The email arrives on a Tuesday, fourteen months after anyone last thought about the decision it names. An external auditor is sampling month-end releases in accounts payable, and one of the twelve items her random draw pulled is exception E-2847: an invoice that the AI-assisted workflow flagged, a reviewer touched, and the system released. Her request is one sentence long and it is the same sentence auditors, regulators, litigators, and disputing customers have been writing for a hundred years: "Please walk me through how this decision was made." In an all-human process, you would answer with testimony and email archaeology, imperfect but familiar. In an AI-assisted process, that option is gone, because the model cannot testify, the reviewer may be gone, and "the AI suggested it" is not an account of anything. The answer has to be reconstructed from records somebody designed in advance. This lesson is about designing them: the six fields every AI-touched decision must be able to produce, and the test that proves it can.

The Question That Always Arrives

Start by noticing who asks, because the list is longer than "the auditor" and every name on it carries authority you do not get to argue with. The auditor sampling month-end releases asks it as routine. The customer disputing a rejection asks it with a deadline and, sometimes, a lawyer. The regulator inquiring about a pattern asks it in writing, with a docket number. The litigator with a discovery request asks it about hundreds of decisions at once. And your own quality review asks it every time an escape is traced backward: which decision let this through, and what did that decision know at the time? Five different askers, one identical shape: not "is your process good in general" but "account for THIS decision, on THIS date, about THIS case."

In a purely human process, organizations have always answered this question badly but survivably. Someone interviews the clerk. Someone excavates an email thread. Someone finds the approval in a signature field. The answer is slow, partial, and colored by hindsight, but a human decision-maker exists who can stand in a room and say "here is what I saw and here is why I did it." The account may be imperfect. It is at least possible.

An AI-assisted decision breaks that fallback in three places at once. The model that made the proposal cannot be interviewed, and the version that made it may have been replaced twice since. The inputs it saw were probably live system references that have since changed: the vendor record as it reads today is not the vendor record the decision consumed. And the human in the loop, if they are still employed, reviewed forty such items that day under a review standard that has itself been revised. Nobody in this chain can testify to the specifics, and hindsight quietly rewrites what everyone remembers. The account must therefore be reconstructed from designed records, or it does not exist. There is no third option, and this is the fact the whole lesson stands on.

The AI cannot testify and memory cannot be subpoenaed usefully: the audit trail is the institution that answers for an AI-assisted decision, and it either exists by design or it does not exist at all.

One distinction before we build, because the agent chapter already gave you something that sounds similar. The agent's action log, held to the reconstruction standard, records what a SYSTEM did: every tool call, every state change, what, when, whose case, from what inputs, why, under which permission, and what happened next. Keep it; nothing in this lesson replaces it. But the action log answers "what did the machine do," and the question that arrives on Tuesday is "how was the decision made." Those are different questions. A decision is bigger than the actions inside it: it includes what information was consulted, what the AI proposed and how strongly, what the human was responsible for checking and what they actually did, which policy version governed, and what happened downstream. The audit trail this lesson designs is the decision-level evidence layer that sits above the action log and cites it. The action log records behavior; the audit trail records judgment. Your program's fourth non-negotiable says accountability stays human. The audit trail is that accountability's memory.

The Decision Record Standard: Six Fields, No Exceptions

Here is the lesson's named artifact: the Decision Record standard. It says that for every decision your AI-assisted workflows touch, you must be able to produce six fields on demand. Not that you must write six paragraphs per decision by hand: almost all of this is captured automatically by systems you already run, connected by identifiers. The standard defines what "complete" means, so that absence becomes visible at design time instead of at discovery time. We will take the six fields slowly, because each one exists to answer a specific question that will someday be asked with authority, and each one fails in a specific, expensive way when it is missing. Throughout, we will render each field against the two running examples this level has built: the invoice-exception workflow (AI extracts and categorizes, a human gate reviews, the system releases) and the vendor-inquiry agent (AI drafts responses to supplier questions under review sampling).

Field 1: The Inputs as Seen

