Mission state changes must enter the Mission state store through State store transactions. A State store transaction is a small atomic write boundary: the daemon validates Entity input commands, workflow commands, or daemon-owned domain intent, applies the resulting storage changes, checkpoints the Mission record, and publishes the change from one place.

This is intentionally not a separate transaction-control architecture. Mission does not need an additional event-sourcing layer, replay model, domain-effect hierarchy, or public transaction language. The transaction exists to keep writes local and auditable while preventing direct storage mutation from leaking across daemon modules.

State store transaction descriptors, transaction mutations, snapshots, and recovery attention are validated with Zod v4 schemas owned by the Mission state store module. Exported TypeScript data types for those validated shapes must be inferred from the Zod v4 schemas with z.infer; hand-written parallel types are not canonical because they can drift from validation. State store adapters must use those schemas instead of accepting TypeScript-only shapes, unchecked JSON, raw SurrealDB records, fallback parser output, or normalized compatibility shapes at the interface. Physical record adapters such as FilesystemAdapter sit below that seam: they read and write raw files, while the Mission state store validates and materializes accepted Mission runtime data and event records. This keeps the Mission state store interface testable today and makes the later SurrealDB adapter a schema-mapping problem rather than a broad type migration.

Daemon modules must not write storage records directly or share a raw SurrealDB client as a private write path. SurrealDB is the datastore adapter behind the Mission state store, not the public write interface for arbitrary daemon internals. This keeps domain rules, audit, checkpointing, and change publication in one place instead of spreading database knowledge across Entity classes, workflow runtime modules, Open Mission control code, or future replication code.

The accepted State store transaction is the unit for Mission record checkpointing, recovery attention, audit, and Entity change stream publication. If a checkpoint fails, Mission keeps the accepted transaction live in the daemon in-memory datastore and follows the non-blocking recovery attention behavior recorded in ADR 0002.02.

Entity RPC remains the surface mutation interface. Surfaces submit Entity input commands; they do not submit storage patches or State store transactions. A future Entity command outbox stores input commands only, and those commands become canonical only after the daemon validates them and applies the resulting State store transaction.

Until the daemon-wide Mission state store owns Artifact body persistence, file-backed Artifact body edits are accepted only through the Artifact Entity command surface and may use the existing Mission record filesystem write path as transitional persistence. That exception is limited to the Artifact body payload itself; it does not permit private storage-record writes, alternate surface mutation vocabularies, compatibility methods such as writeBody, or bypassing the Artifact command input schema. When Artifact body persistence moves behind State store transactions, the public surface remains the same Artifact command.

This gives Mission SurrealDB’s indexing, relationship, query, and change-stream leverage while preserving daemon authority and keeping write semantics testable through one deep Mission state store interface.