Eight sections — from The Audit That Cannot Be Performed to What You Receive.
An AI system made a decision six months ago. A regulator, an internal review board, or a litigator now needs to understand exactly how that decision was reached. Not what the system generally does — how this specific decision was produced, step by step, with evidence for each step.
No production AI system today can satisfy this request. The decision trail — if it exists at all — is scattered across logs, model states, and runtime artifacts that were never designed to be reconstructed as a coherent sequence.
This is not a logging problem. Most AI systems produce logs. The problem is that logs are not decision trails. A log records that something happened. A decision trail proves why it happened, in what order, under what rules, and with what evidence at each step. The difference is the difference between a stack of receipts and a forensic audit.
The inability to reconstruct decisions after the fact creates a specific, compounding liability. Every day that passes between a decision and its review makes reconstruction harder. Runtime state disappears. Context is lost. The people who configured the system may have moved on. And the regulatory or legal question — was this decision made correctly? — becomes unanswerable not because the answer is unfavorable, but because the evidence to answer it was never preserved in reconstructible form.
This is the reconstruction gap. It exists at the evidence layer — below operational dashboards, below system monitoring, below standard logging. And it is the layer where auditors, regulators, and courts will demand answers when an AI-assisted decision is challenged.
The reconstruction gap is invisible during normal operations. It becomes catastrophically visible the first time someone needs to look backward.
A consumer protection agency investigates a pattern of declined loan applications. They ask the bank to demonstrate, for seventeen specific applications, the complete decision process: what data was used, what rules were applied, what overrides occurred, and why each application was ultimately declined. The bank’s AI vendor provides model architecture documentation and aggregate performance metrics. The regulator does not want architecture documentation. They want the decision trail for application #4,271 on March 14th.
Can you show me exactly why this specific application was declined, with evidence for each step? The bank cannot.
A manufacturing AI adjusted process parameters based on sensor data and predictive maintenance models. The adjustment led to a product quality incident. The post-incident review team needs to reconstruct the sequence of inputs, model outputs, and parameter changes that led to the adjustment. They find operational logs showing that parameters changed, but no coherent record of the decision chain that produced the change — what inputs were evaluated, in what order, under what rules, and where the system had the opportunity to halt but proceeded.
At what point could the system have stopped, and why didn’t it? The logs don’t answer this.
A patient sues a hospital, alleging that a clinical AI’s treatment recommendation was based on outdated guidelines. During discovery, the hospital is asked to produce the complete decision trail for the recommendation: which guidelines were consulted, which patient data points influenced the recommendation, whether any conflicts between sources were detected, and what the system’s state was at each checkpoint. The hospital’s IT team can produce the final recommendation but cannot reconstruct how it was assembled.
Was the recommendation based on current guidelines or outdated ones? The system recorded the output but not the reasoning.
In each case, the system functioned as designed during operation. The failure occurred afterward — when someone needed to prove that the operation was correct. The system was never built to support that proof.
Organizations responding to audit and compliance requirements typically rely on three categories of tools. All three produce records. None produces a reconstructible decision trail.
Application logging records that events occurred — timestamps, function calls, state changes. But logs are not structured as decision trails. They cannot answer why a decision was made, what evidence was available at each step, or where the system had the opportunity to stop. Logs are fragments, not sequences.
System monitoring and observability tools track system health, latency, resource usage, and error rates. They are designed for operational debugging, not decision reconstruction. They can tell you that the system was running; they cannot tell you what the system decided, in what order, or on what basis.
Compliance and audit reporting platforms aggregate metrics across many decisions into dashboards and periodic reports. They answer questions about patterns — how many decisions, what distribution, what error rates. They do not answer questions about specific decisions — why this particular output was produced from these particular inputs under these particular rules.
The gap is structural, not operational. Logging, monitoring, and compliance reporting all serve important purposes. But none of them produces a reconstructible, verifiable, legally defensible decision trail for a specific AI-assisted decision. The machinery for that must be built into the architecture.
The Audit Replay Agent is a specification for a decision reconstruction engine that can take the recorded evidence from an AI system’s operation and rebuild the complete decision trail — offline, after the fact, without access to runtime state.
The agent does not make decisions. It does not influence the system’s behavior during operation. It operates entirely after the fact: given a set of recorded evidence, it reconstructs and verifies the sequence of decisions that produced a specific outcome. Its authority is bounded to reconstruction and verification — it proves what happened, it does not decide what should happen.
The specification is ready-to-build and execution-neutral. It defines the reconstruction protocol, verification rules, and evidence requirements without prescribing a programming language, storage format, or runtime environment. An engineering team receives a complete behavioral specification; they choose how to implement it.
The agent reconstructs and verifies. It does not decide, override, or influence. This separation is what makes its evidence legally defensible — the reconstruction engine has no stake in the outcome it is examining.
The Audit Replay Agent provides four guarantees. These are structural properties of the specification — they hold regardless of implementation choices.
How these guarantees are achieved — the reconstruction protocol, verification procedures, and reporting structure — is the content of the specification.
The Audit Replay Agent applies wherever AI decisions may be reviewed, challenged, or investigated after the fact. The specification defines reconstruction mechanics; the evidence format and verification rules are configured per deployment.
Regulatory examinations, internal audit, and consumer complaint investigations all require the ability to reconstruct specific algorithmic decisions. The Audit Replay Agent provides the per-decision evidence trail that regulators are increasingly demanding under frameworks like MiFID II, Basel, and Dodd-Frank.
Clinical AI recommendations face post-hoc scrutiny from institutional review boards, malpractice litigation, and regulatory bodies. The agent provides the reconstructible trail from input data through recommendation, with verification of evidence integrity at each step.
AI-assisted legal decisions — sentencing recommendations, bail assessments, contract analysis — face constitutional and statutory challenges that require demonstrable decision trails. The agent produces evidence that meets the specificity requirements of legal proceedings.
Post-mission review and incident investigation for autonomous and semi-autonomous systems require complete operational reconstruction. The agent rebuilds the decision sequence from recorded evidence, including identification of decision points where alternative actions were available.
Disputed AI-assisted claims decisions require per-decision reconstruction for regulatory review and litigation. The agent provides the evidence trail demonstrating how specific claim inputs led to specific outcomes.
Internal audit, SOC 2 compliance, and board-level AI oversight require systematic evidence that AI systems operated within governance boundaries. The agent provides per-decision reconstruction that integrates with enterprise audit workflows.
The §07 content reduces to a single configuration: Standalone.
The agent is delivered as a Single-agent Pack: a complete specification document package, distributed free of charge. The pack contains the normative specification, the canonical semantic indices (D1–D4), the Conformance Tests, this whitepaper, and the README. Your engineering team builds the agent from the specification, integrates it with the systems it must observe, and operates it as the role that specification defines. The pack is execution-neutral; it does not prescribe a programming language, framework, or runtime.
Standalone solves a scoped decision reconstruction
The Audit Replay Agent specification is a ready-to-build, execution-neutral normative document. It is not a concept paper, not a framework, not a set of guidelines, and not an architecture diagram.
It is the document you hand to an engineering team when you want them to build a component that produces the guarantees described in this whitepaper. The engineering team does not need to make design decisions about what the agent should do, how its logic should work, what it should record, or how it should fail. Those decisions are made. The specification contains them.
| Package | What you get | Best for |
|---|---|---|
| StandalonePKG-A · Agent | The complete agent specification — sufficient for independent implementation. | Solving a specific problem in a specific system. |
The Audit Replay Agent specification includes everything necessary for implementation: the agent's identity and boundaries, its contracts with external systems, its complete internal logic, the rules governing every possible input, the evidence it must produce, the way it handles failures, the conditions for resuming after a failure, and the criteria your team uses to verify that their implementation is compliant.
Nothing is left undefined. Nothing is left to interpretation. Nothing requires your team to reverse-engineer intent from ambiguous prose.
Every whitepaper in the library is free to read. Every specification is distributed free of charge. Free to use, free to verify, free to publish about — free to implement and to embed in your own products, including commercially. The license sets out what is reserved. The whitepaper shows you the problem and the promise. The specification gives you the solution.
Independent Research · Specification-Grade AI Governance.
This whitepaper describes the problem the Audit Replay Agent solves and the outcomes it guarantees. It does not describe the agent's internal mechanisms, design decisions, or specification structure. The specification is a separate deliverable, distributed free of charge.