What information did the decision actually consume? Not "the invoice" in the abstract: the specific invoice image version, the vendor-master snapshot as it stood at 14:32 that day, the exact policy passages the retrieval step handed the model. The operative phrase is as seen, and the discipline behind it is the difference between a snapshot and a live reference. A live reference says "vendor record 40118" and points at a table that will keep changing after the decision is made. A snapshot says "vendor record 40118 as of March 11, 14:32, bank details ending 4471" and never changes again. You met this problem in the drift lesson as the world changing underneath your model. Here it is again, applied to evidence: if your records point at live references, then fourteen months later you are not reconstructing the decision, you are viewing today's data through last year's decision ID, and any replay will quietly lie to you. The invoice-exception record stores the document version ID and a vendor-master snapshot reference. The vendor-inquiry agent stores the retrieved passages themselves, not just the names of the documents they came from, because the documents get revised. In operator terms: staple a photocopy to the file; do not staple a window.

Field 2: The AI Contribution

What did the model propose, how confident was it, what evidence did it point to, and, critically, WHICH model was it? The record captures the proposal ("category: maintenance services; amount 4,180; three-way match: quantity mismatch"), the confidence band the routing logic used, the evidence pointers the reviewer saw, and a version stamp: model version, prompt version, configuration version. The version stamp looks like bookkeeping until the first incident, when the first question in the room is always the same: "was this before or after the update?" That question is asked in every incident review that has ever involved software, and without the stamp it is unanswerable. The stamp is also what connects a single decision outward to the operating records this level already taught you to keep: the canary deck results and the change log that governed that week. With it, "decision E-2847 was made under config v3.2, which passed canaries on March 8 and was superseded March 20" is one lookup. Without it, every decision in a disputed period is equally suspect, which in practice means all of them get re-reviewed, which in practice means nobody re-reviews anything and the dispute is settled on vibes.

Field 3: The Human Judgment

Who reviewed the proposal, and what did they do: approve, correct, reject, or escalate, with a reason code, under which version of the review standard. That last clause is the one most organizations miss. Recording "reviewer R2 approved" proves a human was present. Recording "reviewer R2, under Gate Spec GS-01 v1.3, corrected the category with reason code C-2" proves what that human was RESPONSIBLE for checking and what they actually exercised judgment on. The Gate Spec citation matters because review standards change: GS-01 v1.3 might require a three-way-match check that v1.1 did not, and a decision reviewed correctly under v1.1 must not be judged retroactively against v1.3. This field is the accountability line made queryable, and notice what it does for the reviewer as much as to them: it converts "were you paying attention?" (unanswerable, insulting) into "did you perform the checks the standard assigned you?" (answerable, fair). Your human-gate lesson said a gate without a review standard is a gesture. This field is where the standard leaves a receipt.

Field 4: The Outcome and Downstream

What was decided, and what happened next? Released, and then: paid without incident, disputed by the vendor in week three, reopened by quality review, reversed on appeal. The decision record links forward to the event log's later states so that any decision can be judged by its consequences, not just its process. This is where escape tracing lives: when your quality review finds a wrong invoice in month four, this field is the thread it pulls to find the decision that released it, and fields one through three are what it finds at the other end. A trail that ends at the moment of decision is half a trail; the auditor's real question is usually "you decided X, and then what happened?" The invoice-exception record carries the release event ID and links to payment, dispute, and reopening events. The vendor-inquiry record links the sent response to any follow-up complaint on the same thread.

Field 5: The Policy Context

Which standard operating procedure (SOP) version governed at decision time, which thresholds, which error budget. This is Chapter 3.2's document-version discipline paying its compliance dividend. The point is protective in a direction that surprises people: a decision that was correct under SOP v2.1 and would be wrong under SOP v2.3 is a finding about change management, not about the clerk. Without this field, every process improvement you ever ship silently converts your own history into apparent misconduct, because old decisions get judged by new rules. With it, the timeline is exact: this decision was made on March 11 under v2.1; v2.3 took effect April 2; the behavior changed because the rule changed. Auditors do not merely tolerate this answer; they respect it, because it demonstrates that your documents have versions and your versions have dates, which is most of what a records auditor is actually probing for.

Field 6: The Exceptions and Overrides Around It

