The letter is four paragraphs long and entirely routine. A regulator, following up on a consumer complaint, asks a healthcare services firm to explain one automated eligibility decision made fourteen months earlier: what the system considered, who reviewed it, which model version produced it, and what evidence exists that the fairness controls the firm described in its own policy actually operated at the time. Nothing in the letter is hostile or surprising. Everything it asks for exists, somewhere, because this firm did the work: the decision was logged, the gate operated, the model version was recorded, the fairness check was run. Nine weeks later the answer goes out, complete and correct, having consumed roughly a quarter of the AI program's senior capacity for two months and pushed the year's delivery plan a full quarter to the right. Leadership's takeaway is that AI is expensive to govern. The actual finding is narrower and far more useful: the firm had evidence. It did not have an evidence layer.

The Archaeology Tax

Watch how those nine weeks were spent, because the shape of the cost is the whole lesson. Almost none of it was analysis. It was archaeology.

Week one went to establishing which system made the decision, because the complaint's case number mapped to a business process and two systems touched that process. Weeks two and three went to the decision record, which existed but referenced a model version by an internal identifier meaningless outside the data science team, whose lead had left eleven months earlier. Week four found the version mapping in a spreadsheet on a departed employee's drive. Weeks five and six went to the oversight gate: the approval was captured, but the review standard in force that day had been superseded twice, and establishing which version applied meant tracing policy amendments through committee minutes. Weeks seven and eight went to the fairness check, which had definitely been run, which everybody remembered discussing, and whose only surviving artifact was a calendar invitation and a manager's recollection. Week nine went to writing four pages.

Three senior people gave partial attention throughout. Nobody did anything wrong and every control had operated. The failure was not diligence but architecture: the evidence sat in seven systems owned by five functions under four retention regimes, discoverable only by whoever remembered where it lived, and two of those people had left.

Call this the archaeology tax. It is charged at the worst possible moment, without warning, on your scarcest people, and it scales with the age of the question. A decision from last month costs an afternoon. A decision from fourteen months ago costs nine weeks, because memory has decayed, staff have moved, systems have been upgraded, and the informal knowledge that substituted for structure has evaporated. It is invisible until charged, which is why it never gets budgeted for.

Which is the reframe that makes the case: the evidence layer is not built for the inquiry. It is built so the inquiry costs an afternoon.

Evidence Without an Evidence Layer

By this point your organization is a prolific producer of evidence. Level 3 gave you the decision record standard (six fields on every AI-touched decision, tested by whether a colleague can reconstruct it from the record alone) and the agent action log with its reconstruction standard. Level 4 gave you the regulatory readiness register and the artifact map tying obligations to the documents that satisfy them. Earlier in this chapter came policy architecture, the compliance program, responsible-AI controls, and vendor dossiers. Add gate specs, quality regime outputs, fairness sheets, governance minutes, model and prompt versions, incident postmortems, and test results, and the honest picture is an organization producing more documentation about its AI than most of its peers and unable to find any of it under time pressure.

That is the enterprise problem in one sentence. Evidence production is solved. Evidence architecture is not.

The distinction matters because the remedies are opposite. If evidence is not produced, you fix controls: add a field, a log, a gate. If it is produced but not architected, adding controls makes things worse, because you have increased the volume scattered across systems nobody has indexed. Many programs answer an audit finding by creating another document in another place, which is the governance equivalent of fixing a messy garage by buying shelves for a different room.

The one property worth designing for

An evidence layer is defined not by what it contains but by a single property, and every architecture decision here exists to produce it.

Any consumer's question can be answered by retrieval rather than by reconstruction, within a stated time, by someone who was not personally involved.

Each clause works. Retrieval rather than reconstruction means the answer is found, not assembled from fragments and memory. Within a stated time means a committed number, which forces the design to be real; an untimed capability is a hope. By someone who was not personally involved is the hardest and most valuable clause, because it converts an unpredictable, senior-person-consuming activity into a routine, delegable one. If the only person who can answer the regulator is the person who built the system, you do not have an evidence layer, you have a dependency on one employee's memory and continued employment. Designing for the uninvolved retriever is not an efficiency preference: it is the only design robust to normal staff turnover, as those nine weeks demonstrated.

The artifact: the Evidence Layer Design

The deliverable is a document you can write in a fortnight and maintain for years. The Evidence Layer Design has five parts, built in order through the rest of the lesson:

1. The six evidence classes, each with its contents, its single system of record, and who asks for it.
2. Retention and legal-hold rules per class, aligned to the records policy you already have.
3. Access and segregation rules: who retrieves what, by which path, and what the layer must never be used for.
4. The index, keyed on system identifier and date, that ties the classes together without moving any data.
5. The standing retrieval drill: quarterly, timed, run by someone uninvolved, and the layer's only honest metric.

Note what is not on that list: a new repository. The next section but one explains why the index beats the warehouse every time.

The Six Evidence Classes

Everything your program produces sorts into six classes. This is not housekeeping: each class has a different owner, different retention economics, a different consumer, and a different failure mode. Treat evidence as one undifferentiated pile and you end up applying the cheapest class's retention rules to the most important one.

1. System evidence: what each AI system is and does

This class answers the first question every outside party asks: what do you actually run? It holds register entries, risk classifications, the dependency stack (which model, which vendor, which data sources, which downstream systems), named ownership, and lifecycle status.

The system of record is the AI register, and the rule is blunt: one register, not several. Most enterprises discover they have three partial ones. IT keeps an application inventory capturing AI systems as software assets, with vendor and hosting detail but no risk classification. Risk keeps a list assembled for a regulatory exercise, accurate at classification and stale elsewhere. The AI program keeps a portfolio tracker, current and rich but scoped to initiatives it sponsored, missing every AI feature that arrived inside tools the business already owned. None is wrong; together they guarantee that "how many AI systems do you have?" depends on who you ask, which is the worst answer to give a regulator.

Consolidation is a one-quarter project with permanent returns: reconcile the lists, agree one owner and one schema, retire the others as sources of truth, and feed the survivor from existing systems rather than by manual re-entry. It is the precondition for everything else here: the register's system identifier is the key the whole index is built on.

2. Design evidence: why the system is built as it is

This class holds risk assessments, oversight design, gate specifications, handoff contracts, schema definitions, and the tradeoffs recorded at design time: why this threshold, why human review here and not there, why this data was excluded, what alternatives were rejected and why.

It is requested whenever anyone questions a design choice, most sharply after an incident. The question is never "was the design reasonable?" in the abstract but "was this choice made deliberately, with the risk understood, by someone accountable, before the harm?" A recorded tradeoff, dated and attributed, answers that. A design with no recorded rationale looks like an accident even when it was carefully considered, and after an incident, looking like an accident is expensive.

3. Operating evidence: what actually happened

The running record of the system in use: decision records, agent action logs, override logs, sampling results, monitoring outputs, canary histories. It is the highest-volume class with the hardest retention economics: a system making thousands of decisions a day generates a corpus nobody wants to keep in full forever and nobody is comfortable deleting.

The answer is tiering, aligned to the retention rules already governing the underlying business records rather than invented as a separate AI regime. If the credit file must be kept seven years, the AI decision record attached to it inherits that period; it does not get a shorter one for living in a different database. Within that envelope, keep full individual records for a defined period (24 months is a common landing point) and summarize thereafter, preserving the ability to reconstruct patterns, rates, and distributions even where individual items are no longer held in full. The test: after the full-fidelity window you can still answer "what was this system's override rate that quarter, and did it drift?" even if you cannot produce every individual case.

4. Assurance evidence: that controls actually operated

This is the class programs most often miss, and the distinction underneath it is the one auditors care about most:

Evidence that a control exists is design evidence. Evidence that the control operated on a given date is assurance evidence. Only the second answers the question an auditor is actually asking.

A beautifully written gate specification proves you designed a gate. It proves nothing about whether the gate operated in March. Assurance evidence is the operating proof: dated test results, calibration records, fairness sheets with the period they cover, audit samples, control-operation attestations, drill records. In the failure story the fairness check had genuinely been run; no artifact proved it ran that quarter, so for evidentiary purposes it had not. A control that operates and cannot be demonstrated is identical to one that did not operate.

The remedy is small and specific: every control whose evidence lives in someone's memory gets a filing requirement written into the control itself. Not "run the fairness check quarterly" but "run the fairness check quarterly and file the signed sheet to that system's assurance folder within five working days." Filing is part of the control, and a control without it is a control you cannot prove.

5. Governance evidence: decisions and their basis

This class holds committee minutes with decision rationale, gate outcomes, exception approvals with expiry dates, policy versions and amendment history, and risk acceptances naming who accepted them. It matters because accountability stays human, and this is where that principle becomes checkable: every material AI decision traces to a named person who made it on a recorded date on a stated basis.

