Mission will move toward a daemon-owned Mission state store as the canonical owner of Entity storage records, Mission runtime data, Agent execution context, and other durable Mission coordination state. The first intended adapter is a daemon in-memory datastore using embedded SurrealDB with SurrealMX-backed memory as canonical working state.

The daemon in-memory datastore is not a cache in front of another in-process Entity or workflow model. Entity classes and workflow runtime modules should write through the Mission state store so the datastore is the authoritative working record. The canonical write interface is a small State store transaction: Entity input commands, workflow commands, and daemon-owned domain intent are validated and applied before Entity storage records or durable Mission coordination state change. Daemon modules must not bypass this interface with direct storage writes or private SurrealDB client usage.

Mission state store schemas are part of the Mission state store module and are written with Zod v4. Any shape that needs runtime validation must have a Zod v4 schema as the source of truth, and exported TypeScript data types for validated shapes must be inferred from those schemas with z.infer instead of being hand-written beside them. Validation is clean-slate: the Mission state store rejects invalid Mission runtime data, transactions, snapshots, and event records instead of applying fallback parsers, compatibility aliases, or load-time normalization. Schema definitions live separately from state store adapter classes so validation, TypeScript inference, and future SurrealDB database schema mapping share one source of truth. Until the daemon-wide Mission state store owns broader datastore responsibilities, the narrower per-Mission record-backed implementation lives with Mission runtime instead of occupying a mission-state-store module name prematurely.

Filesystem adapters are physical Mission record adapters for this slice. They may know Mission runtime data and runtime event-log file paths and raw JSON/JSONL mechanics, but they must not parse Mission runtime data schemas, create Mission runtime data, validate workflow event records, migrate runtime layouts, or apply domain defaults. The Mission runtime module owns those schema-aware operations and uses the filesystem adapter only as raw Mission record file I/O.

The first state store persistence policy is Mission record-backed persistence. The Mission record remains the canonical durable recovery format. When the daemon starts or resumes a Mission, it performs state store hydration by reading and validating the Mission record once into the daemon in-memory datastore. After hydration, live Mission work reads and writes the daemon in-memory datastore, not the Mission record as a repeatedly-read live store.

Mission record checkpoints run after every accepted State store transaction because Mission data is currently small and direct persistence is simpler than batching. This keeps durable recovery current without giving up SurrealDB’s live working advantages. Batching, debouncing, or lifecycle-only checkpoints are future state store persistence policy optimizations and require a new decision before replacing direct checkpoints. SurrealDB capabilities such as live querying, indexing, relationships, change streams, and in-memory working state remain central. Configured SurrealDB memory persistence, SurrealKV, RocksDB, or export/import may be added as recovery optimizations, but they must not replace the Mission record as the canonical durable recovery format without a new ADR. Open Mission surfaces and Surface state replicas must not define persistence for canonical Mission state.

If a Mission record checkpoint fails after the Mission state store has accepted a State store transaction, Mission does not roll back the accepted transaction. Agent executions and Agent adapters may already have changed files in the Mission worktree, and Mission cannot emulate each agent adapter’s checkpoint or rollback semantics. Instead, the daemon keeps the daemon in-memory datastore live and marks the Mission for recovery attention so it can retry persistence, record diagnostics, or run daemon-owned recovery handling. Mission recovery attention is non-blocking: the daemon continues to accept new State store transactions while persistence recovery is pending, unless a separate future safety policy explicitly pauses a Mission. Mission recovery attention is daemon-only by default and is not published through Mission control view, System snapshot, or Entity data unless a future operator-facing recovery design explicitly promotes it.

Open Mission surfaces may later maintain a Surface state replica, likely using SurrealDB/WASM with IndexedDB, but the replica is not a second canonical Mission state owner. It is a local query, reconnect, and offline-read aid populated from daemon-published Entity storage records and Entity change streams.

Entity RPC methods remain the surface mutation interface. A surface submits an Entity input command, the daemon validates it with the Entity input schema, applies it through a State store transaction, checkpoints it, and publishes the resulting changes. A future offline surface may queue Entity input commands in an Entity command outbox, but those commands become canonical only after daemon acceptance and transaction application.

The Input, Storage, and Entity schema roles are load-bearing for replication. <Entity>InputSchema defines daemon-validated creation or registration input. Method-specific input schemas define mutation intent and future command outbox payloads for existing Entities. <Entity>StorageSchema defines canonical persisted records and the only record shape eligible for replication as source of truth. <Entity>Schema defines the fully hydrated Entity instance, including computed fields, linked Entity data, workflow read material, and commands; hydrated Entity views may be derived by the daemon or a Surface state replica, but they must not be replicated as source of truth.

SurrealDB live queries and change feeds are suitable primitives for the replication path: live queries can support connected real-time updates, while change feeds and replication cursors can support reconnect and catch-up. The State store transaction is only the accepted write unit that connects validation, checkpointing, and change publication; it must not become a separate event-sourcing or replay architecture. Export/import may seed or rebuild a replica, but it is not the ongoing synchronization contract. Mission should not depend on a complete built-in browser-to-daemon database replication protocol unless SurrealDB explicitly provides one that preserves daemon authority and command validation.

This path keeps the existing Entity RPC design useful while removing the burden of hand-maintained surface mirrors. The daemon owns writes, State store transactions define the accepted write unit, the daemon in-memory datastore owns canonical working state, Mission record-backed persistence owns durable recovery, surfaces can query local replicated storage when that becomes valuable, and schema-role discipline prevents Data views from becoming another drift-prone mirrored model.