Was this decision made inside an abnormal operating period? During a yellow rung on the escalation ladder, when sampling was doubled? Inside an incident window? Inside a mitigation lane, like the fairness routing you built in the previous lesson, where a flagged segment deliberately receives heightened review? Context reframes individual decisions. A reviewer who rejected an unusual number of items during a yellow-rung week was not being erratic; they were following the tightened protocol, and this field is the record that protects them. It is also where the previous lesson's fairness check sheet becomes trail-fed evidence: when someone asks "does your AI treat vendor segments differently?", the trail can cite the quarterly check sheet, its date, its findings, and the mitigation lane that any affected decision ran through. A decision examined without its operating context is a sentence quoted without its paragraph, and hostile readers love quoting out of context. This field takes the option away.

Six fields. Read them back as the questions they answer: what did it see, what did the AI say, what did the human do, what happened next, what rules governed, and what was unusual that week. Any authority who asks about a decision is asking some subset of those six. The standard's job is to make sure no subset comes back empty.

The Retrieval Test: The Standard's Teeth

A standard without a test is a hope, and this program has already taught you what to do about specifications that might be theater: make someone do the thing. The verification lesson had the do-it test. The Decision Record standard has its audit sibling, the retrieval test: once a quarter, pull three random decisions per AI-touched workflow and reconstruct all six fields for each, with a stopwatch running. The target is 30 minutes per decision. Not because auditors give you 30 minutes, but because reconstruction time is the honest measure of whether your trail exists in practice or only in architecture diagrams. If reconstructing one decision takes days of engineers spelunking through logs and asking around on chat, then your trail exists in theory only, and the first real request will prove it at the worst possible moment, in front of the least sympathetic audience.

The design rule that falls out of the test is worth saying plainly: design nothing you cannot retrieve. A field that is technically captured somewhere, in some system, retrievable by one specific engineer who is on parental leave, is not captured. Random selection matters for the same reason it matters in review sampling: if you choose the decisions to reconstruct, you will unconsciously choose the easy ones, and the test will pass forever while the trail rots. Three per workflow is deliberately small; this is a fire drill, not an audit, and it must be cheap enough that it actually happens quarterly.

The test's results are themselves evidence, so treat them like it: reconstruction times and any failed fields go to the quality review as a standing line item. A field that failed retrieval is a defect with a name and an owner, fixed like any other defect. And notice what the quarterly rhythm quietly builds: the first time a real auditor asks, your team will have rehearsed the exact motion a dozen times. The retrieval test IS the audit rehearsal. Organizations that rehearse retrieval answer discovery requests in days; organizations that do not, staff a war room.

One Decision, Reconstructed in Twelve Minutes

Here is the whole standard rendered against a single decision, with illustrative numbers, so you can see what "complete" looks like at the level of one record. The case is the one from the opening scene: invoice exception E-2847 in the invoice-exception workflow, sampled by the auditor fourteen months after the fact.

