Runtime state, domain state and audit history
"Where is the truth?" has three different answers in an agentic system. They are kept in different stores, owned by different components, and they answer different questions:
| Kind of state | Answers | Owner | Examples in this book |
|---|---|---|---|
| Runtime state | Where is this execution, and can it continue? | the agent runtime | Sophos's LangGraph checkpoints and runs table; the in-memory SSE buffer |
| Domain state | What is true about the business right now? | the system of record | the template's tickets; ETF decisions in etfs; Tauros invoices, revisions and approvals; Arktos wallets |
| Audit history | What happened, who caused it, and under which rules? | the mutation boundary | the template's audit rows; ETF audit_events with rules_version and profile_version; Tauros InvoiceEvent |
Do not let one stand in for another
A checkpoint is not a business record. Sophos's checkpoints record a graph's progress so a run can resume (R2, R3). They say nothing reliable about whether an external side effect happened. That question belongs to the system the side effect touched (R7).
A stream is not a record either. What the browser saw over SSE is presentation transport (R4). After a reconnect or a restart, the durable state decides what happened.
A conversation transcript is not authority. In Parts I, III and V the model may say a ticket is urgent, a fund passes, or an invoice is approved. The system of record decides, and the mutation boundary re-reads it under a lock before acting.
Domain state is not audit. The current row tells you what is true; it cannot tell you why. Part III's lesson A6 shows what an audit row needs before a decision can be explained after the policy changes: the policy versions, the human's choice, the rationale. It also shows what is still missing, because the fund facts that were used are not recorded.
How strong is "append-only"?
All three projects that keep a history call it append-only. They enforce it at different layers:
| Project | Mechanism | Limits at the pinned revision |
|---|---|---|
| I · template | database trigger refusing UPDATE/DELETE on the audit table | does not cover TRUNCATE; the application role owns the table and could drop the trigger |
| III · ETF Research | same trigger pattern | same limits; no test exercises the trigger |
| V · Tauros | application code: no update or destroy actions on InvoiceEvent | not database-enforced (planned in Epic 5) |
None of these is tamper-evident against a database owner, and none claims to be. A trigger protects against application bugs and casual edits. Protecting against a privileged insider needs a different design, such as separate roles, an external log or hash chaining. That is a reasonable challenge to attempt.
Memory is a fourth thing
Part II adds a distinction the others do not need: an agent's "memory" may mean prompt context, conversation history, execution state, checkpoint history, application metadata or a long-term knowledge graph (R5). Each has its own owner, lifetime and deletion semantics. Deleting a conversation in Sophos does not delete what the Memory server learned. For governed systems, treat each kind of memory as a separately owned store, with its own answer to "who can delete this, and does deletion propagate?".
Exercise
Take one consequential action in a system you know. For each of the three kinds of state, name the store, the writer, the reader that trusts it, and what happens to it on a crash halfway through the action.