# Zudux-State V2 Enterprise Guide

## Architecture selection

Use a governed domain for business state, a signal for small local models, a transient channel for frame-rate data, a resource hub for remote data, and an event domain when replay is a business requirement. Keeping these workloads distinct prevents durable audit history from being polluted by pointer movement or cache refreshes.

## Domain hardening

Published state is frozen by default. Add `validate`, invariants, a policy engine, bounded history/audit limits, an `onModuleFault` handler, and deterministic IDs supplied by infrastructure. Use idempotency keys for commands triggered by retried requests.

Post-commit modules are deliberately best-effort: once state is published, a logger outage cannot make the command appear rejected. Use a durable telemetry sink if delivery guarantees are required.

## Performance model

Commands use copy-on-write proxies. Only changed branches receive new references. Event patches are suitable for replication and inspection; inverse patches power rewind and speculation. Put pointer, animation, and sensor values in `forgeTransientChannel` to avoid business-history overhead.

Use `forgeSelector` for parameterized/multi-input caches and `trackView` for property-level dependencies. Monitor selector hit/miss ratios and slow-computation callbacks.

Use `domain.preview()` before irreversible business steps, approval screens, or admin bulk actions. It returns the proposed state, patches, inverse patches, result, or rejection without publishing, notifying observers, or writing audit history.

## Resource cache

One resource hub should normally represent one trust/base-transport boundary. Define stable endpoint arguments, meaningful invalidation tags, explicit stale/retention periods, abort-aware loaders, and bounded retries. Dehydrate on the server and hydrate before client subscriptions to prevent loading flashes.

## Offline synchronization

`bindReplica` exchanges patches and records per-source progress. Production transports should authenticate messages, persist the outbox, reject unknown schemas, and provide a domain-specific `resolve` function. Conflict hooks are signals for missing counters; they are not a substitute for a server reconciliation policy.

Use `replicaConflictStrategies.applyPatches` for simple patch replay, `serverAuthoritative` when a trusted backend sends complete state, and `lastWriteWins` only for low-risk collaborative data where overwriting is acceptable.

## Multi-domain work

`coordinateDomains` stages recipes, commits enlisted domains in order, and compensates earlier commits if a later invariant fails. This is a saga-style coordinated transaction—not a distributed database transaction. External irreversible work should occur after successful coordination or provide an explicit compensating operation.

## Audit and privacy

Audit records form a SHA-256 hash chain. Export complete chains, retain the first predecessor hash, redact sensitive tags, and anchor periodic terminal hashes in independent storage for stronger tamper evidence. Hashing proves integrity relationships, not actor identity; sign exported anchors when non-repudiation is required.

Use `queryAudit()` and `stateTimeline()` for support investigations. Use `replayPolicy()` before shipping new access rules so the team can see which historical commands would now be denied.

## Enterprise intelligence

Add `forgeStateGuard()` when command risk depends on command name, payload, actor, tags, or current state. Its `policy()` adapter can require approval tags for high-scoring commands while still composing with an existing access policy.

Attach `commandSlaModule()` to enforce command expectations such as required actors, duration ceilings, maximum patch count, and required tags. Attach `forgeMutationProfiler().module` to collect command cost reports without coupling the domain to a specific monitoring vendor.

Use `forgeTenantHub()` for SaaS tenants, SSR requests, or isolated test fixtures. A tenant hub creates one domain per tenant ID and disposes domains explicitly, preventing accidental shared singleton state.

Use `forgeDomainGraph()` to document domain impact paths, for example `account -> invoice -> notifications`. Use `scoreEnterpriseReadiness()` during release review to see missing controls such as policies, invariants, audit, persistence, checksums, actor tags, rollback, tests, inspector, and schema validation.

## Failure testing

Use `deterministicRuntime`, `faultingPersistence`, and `replicaTestBus` to reproduce timing, storage failures, packet loss, and reordering. Test every invariant with randomized command sequences and verify the audit/event chains after recovery.