Decision Traces & AI-Readiness

AI agents are increasingly doing things in production systems: booking flights, approving loans, executing trades, resolving tickets. For them to be trustworthy, two things have to hold:

1. Before acting, an agent needs the context of similar prior decisions: precedent, exceptions, policy history. Without it, the agent is guessing.
2. After acting, someone needs to reconstruct what the agent did and why: for audit, for dispute resolution, and for debugging the agent itself.

A traditional CRUD database fails at both. Its state shows where things ended up, not how they got there, and decision context lives in chat threads, email, and experienced employees’ heads.

A decision trace is the record behind a business action: what happened, what caused it, who asked for it, and what the system knew at the time. In EvidentSource, the event log and its transactions are that record.

What EvidentSource records

Every event carries:

• its type, stream and subject: what happened, and to what;
• its effective time, when it took effect, and its recorded time, when the database learned of it;
• its revision, its position in the database;
• a causationid, the transaction that appended it, and a correlationid when the caller supplies one;
• authtype, the kind of caller, and for an authenticated caller its authid.

Every transaction records:

• how it arrived: over HTTP, gRPC or Kafka, and whether as raw events or as a command;
• for a command, which State Change handled it, and that State Change’s version;
• its basis, the database’s revision just before it.

Who sent it is recorded for events appended directly, and for commands run synchronously or asynchronously, over HTTP or gRPC: the transaction carries the caller’s attributes from their token, and each event its authtype and authid. A record produced to the command topic directly records the caller attributes it carries; Kafka’s access control is what stands behind them. With authentication off, a caller over HTTP is not identified, and its events carry authtype unauthenticated; over gRPC, a caller that presents a token is still recorded as itself.

Reconstructing a decision

• What did the system know? Read at the transaction’s basis revision. Every earlier revision stays readable, so a State View read there shows the state as it stood.
• What did the agent do? The transaction and its events, found by the causationid on any of them.
• Who asked? The caller’s attributes on the transaction, and authtype on each event, where they’re recorded.

Two limits worth knowing:

• Identity attributes are context, not proof. They are not signed. Read authid together with authtype.
• Reads are reproducible when they name what they depend on. A State View read at a revision and an effective-time cut always gives the same answer. An effective-time-ordered view refuses a read with no cut, inside decide too, and a read at now is told which time now was. See Bi-temporal reads.

Why this matters for AI agents

• Context before acting. An agent can query events by subject and type to see how similar cases were resolved, before it appends anything.
• Auditability after acting. Regulators won’t ask only “what did the AI decide?” They will ask “why, and what did it know when it decided?” The log records the what and the when for every caller, agents included, without instrumenting the agent.
• A narrow job to generate. decide and evolve each have one input shape and one output shape, which gives code generation a small, checkable target.

See MCP for AI agents for how agents can reach EvidentSource directly through the Model Context Protocol.