State Store

State stores persist state data, state graph nodes, and snapshots. Public docs refer to state stores as evidence storage for local runs, replay, and handoff examples rather than as a general database API.

What is stored

• serialized state bytes;
• state node metadata;
• parent state linkage;
• state hashes;
• snapshots for replay or resume;
• trace linkage where available.

Local usage

Local examples use SQLite state storage so a run can be replayed after process exit. In-memory stores are useful for SDK examples and tests where persistence is not required.

Failure behavior

A failed state write or state commit must not be hidden. If a commit fails, the runtime does not advance the state head or start the next tick as though the commit succeeded.

Replay relationship

Replay validates referenced snapshots and state hashes before reconstructing run state. Replay does not mutate live state stores by default.