The characteristic failure is not production but indexing. Committees keep minutes by habit, so the evidence exists; minutes are organized by meeting date rather than by system, so "what did governance decide about system X?" becomes a text search across eighteen months of documents run by whoever recalls roughly which quarter it came up. The fix is mechanical: tag every governance decision with the system identifiers it touches at the moment it is minuted. Ten seconds for the secretary, an afternoon for the retriever.

6. Change evidence: what changed and when

The last class contains model and prompt versions, configuration changes, SOP (standard operating procedure) versions, vendor notifications of their own changes, and the re-test results that accompanied each change.

Change evidence makes all the others interpretable. An operating record tells you what a system decided; without knowing which version produced it, that record is nearly useless. Was this an error the current system would still make? Did the override rate rise because behaviour changed or because someone edited a prompt? Did the vendor's silent update land before or after the complaint? Each is unanswerable without a version stamp and answerable in minutes with one.

Which gives you the highest-leverage field in the entire layer: the version identifier stamped on every operating record. If you do one thing from this lesson before the register consolidation, before the index, before the drill, make it that stamp. It costs a field, and it is the difference between records that support a defence and records that merely prove something happened.

The Three Architecture Decisions

With the classes named, three decisions determine whether the layer works. Each has an obvious wrong answer that costs a year.

Build the index, not the repository

The intuitive design is a central AI evidence repository: one place, everything copied in, one search bar. It demos well and fails on three grounds.

It fails on volume: operating evidence at enterprise scale is enormous, and duplicating it doubles storage, the surface to secure, and the retention obligation. It fails on ownership: the operations, risk, IT, and legal functions that own these systems do not want a second copy of their records outside their control, and that objection is correct rather than territorial. It fails on system-of-record integrity: the moment a copy exists there are two versions of the truth, and the copy will lag. An auditor who finds two versions of one record has found a control weakness you built deliberately.

The alternative is cheap and works. Leave evidence where it lives and build an index: a thin catalogue recording, for every evidence set, its system identifier, evidence class, period covered, system of record, a stable pointer or query, its owner, and its retention rule. Metadata, not content, small enough to run in a database you already own.

That buys the one query that makes retrieval possible: "show me everything about system X in Q3" becomes a single lookup returning locations across every class, instead of six conversations with six functions. Keying on system identifier and date is what makes it work, which is why register consolidation is a prerequisite. If your systems carry three identifiers in three registers, the index has nothing to key on.

Align retention, and check that legal hold actually reaches you

The strong default is to align to the records policy you already have rather than write an AI-specific one. Your records function has spent years mapping statutory retention to business record types, and AI evidence is almost always derivative of a record already covered. Inheriting is faster, defensible, and avoids your AI logs being destroyed while the underlying case file lives on, or the reverse.

Three AI-specific additions need writing down, because the existing policy will not anticipate them:

• Derived data and indexes inherit classification. An index entry pointing at a record containing PII (personally identifiable information) is itself sensitive, and embeddings, feature stores, and summarized extracts inherit their source's classification rather than defaulting to unclassified because they look like technical artifacts.
• Model and prompt versions must outlive the decisions they produced. If a decision record is held seven years, the version that produced it must be retrievable for seven years, or the record becomes uninterpretable exactly when it matters. This routinely breaks, because model artifacts sit in engineering environments with cleanup policies measured in months.
• Legal hold must actually reach these systems. This is the one to check first.

Take the specific question to your general counsel's office and ask it in these words: if a litigation hold is placed on a matter, do our AI decision logs, agent action logs, and model version records get held? The answer is frequently no, not through negligence but because the hold mechanism was mapped to email, document stores, and the systems of record that existed when the mapping was done, and nobody updated it once AI systems began producing legally relevant records. A hold that misses your logs means retention automation may destroy material you were obliged to preserve, converting a manageable dispute into a spoliation problem. Half a day, and the highest-return half day here.

Define access, and keep the layer out of surveillance

The third decision is who retrieves what, and it has three parts.

Defined access paths for external parties. Auditors and regulators get a named route: who they ask, what they receive, in what form, with what review before release. Ad hoc access, where an auditor is handed a production login because it was fastest, creates its own control findings. A defined path also lets you measure the layer, since every external request becomes a timed retrieval.

