A customer reports an unauthorized data access on May 1. The investigation runs on June 15. The audit log has the agent's action, the operator behind it, the policy decision, and the outcome. The investigator has two questions: "what happened," and "why was this allowed at the time, and would it be allowed today."

The audit row answers the first question alone. The second requires replay: re-running the action's evaluation against the policy that was in force on May 1, with the inputs the agent saw, to see whether the policy gate emits the same decision.

Replay turns an audit log from a record of what happened into a tool for answering counterfactual questions. It also pays down audit lag in advance: the answer to "why was this allowed" is already in the policy store, waiting on the row that names the version.

Replay is also a regulatory primitive. The EU AI Act's Article 12 obligation to enable post-market monitoring and to identify risk situations practically requires the ability to reconstruct events. A runtime that produces the audit row but cannot replay the evaluation is missing half the investigation surface.

What "replay" means concretely#

Teams often conflate three operations under the word replay.

Action replay. Given an audit row, reconstruct the agent's action: which tool was called, with what arguments, against which resource, under which identity. The row schema supports this directly; no replay engine is required.
Decision replay. Given the audit row and the policy version recorded on it, re-evaluate the policy gate's decision. The output should match the original decision field. This proves the row is internally consistent.
Run replay. Given the audit row, the agent's reasoning record, and the run's input context, reconstruct the chain of actions the agent took. This is the heaviest operation, and it depends on the agent's reasoning being deterministically reproducible, which is not always possible.

Decision replay matters most for security investigations and the EU AI Act. Run replay matters for model risk validation and product debugging. Action replay is always available, because the audit row is its only input.

Decision replay in detail#

The row records the policy gate's inputs at evaluation time. The five inputs from Policy at action time are all there: identity, resource, arguments, run context, and policy version, the last as a foreign key into the policy store. The replay engine fetches the policy by version, builds the input bundle from the row, and runs the policy.

The output should be identical to the row's decision field. If it isn't, one of three things happened:

The policy store lost a version. The policy in force at the time was overwritten without preserving the old version. This is a runtime bug; the policy store has to be versioned.
The audit row is missing an input the policy depends on. This is a schema bug; the row needs another field.
The policy depends on external state that was different at the time. Pure replay cannot resolve this. Reconstruct the state from other sources, or rewrite the policy to compile that state into the policy version at load time.

The first two are runtime defects. The third is a design choice: policies that depend on time-varying external state are harder to replay than policies that depend only on the row's inputs. Compiling state into the policy version and avoiding I/O on the evaluation path, as the policy post describes, also makes decision replay tractable.

Counterfactual decision replay#

Once decision replay works, the extension is counterfactual: what would the decision have been under a different policy? Two use cases:

Investigation. Given an action that turned out to be wrong, what policy change would have prevented it? The investigator drafts the change, applies it as a new policy version, and runs decision replay against it. The change moves forward if the replay shows the desired effect on the historical action.
Policy review. Before deploying a new policy version, the replay engine runs it against the last 30 days of audit rows and reports how many allowed actions would have become denied or require-approval. The team reviews the changes. An unexpectedly large change set points to a bug in the policy.

Both need the audit log to carry enough input data to drive the policy under arbitrary versions. What an agent audit row should carry describes the minimal row for this. The reasoning trace is not required.

Stochastic vs deterministic replay#

Run replay runs into stochasticity. The model's decision at each step depends on sampling, which is not deterministic by default, so two agents given the same inputs can produce different action chains. Three sources matter:

Temperature and sampling. At non-zero temperature, the same inputs produce different outputs across runs, so replay against the live model is not deterministic.
Model version. If the provider updated the underlying model since May 1, replays against the current model are not faithful.
Prompt assembly. Small differences in how the prompt was built (whitespace, order of retrieved chunks, timestamp inclusion) change the model's output.

Three replay strategies handle this:

Deterministic seed replay. The runtime records the sampling seed and model version, and the replay engine reuses both. This works while the model version is still available.
Distribution replay. The replay runs the action many times and reports the distribution of outcomes. It answers "is this kind of action consistently allowed" without reconstructing the specific event.
Trace replay. The runtime records the model's output verbatim, and the replay re-runs the policy gate's decisions against the recorded outputs. This trades model fidelity for decision fidelity: the agent's actions are exactly what they were, but the model is not re-evaluated.

Most investigations need trace replay. The question is rarely what the model would do if re-run. It is whether the decision was right, given what the model did.

The reasoning store#

Run replay needs the agent's reasoning record: the prompt, the model's response, the retrieved context, and the tool outputs. This is the structured reasoning record from the audit-row post, kept in a separate store from the SIEM-shaped audit log.

The reasoning store has tighter access controls than the audit log because it holds content the agent ingested from customer data and third-party APIs. Its retention is shorter because storage costs more and the use case is narrower.

A useful default partition: the audit log retains for years, the reasoning store for 30 to 90 days. Investigations that need both have to land inside the reasoning store's window. Later ones have the audit log alone, which supports decision replay but not run replay.

EU AI Act Article 12 connection#

Article 12 of the EU AI Act requires high-risk AI systems to enable post-market monitoring and to identify situations that present risk. Both require replay: monitoring surfaces patterns across many actions, and risk identification reconstructs individual events.

The primitives in this post map onto Article 12 as follows:

The audit row is the record-keeping requirement.
Decision replay is the monitoring capability.
Counterfactual decision replay is the risk-identification capability that lets the deployer assess proposed mitigations.

A runtime that ships the row schema but not the replay engine meets Article 12 only in part. A runtime that ships both is the more defensible posture under conformity assessment.

Model risk validation use case#

Model risk teams use decision replay to validate an agent runtime before deploying it on a new workload.

The team writes a test suite of synthetic actions the agent might plausibly attempt, including out-of-scope ones, and runs decision replay over the suite against the production policy with specific expected outcomes. A mismatch is a bug in the policy or in the expectation, and the team resolves it before deploying.

The replay engine is the test harness, the policy is the code under test, and the synthetic actions are the test cases.

Where the replay engine sits#

The replay engine sits next to the policy gate and off the action path. The gate runs on every action. The replay engine runs on demand against historical and synthetic actions. Both share the policy evaluator, so the code that decides live also decides on replay.

The engine reads from the audit store and the policy store and produces reports. It never affects live agent actions. Replay activity is itself audited, because the engine's queries against the audit store are access to sensitive data.

Closing#

A runtime with a structured audit row, a separate reasoning record, versioned policies, and a working replay engine supports three checks. The audit log supplies the first and the replay engine the other two:

Reconstructing what an agent did from the row alone.
Re-running a policy decision against the version active at the time.
Testing a proposed policy change against 30 days of historical actions before it ships.

Deixic keeps policy and approval decisions in a tamper-evident history alongside governed action results. Its evals and replay replay sessions as scenarios, so a changed model, prompt, or skill can be checked against work your company already did. Your integration supplies the policy-reconstruction fields and the replay path for the decision-replay design above.