Now the retrieval test, run on this record before the auditor ever asked: full reconstruction took 12 minutes, and it is worth seeing where those minutes went, because the machinery is deliberately boring. Three systems held everything. The event log (the same instrumentation this level built for baselines and drift) supplied the timeline: what fired when, in what order, with the downstream payment and non-events. The decision store, which in most organizations is simply the ticketing or case-management system with a few added fields, supplied the AI proposal, the confidence, the reviewer identity, the reason code, and the version stamps. The document registry (Chapter 3.2's versioned SOP and Gate Spec library) supplied what v2.1 and GS-01 v1.3 actually said. The joins are just IDs: the exception ID links the ticket to the events; the version stamps link the decision to the registry and the change log. Nothing exotic. Most organizations already own all three parts; what they lack is the design decision to connect them and the standard that says which fields must land where. That is genuinely all an audit trail is: the ticketing system, the log, and the version registry, holding hands on purpose.

The auditor's Tuesday email, in this version of the story, was answered the same afternoon with a two-page walk-through. She sampled eleven more. The AP section of the audit closed without a finding, and, a detail worth savoring, with a sentence in the management letter noting the records discipline. Illustrative numbers, real shape.

The Firm That Could Not Answer

Now the other version, assembled from the standard failure pattern, with illustrative figures. A professional-services firm ran an AI-assisted compliance screening step: the model proposed pass/flag decisions on client transactions, a reviewer confirmed, volume was high, and everyone was reasonably sure the process was sound. Fourteen months after one particular screening decision, a client disputed it, with counsel, claiming the flag that delayed their transaction was baseless and cost them a deal.

The firm believed the decision was right. Believing it was the easy part. Demonstrating it required reconstructing what the decision saw and proposed, and every thread they pulled came away loose. The model had been updated four times since; nobody could say with confidence which version had made the proposal. The prompt had been "improved" repeatedly by a well-meaning analyst, without versioning, so even the model version would not have pinned down the behavior. The reviewer who confirmed the flag had left the firm ten months earlier. And the inputs were live references: the screening had consumed the client's risk profile and a watchlist feed as they stood that day, and both had changed many times since. A replay against current data produced a different result, which was worse than no replay at all, because now the record appeared to contradict the original decision.

Counsel's assessment was blunt: the decision was probably defensible, and the firm could not demonstrate its defense, and in a dispute those are the same thing as being wrong. They settled for a low six-figure sum, call it $180,000 plus fees, plus the quieter costs: a remediation project to bolt versioning on after the fact, and a client base that heard about it. The trail's absence had converted a probably-correct decision into a liability.

Run the contrast honestly, because it is the entire economics of this lesson in one paragraph. With the six fields in place, that same dispute is a 40-minute records response: inputs as seen (snapshotted profile and watchlist entries), AI contribution with version stamp, reviewer action under a cited standard, outcome links, governing SOP version, no abnormal operating period. Delivered in a week with a cover letter, that package deflates the dispute on contact; almost all disputes do deflate on contact with records, because disputes feed on ambiguity. The cost of the trail was three design decisions at launch: snapshot the inputs, stamp the versions, store the reason codes. The cost of its absence was the settlement. Nobody who has paid the second price ever argues about the first again.

Retention, Access, and the Rising Floor

Three governance questions remain, and all three are policy decisions you make once, at design time, rather than arguments you have during every incident.

How long the records live

Decision records are records, and they inherit the rules of what they contain. Align retention with the document-retention and privacy commitments you mapped in Level 2's pre-flight: if the invoice workflow's records carry vendor bank details, the trail carries them too, and the trail's retention and protection must match. Set one retention period per workflow, in writing, with your records or privacy owner, driven by the longest applicable obligation (audit cycles, statute-of-limitations exposure, sector rules). The trap to avoid is the default of keeping everything forever, which turns your evidence layer into a liability layer: data you hold is data you must protect and produce.

Who may query the trail

Access is the question that decides whether your reviewers trust the trail or fear it. Auditors: yes, that is the point. Managers running the quality review and escape traces: yes, through the defined cadence. Ad-hoc curiosity about how many overrides a particular reviewer made last month: no. The people lessons in this program drew the line and it holds here with force: measure the SYSTEM, and discipline people by policy, not by fishing. A decision trail that becomes a surveillance tool on reviewers will be defeated by the reviewers, quietly and completely, through defensive reviewing, minimal reason codes, and pressure to remove the very fields that protect them. Write the access rules next to the retention rules: named roles, defined purposes, and the principle that queries about individuals go through the same evidence-based performance process everything else does. The trail exists to answer for decisions, not to ambush the people who made them; field six, remember, is as often the reviewer's shield as anyone's sword.

The regulatory floor is rising on a published calendar

Everything above is worth building for your own operational reasons, and the regulatory clock is running anyway. The EU AI Act's obligations arrive on dates, not vibes: general-purpose AI (GPAI) obligations have applied since August 2, 2025; transparency obligations for AI-generated content arrive December 2, 2026; high-risk obligations for Annex III use cases, which carry explicit documentation, record-keeping, and human-oversight requirements, arrive December 2, 2027; and requirements for AI embedded in regulated products under Annex I follow on August 2, 2028. Here is the practical comfort: for most operations workflows, the trail this lesson designs already exceeds the floor those documentation and record-keeping provisions set. Build the Decision Record standard once for your own audits and disputes, and compliance arrives largely included, instead of as a separate panicked project in late 2027. The Level 4 governance program will formalize this into a management system with owners and evidence calendars; what you build now is the layer it will formalize.

What the trail buys beyond defense

Do not let the courtroom framing shrink this artifact, because the affirmative uses pay for it even if no authority ever calls. Dispute resolution in minutes: the vendor who claims their invoice was mishandled gets a factual walk-through instead of a negotiation, and most such disputes end at the walk-through. Reviewer development: the trail shows exactly where judgment diverges from the standard and from peers, which is coaching material of the highest grade, handled through the trust rules above. And the improvement loop: every override reason code, every escape trace, every retrieval-test failure is raw material for making the workflow better, which is where this chapter's closing lesson will take you. The same six fields that defend last year's decisions are the dataset that improves next year's.

One bridge before the Monday list. The trail answers for decisions one at a time. But sometimes the retrieval test, or an escape trace, or the drift watch shows you something worse: the trail reveals that something went wrong at SCALE, across a week of decisions or an entire segment. At that point you are no longer documenting; you are responding to an incident, and improvisation is the enemy. That is the next lesson: the incident playbook for when the AI step breaks.

What to Do Monday Morning

1. Run the retrieval test on your live workflow. Pull three random AI-touched decisions from the last quarter and reconstruct all six fields for each, with a stopwatch. Record the times honestly; anything over 30 minutes, or any field that comes back empty, is your finding.
2. Add the version stamp to whichever field failed. In most first runs it is field two: decisions are not stamped with model, prompt, and config versions. That is usually a one-line change in the workflow configuration and the single highest-value fix on this page.
3. Write the six-field standard into the SOP's records section. One page: the six fields, where each lives (event log, decision store, document registry), and the quarterly retrieval test with its 30-minute target and its reporting line into the quality review.
4. Set retention and query-access rules with your privacy or records owner. One retention period per workflow aligned to your existing obligations, named roles for access, defined purposes, and the explicit rule that the trail is not queried to fish on individual reviewers.
5. File this quarter's fairness check sheet where the trail can cite it. Give it a date and a registry entry, so that field six of any decision in a mitigation lane can point to it. Evidence that cannot be cited by the record that needs it is evidence in theory only.

Key Takeaways

• Expect the question "walk me through how this decision was made" from five directions (auditor, disputing customer, regulator, litigator, your own quality review), and accept that in an AI-assisted process the answer must be reconstructed from designed records, because the model cannot testify and hindsight rewrites memory.
• Distinguish the two layers cleanly: the agent's action log records what systems did, at reconstruction standard; the audit trail records how decisions were made, and it sits above the action log and cites it.
• Build the Decision Record standard's six fields for every AI-touched decision: inputs as seen (snapshots, never live references), the AI contribution with a model-prompt-config version stamp, the human judgment with reason code and Gate Spec version, the outcome and downstream events, the governing policy context, and the exceptions and overrides around it.
• Prove the trail with the quarterly retrieval test: three random decisions per workflow, all six fields reconstructed in 30 minutes each, results to the quality review; a trail that takes days to retrieve exists in theory only, and the test doubles as your audit rehearsal.
• Assemble the trail from systems you already own: the ticketing system as decision store, the event log, and the document registry, joined by IDs; the missing ingredient in most organizations is three design decisions at launch, not new software.
• Set retention and access as one-time policy decisions: retention aligned to your existing document and privacy obligations, access limited to auditors and defined quality purposes, and never let the trail become a fishing tool on reviewers, because measured systems improve and surveilled reviewers retreat.
• Treat the EU AI Act calendar as a floor you already clear: transparency obligations December 2, 2026, Annex III high-risk record-keeping December 2, 2027, Annex I embedded August 2, 2028; a trail built for your own operations arrives at compliance largely included.
• Use the trail affirmatively, not just defensively: disputes deflate on contact with records, override patterns become coaching material under the trust rules, and the six fields are the raw dataset for the improvement loop this chapter closes with.