The layer must not become an employee-surveillance tool. This follows from the worker-trust rules established earlier in the program, and it needs an explicit written boundary because the technical capability is genuinely there. Override and action logs contain individual employees' decisions. Used for their intended purpose (quality, calibration, incident reconstruction, control assurance) they are legitimate. Used to rank individuals on override frequency or build performance cases, they poison the honest logging the whole layer depends on: people who believe the log will be used against them stop recording ambiguity, stop overriding when they should, and start writing records that are technically true and substantively empty. State the permitted uses, state the prohibited ones, and say so publicly to the people being logged.

The program uses the same layer for its own work. This is the sustaining insight. A layer touched only during audits decays invisibly: pointers break, owners change, systems migrate, and nobody finds out until the next inquiry. A layer the program opens weekly (to investigate a quality signal, prepare a gate review, check what changed before an incident, pull last quarter's sampling results) stays accurate because errors surface in ordinary business, when fixing them costs ten minutes rather than nine weeks. Give your own people a reason to open it every week, or accept that you are maintaining a document nobody reads.

The Retrieval Drill and What It Proves

Every claim in the Evidence Layer Design is a hypothesis until someone tests it under a clock. The retrieval drill is that test, and it descends from two things you already know: the do-it test, which asks whether a person can perform the documented step rather than whether the document exists, and the decision record's retrieval test, which asks whether a colleague can reconstruct a decision from the record alone. Grown to enterprise scale, they become this.

Quarterly, someone uninvolved is handed a realistic question and a stopwatch. Three questions, drawn from different evidence classes. Good ones look like:

• "Reconstruct decision X: what the system considered, which version produced it, who reviewed it, and against what standard."
• "Produce every operating record for system Y in the last quarter, and tell me the override rate."
• "Show me the assurance evidence that control Z operated in March."

The retriever must be genuinely uninvolved: not the system owner, not the index's builder, ideally someone from another function with an auditor's access and none of the institutional memory. The clock runs from question to complete, sourced answer. Those times are the layer's only honest metric. Not documents indexed, not systems registered. Time to answer, by someone who was not there.

The first drill always fails somewhere

Expect it and budget for it. The first drill fails because the layer was designed on how the organization believes its evidence works, and the drill measures how it actually works. The gap holds the same surprises every time: a pointer to a decommissioned system, an identifier meaning two things in two registers, a control everyone believed produced a record that produces only a calendar entry, an owner who left. These are not embarrassments. They are the design backlog, delivered for free, in an hour, at zero external cost. The alternative way to discover them is a regulator's letter and nine weeks.

Worked example: one enterprise builds the layer

Here is the arc with illustrative numbers, following the enterprise storyline this level has tracked. Every figure is hypothetical: the shape transfers, not the arithmetic.

Quarter one, the register. Counting registers finds three: IT's application inventory (61 entries, 19 flagged as AI-touched), risk's regulatory list (24 entries, well classified, eight months stale), and the program's portfolio tracker (31 entries, current, missing every AI feature bundled inside an existing platform). Reconciliation yields 38 distinct AI-touched systems, 6 of which appeared on no list at all. One owner, one schema, the other two lists retired as sources of truth and rebuilt as views. Cost: roughly a quarter of two people's time.

Quarter one, the index. Keyed on system identifier and date, tying seven systems of record (case management, the register, the governance document store, the assurance repository, MLOps version control, ticketing, and the minute archive) without moving a record. Build effort in weeks, not quarters, because it holds metadata only.

Retention. Agreed with the records function rather than invented: full operating records held 24 months and summarized thereafter, model and prompt versions retained for the life of the decisions they produced plus the statutory period, index entries inheriting the classification of what they point at.

The legal-hold gap. The half-day conversation with legal finds the hold mechanism reaches email, the document management system, and three core business platforms, and does not reach the AI decision logs or the model version store. Closing it takes six weeks of unglamorous work and is, in the program's later assessment, the exercise's most valuable finding.

Drill one. Three questions, one uninvolved retriever from internal audit, a stopwatch. Reconstruct a specific decision: 26 minutes. All operating records for one system in a quarter plus its override rate: 19 minutes. Assurance evidence that the fairness check operated in a given quarter: failed entirely, because the check had been run, everyone remembered it, and the only artifacts were a calendar entry and a recollection. That drives a filing requirement into the control plus a sweep for others with the same defect. Four more have it.

Drill two, three months later. Three new questions, a different uninvolved retriever, all three answered, median time 22 minutes.

The honest reading: the layer did not become perfect, it became measurable. The program can now say, with evidence, that a typical question is answered in about twenty minutes by someone who was not involved. That sentence is worth more in a board meeting than any maturity score.

The commercial dividend

Then the unplanned part. Eight months in, a large enterprise customer sends a combined security and AI questionnaire with a renewal: 90 questions covering system inventory, model provenance, human oversight, testing, incident history, and subprocessor dependencies. The previous one took six weeks and eleven people. This one is answered in four days, because the questions map almost exactly onto the six evidence classes and the answers are retrieved rather than reconstructed. The account team notices they can now commit to a response time in the contract.

This is the argument that gets the layer funded, and it must be made explicitly, because "we should answer regulators faster" is a cost story and cost stories lose budget fights. The layer is one build serving five consumers: internal audit, external audit, regulators, enterprise customers in procurement, and the program's own quality and incident work. Any one alone is a hard sell; together they make it obvious. The direction of travel is one way: the EU AI Act's calendar keeps raising documentation expectations by date (general-purpose AI obligations live since August 2, 2025, AI-content transparency from December 2, 2026, high-risk Annex III from December 2, 2027, embedded Annex I from August 2, 2028), enterprise procurement is converging on the same questions ahead of the regulators, and Gartner's projection that over 40 percent of agentic AI projects will be canceled by the end of 2027 for inadequate controls and unclear value describes a market where demonstrable control is a differentiator, not a formality.

Keep it calibrated. MIT's finding that 95 percent of enterprise generative AI pilots produce no measurable P&L return is not solved by record keeping. The layer does not create value; it protects the value you created from the archaeology tax and lets you prove that value exists. Different jobs, both necessary.

With that, the chapter closes. Policy architecture gave your program its rules, the compliance program a calendar and an owner, responsible-AI controls the practices that make outcomes defensible, dependency work a clear view of what it stands on, and the evidence layer the ability to prove all of it to anyone who asks: together, the enterprise's governance and trust foundation. Chapter 5.4 turns from the systems to the organization itself: the AI-era org chart, new roles and reporting lines, literacy at scale, culture, and the honest workforce conversation most programs postpone until it is too late to have well.

What to Do Monday Morning

Five moves, in order. The first two cost almost nothing and reliably surprise people.

1. Count how many AI registers your organization actually has, then start the consolidation. Ask IT for the application inventory, risk for the regulatory list, the program for its portfolio tracker, and reconcile them into one sheet. Systems appearing on only one list are your opening finding.
2. Ask your general counsel whether a legal hold reaches your AI logs and model versions. Use those words. If the answer is no or unclear, you have found the layer's most consequential gap in under an hour, and closing it is straightforward once someone has named it.
3. Build the index rather than centralizing the evidence. One row per evidence set: system identifier, class, period covered, system of record, pointer, owner, retention rule. Resist every suggestion to copy the evidence itself; the copy is where the project dies.
4. Add a filing requirement to any control whose evidence lives in someone's memory. Walk the control list and mark where each one's operating proof is filed. Every blank is an assurance gap. Amend the control text so filing is part of it, with a named location and a deadline.
5. Run your first retrieval drill. Three questions, one uninvolved person, a stopwatch, this quarter. Record the times and the failures without defending them. That failure list is the cheapest design backlog you will ever be handed.

Key Takeaways

• Distinguish evidence production from evidence architecture: mature programs produce decision records, gate specs, fairness sheets, and minutes and still pay a nine-week archaeology tax, because that material sits in a dozen systems discoverable only by whoever remembers where it lives.
• Design for one property: any question answered by retrieval rather than reconstruction, within a stated time, by someone who was not personally involved, because that last clause is what makes the capability survive staff turnover and become delegable.
• Sort evidence into six classes (system, design, operating, assurance, governance, change), each with a named system of record and a known consumer, because each has its own retention economics and characteristic failure.
• Hold the distinction auditors care about most: evidence that a control exists is design evidence, evidence that it operated on a given date is assurance evidence, and a control whose operating proof lives in someone's memory cannot be demonstrated at all.
• Stamp the version identifier on every operating record, because change evidence makes the other five classes interpretable and a decision record without its model or prompt version answers almost no question worth asking.
• Build an index keyed on system identifier and date rather than a central repository, since centralizing evidence fails on volume, ownership, and system-of-record integrity while indexing is cheap and turns "everything about system X in Q3" into one lookup.
• Ask legal whether a litigation hold actually reaches AI logs and model version stores, align retention to the existing records policy, and make derived data and indexes inherit their sources' classification.
• Prove the layer with a quarterly timed retrieval drill run by someone uninvolved, expect the first to fail somewhere, treat those failures as the design backlog, and fund the build as one asset serving five consumers rather than as an audit cost.