I dropped a car in for a heated seat that had stopped heating. Simple enough. I’d described the fault in the app, the booking had come back confirmed, and I turned up on the morning expecting the ordinary transaction of leaving keys with someone.

The man at the desk read his screen and his face did something I have thought about ever since. The booking in front of him was for a different repair entirely. He looked at it. He scrolled. He looked at it again. Then he said, half to himself and half to me:

“I think the AI got that one wrong.”

The part had already been ordered. And what I actually watched, in the four or five seconds that followed, was a competent person quietly clocking out of the problem. Not through indifference — through the complete absence of anything to argue with. What was he supposed to do? Overrule it? On what basis? He had a screen telling him one thing, a customer telling him another, and no way in the world to find out which of them was closer to the truth.

The failure isn’t the wrong answer

It is tempting to file that morning under “the AI made a mistake,” and it is the wrong file. Wrong answers are visible, arguable and correctable. Every system produces them, including the human systems that preceded this one; a service advisor who mis-keys a job code produces exactly the same wrong part order, and nobody writes a book about it.

The failure was something else, and it is worth naming precisely because everything in this book follows from it.

Had the system been right that morning — and on most mornings it presumably is — the man at the desk would have had exactly the same amount of evidence for trusting it, which is to say none. He was not evaluating a recommendation. He was receiving one. The difference between a brilliant diagnosis and a confident fabrication was, from where he stood, invisible.

What he had actually been handed

Look at the shape of his job now. The AI absorbed the common cases — the clean triage, the obvious fault, the booking that goes through without anyone thinking about it. What flowed to him was the residue: the misclassified ticket, the wrong part, the customer standing there with a reasonable question.

That is not triage. It is de-triage — repair of the repair process, apology labour for an invisible system. And it arrives with a phrase attached that is doing an enormous amount of unearned work.

And there is a second cruelty in it, which the human-factors literature named four decades before anyone shipped a language model. Lisanne Bainbridge’s 1983 paper Ironies of Automation reads like it was filed from a service centre. Automate the routine work, she observed, and you leave the operator “an arbitrary collection of tasks” — precisely the hard exceptions — while their skills quietly decay from disuse. “A formerly experienced operator who has been monitoring an automated process may now be an inexperienced one.”¹

The irony she was pointing at is the one that matters here. When manual take-over is needed, something has already gone wrong — so the operator “needs to be more rather than less skilled, and less rather than more loaded, than average.” Later empirical work named the same thing the out-of-the-loop performance problem: automation erodes situation awareness, leaving operators handicapped in their ability to take over manual operations when the automation fails.²

We deskill them, and then we hand them the hardest cases, under time pressure, in front of the customer. And we call it human oversight.

So ask the system why

This is the point where every governance conversation goes the same way. If the recommendation is questionable, ask the system to explain itself. Build for explainability. Make the reasoning visible. It sounds unarguable.

And the system will answer. Fluently, plausibly, reassuringly. It will produce a paragraph that sounds exactly like a competent colleague justifying a sensible decision, with the caveats in the right places and the confidence pitched just so.

Here is the trap, sitting in plain sight: that paragraph was generated after the decision, by the same system whose decision you are trying to audit.

It is not a record of what happened. It is a performance about what happened.

For a long time that was an intuition you could dismiss as excessive suspicion. It isn’t any more; it has been measured. Anthropic handed reasoning models hints that changed their answers, then checked whether the models mentioned the hint. Mostly they didn’t. And where models had exploited a reward hack, they admitted it in their stated reasoning less than 2% of the time.³

Independent work on chain-of-thought faithfulness reaches the same shape and gives the pathology a name. Verbalised reasoning “can give an incorrect picture of how models arrive at conclusions”; it “is not a complete account of the internal process that produced the model’s answer and should be used with caution in agentic or safety-critical settings.”⁴ The name is post-hoc rationalisation, and it is not an LLM-era discovery. Cynthia Rudin made the general argument in 2019: trying to explain black-box models, rather than creating models that are interpretable in the first place, “is likely to perpetuate bad practices and can potentially cause catastrophic harm to society.”⁵

I’ll put it less carefully than the papers do, because the careful version keeps letting people off the hook. You can’t look into an LLM’s brain and see all the crap it was looking at. Asking it afterwards is not a substitute. It is a re-enactment performed by an actor with an interest in the verdict.

How big is the gap, actually?

Big, and widening in the worst direction, because the nature of the risk changed at the same moment the controls didn’t. As McKinsey puts it, organisations “can no longer concern themselves only with AI systems saying the wrong thing; they must also contend with systems doing the wrong thing, such as taking unintended actions, misusing tools, or operating beyond appropriate guardrails.”⁶ Saying becomes doing. A wrong sentence becomes a wrong part, on a real van, with a real customer waiting.

One line of commentary and no more, because the numbers are not the argument. The gap isn’t ambition — organisations are deploying enthusiastically. The gap is evidence infrastructure, and evidence infrastructure is a build, not a policy. You cannot write your way to it in a framework document, and you cannot buy it as a dashboard.

Where governance has to live instead

If the narration can be a confident fiction, then governance cannot live inside the model. There is nowhere in there to put it. It has to live in something you can observe from the outside — something that exists independently of the system’s account of itself, and that was written down before anyone needed it.

Which narrows the field considerably. Not the model’s reasoning, because that is testimony. Not the output, because the output is what you are trying to evaluate. Not the input, because the same input produced both the brilliant and the fabricated version of that morning.

What’s left is what the agent actually read — the knowledge it consulted, or failed to consult, on the way to the recommendation. That is an external fact. It happened outside the model, in a system you own, and it can be recorded, restored and inspected.

That sentence sounds like an architecture preference. It is the entire argument of this book, and the next chapter is about why the two obvious candidates for that substrate — the model’s weights and your retrieval index — both fail the same test, in the same place, for the same reason.

An agent knows things in two ways. It knows things because they are compressed into its weights, and it knows things because something fetched them and put them in front of it at query time. That’s the whole inventory. Everything else — the tool call, the system prompt, the memory feature your vendor shipped last quarter — is a variation on one of those two.

Neither of them is a knowledge state. That distinction sounds pedantic and it is the hinge the rest of this book swings on, so it is worth being slow about.

Weights: no way in, no way back

The first source is the model itself. Everything it absorbed in training, compressed into a representation that is genuinely, structurally opaque to the operations governance needs to perform.

You cannot ask a model which of its priors fired. You cannot diff last month’s beliefs against this month’s. And when the vendor deprecates the version that made the decision you’re now defending — which they will, on their schedule, not yours — you cannot stand it back up to check.

I want to be fair to interpretability research here, because dismissing it cheaply weakens the argument. It is real, it is advancing, and some of it is remarkable. It is also not a control you can operate on a Tuesday against a decision made on a Monday by a system in production. Those are different timescales and different kinds of claim.

Query-time retrieval: better, and still not a record

The second source is retrieval. Embed the question, search, hand the model the nearest passages. And credit where it’s due — this is a genuinely brilliant trick, and it’s fast for exactly the reason that makes it brilliant: the thinking was already compressed into the embedding, so at query time there is nothing to do but compare distances. You also get something weights never gave you, which is a log. You can see the query. You can see what came back.

That is more than nothing. It is also not what an auditor needs, and it fails in three specific ways.

1. There is no versioned state to restore

Here is the failure nobody names, and it is the one that earns this book its title.

Your corpus moves — documents get added, edited, retired. Your chunker gets tuned. Your embedding model gets upgraded, and when it does, every vector in the store changes meaning slightly. Your reranker gets swapped. All of that is normal, healthy engineering.

Now try to answer the question an audit actually asks: restore the search as it stood on 17 June and show me what this agent could have found. That is not a supported operation. There is no commit to check out. There is no state to stand up. A log of what came back is a record of an event, not a reconstruction of the world that produced it — and if you cannot reconstruct the world, you cannot distinguish “the agent missed it” from “it wasn’t there.”

2. Distance carries no notion of status

In embedding space, “close to the idea” can quietly beat “the authoritative source of the idea.” A second-hand mention that happens to share the query’s vocabulary can outrank the page that defines the thing, and the agent cannot tell, because the embedding carries no notion of standing. Distance is all it has.

A wiki-graph encodes status natively. A page doesn’t just hold content; it holds its standing — this page defines the part, that one applies it, this one extends it, that one is stale, this one is deprecated but still binding on contracts signed before March. The edges carry the same information: first-hand versus second-hand, source versus commentary.

That is not a nicety. For governance it is the whole thing, because “did the agent consult the authoritative source?” is only a meaningful question in a system where authoritativeness is a recorded property rather than an accident of phrasing.

3. The quality lives inside machinery you can’t read

When retrieval returns the wrong thing, what exactly do you fix? Chunk size. Overlap. The embedding model. The reranker. A metadata filter. You change one, re-index, and re-test everything, because the change ripples through a representation no human can inspect. You are debugging a black box by poking inputs and squinting at outputs.

Chapter 5 turns that observation into an instrument, so I’ll leave it here as a statement. The point for now is that all three failures have the same root, and it isn’t effort or tuning.

RAG is intelligence hidden inside similarity. The wiki is intelligence externalised as structure.

The third thing

There is a third place knowledge can live, and I have argued its architecture at length elsewhere, so this is a summary rather than a derivation.

An ingestion agent reads sources one at a time and writes atomic claims and typed edges into a markdown graph. A janitor agent activates when pages bloat, consolidating redundant claims, converting prose into edges, fading stale material — governed by a broad North Star rather than a rulebook. Meaning migrates out of flat statements and into relationships, so the graph gets smaller and more useful over time. Retrieval becomes navigation of a prepared map rather than a crawl performed at the moment of the question. It sits at the top of the retrieval maturity ladder, where the binding constraint stops being model capability and starts being context architecture.

None of that is why it matters here. The economics, the token maths, the multi-hop accuracy — all interesting, all somebody else’s chapter. For governance there is exactly one property that counts:

Which gives you something odd and rather good: a map that behaves like soft weights. It conditions how the AI reasons about your domain the way a fine-tune would — but you can read it, edit it, and review the last maintenance pass in a pull request. The conditioning benefit of training, without the cost, the delay or the opacity.

Three substrates, four governance questions

Set them side by side against the questions an auditor actually asks, and the comparison stops being a matter of taste.

Four rows, and the same word in the first two columns. That is not a performance comparison. It is the observation that two of the three places your organisation’s knowledge currently lives are, for governance purposes, write-only.

A warning before anyone gets ahead of the argument

I can feel where this is going in some readers’ heads, so let me head it off now rather than at the end. This is not a migration argument. I am not telling you to rip out your vector store.

Substrate is a decision, not an allegiance. Two corpora owned by the same organisation routinely belong on opposite substrates, and the rule that tells you which is which gets a full chapter near the end. For now, hold this scope: everything that follows applies to the layer an agent traverses when it makes a consequential call — not to every byte your organisation retrieves.

What one design choice buys

Strip it back. The choice is: does the knowledge your agent reasons over live inside a model, inside an index, or in text under version control?

The model is not the memory. The wiki is the memory.

People think of AI learning as something that gets built into the LLM. I think the wiki — the edges, the graphs, the claims — is the real nature of what we need to do now: use AI to process record-level interactions into the wiki. Which has an imperative form worth putting on a wall.

Do not teach the LLM in its weights. Teach the organisation in its graph.

Make that one choice and governance stops being interrogation and becomes replay. You stop asking the system to account for itself and start restoring the conditions it acted under.

That capability deserves a name, and a precise one. Next chapter.

Explainability asks the model to narrate. Cognitive provenance asks the system to produce the knowledge path.

One is testimony from the defendant. The other is the evidence room. They are not two flavours of the same control; they are different categories of thing, and conflating them is why so many AI governance programmes feel thorough and prove nothing.

That is the difference between explainability and cognitive provenance.

The definition, and why every clause is doing work

Exactly, not approximately — not “documents similar to these.” Observed, not available: the fact that a page existed in the corpus is a fact about your corpus, not about the decision. At decision time, not now, because the graph has moved since and the version that mattered is the one that was live. External, because anything inferred from the model is testimony again. Version-pinned to a commit rather than a date, because dates are ambiguous and commits are not. And restorable, meaning you can actually stand it up again — not that you have a description of it.

Every one of those clauses is somewhere an implementation quietly fails, and each failure leaves you with something that looks like provenance in a slide and evaporates in a review.

What does it let you actually ask?

Here is the practical difference. With knowledge in weights, none of the following questions has an answer. With a version-controlled graph, all eight of them do.

1. Which pages were retrieved?
2. Which claims were observed?
3. Which edges were traversed?
4. Which version of the memory was current?
5. Which claims were available but not used?
6. Which proposals were rejected?
7. Which gates passed or failed?
8. Which human or deterministic gate authorised the final action?

Dwell on the fifth for a moment, because it changes the character of the artefact. A knowledge path tells you both what the agent touched and what it ignored.

That is the difference between a story and an audit. A story is a sequence of things that happened. An audit is a sequence of things that happened and the things that should have and didn’t. Every plausible narrative in the world is the first kind. Only a record with absences in it is the second.

The mechanism: three pins, not one

The machinery is unglamorous, which is the point. Restore the wiki commit that was live at decision time. Restore the DAG or policy version. Restore the agent version. Then re-run.

All three, not one. The wiki alone tells you what was knowable; the DAG version tells you what the gates were; the agent version tells you what was doing the walking. Pin one and you have a fact. Pin three and you have a re-runnable world.

If you manage the wiki with Git, you can rewind it to that point in time — to that snapshot — and see exactly what the AI was looking at and how the wiki was constructed. You can’t do that with knowledge baked into an LLM. The audit request stops being a conversation and becomes a procedure:

restore wiki commit hash
restore policy / DAG version
restore prompt / agent version
restore source permissions
restore observed case data
replay proposal generation
compare accepted and rejected proposals
inspect whether the agent read the relevant edge

In governed agentic AI, the path through knowledge is part of the decision.

Which is the sentence that reframes the whole tool-call layer. Retrieval calls are not plumbing to be logged for debugging. They are the substance of the cognition, and the record of them is the only externally verifiable thing the decision produced. The wiki is not just memory. It is inspectable cognition.

None of this is exotic — we already do it one layer down

If this feels like a lot of new discipline, notice that your engineering organisation already practises it, twice.

You version code in Git so that a bug report can be tied to the exact source that produced it. You version data, models and intermediate artefacts in tools like DVC for the same reason: so a model can be traced back to its exact training data via commit hashes, which matters most in regulated industries where audit trails are essential for compliance.⁹

Nobody thinks versioning training data is avant-garde. Cognitive provenance is the same instinct applied one layer up — to the claims and edges the agent reads at decision time. The move is small. It only looks novel because the knowledge layer was never treated as engineering in the first place; it was treated as content.

Regulation describes the capability. It doesn’t give you the knowledge dimension.

There is a tailwind here, and I want to state it as a tailwind rather than turn this into a compliance pitch.

EU AI Act Article 12 requires that “high-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system,” with high-risk obligations applying from 2 August 2026.¹⁰ The NIST AI Risk Management Framework asks for traceability and provenance attributable to defined human roles.¹¹ And the academic case for durable lifecycle ledgers is already made: an audit trail as “a chronological, tamper-evident, context-rich ledger of lifecycle events and decisions” that links technical provenance with governance records “so organizations can reconstruct what changed, when, and who authorized it.”¹²

What the agent consulted is the third nobody builds. It is also the third that separates a defensible decision from a lucky one, which is a claim I will make good on in the very next chapter.

What naming it doesn’t buy

The first edition of this argument, published in the middle of 2026, essentially stopped here. It named the capability, showed the mechanism, and left the reader to build it. That was incomplete in four specific ways, and the rest of this book is those four ways in order.

That is not hedging. It is a table of contents. A named capability with no instrument, one clock, no budget and no authority boundary is a concept; the point of this edition is to make it a practice.

And the first thing a practice needs is a failure it can detect — which turns out to be a failure most people would not think to look for, because it happens when the AI gets the answer right.

This one is a field note rather than a theory, and I think that’s why it convinced me.

The more you put in the wiki, the more you notice the model will sometimes bypass it and answer from its own knowledge. It gets the right answer — but if it never observed the right edge, the right claim, the right page, you can prove it hallucinated. You can now clearly state that it hallucinated, even though it was right.

I want to be honest about the epistemic status of that. I did not run a controlled study. I ran a system, watched its traces, and kept noticing the same shape. What makes it more than an anecdote is that the shape has an obvious mechanism and an uncomfortable trajectory: the richer the wiki gets, the more often it happens. A well-populated graph is exactly the condition under which the model’s own priors are also decent — you’ve compiled the same domain the internet already described. So the better your memory layer gets, the more opportunities the model has to skip it and still look competent.

A definition that never mentions correctness

Notice what that definition doesn’t say. It doesn’t say the answer was wrong. It doesn’t mention correctness at all — deliberately, because correctness is a property of the output and this is a property of the process.

The load-bearing words are the ones people skim. Material: not every incidental phrasing, only claims that carry the decision. Admissible: the knowledge your organisation says counts for this decision class, not everything that happens to exist. Actually observed: not available, not retrievable, not in the corpus — read.

Substantively right, procedurally unsupported.

Two paths, one recommendation

Here is the thing in its purest form. Same ticket in. Same recommendation out. Opposite governance posture.

And that last sentence is the whole problem. If you never recorded the path, the distinction between these two does not exist as a fact about your system. It exists only as a possibility you cannot rule out — which is a very uncomfortable thing to say in a room with an auditor in it.

Is this just our vocabulary?

No, and it matters that it isn’t, because the first time a model-risk function hears “procedural hallucination” they will reasonably ask whether you invented a problem to sell a solution.

The retrieval-attribution literature reached the same place from the other end. Citation correctness alone is insufficient; to establish trust in attributed answers you have to examine both correctness and faithfulness — and “faithfulness ensures that the model’s reliance on cited documents is genuine, reflecting actual reference use rather than superficial alignment with prior beliefs, which we call post-rationalization.”¹³

Groundedness in RAG evaluation is likewise defined strictly against the retrieved context, not external knowledge or the model’s parametric memory.¹⁴ Their version and ours describe the same object from different ends: they measure it inside a single answer, we govern it across a decision. Same failure, different unit of analysis.

Why a correct answer can be a latent failure

The obvious objection is the practical one: so what? The customer got the right part. The case closed. Where is the harm?

The harm is in the word “latent.” A correct-by-luck decision holds until the model’s internal knowledge diverges from organisational reality — and there is no warning signal, because nothing degrades gradually. It is fine, fine, fine, wrong.

None of those events announce themselves. All three land on a system that has been passing its tests, because its tests were graded on outputs and the outputs were right.

There is a compounding version too, and it is nastier. In a closed loop, the outcome writes back. A correct-by-luck decision that closes successfully teaches the loop that the shortcut worked — and the next agent inherits a map that has quietly learned to be bypassed.

What this lets an auditor say

Once you can see the path, sentences become available that were previously unsayable. Not because you have become more suspicious, but because you have acquired a fact.

• “This agent did not observe the required service-domain pages before recommending a non-obvious part.”
• “This agent observed the diagnostic pages but did not observe the customer-trust page.”
• “This agent observed all required pages, generated three proposals, rejected the cheaper two for explicit reasons, and accepted the higher-cost path to protect first-visit resolution.”

What those statements should do — fail, flag, or nominate for review — turns out to have a counterintuitive answer that has nothing to do with technology. That is Chapter 10, and getting it wrong is how systems like this die.

The half this book used to stop at

Naming a failure mode is the easy half. The first edition of this argument named it, defined it, gave it a memorable phrase, and left the reader holding a concept.

The hard half is operational, and it has two parts. How do you detect procedural hallucination at scale, without reading every decision by hand? And once you can see the path, how do you tell this failure apart from the three others that look nothing like it — because it turns out there are exactly four things that can happen, and output-grading can only ever see two of them?

Governance comes down to a new question: what wiki did it observe?

Answering that question at scale needs an instrument. Next chapter.

Picture two agents handed the same hard ticket. Both return the right recommendation.

The first read the canonical fault page, followed the occupancy-sensor edge, checked the model-year exception, and arrived. The second read three loosely-related passages, none of them canonical, and then guessed — and its guess happened to match what the model already believed from pre-training.

Same answer. From the outside, grading the output, you cannot tell them apart. One is genuine expertise. The other is a lucky guess from model priors wearing expertise’s clothes.

And the lucky one is the dangerous one. Not because it’s wrong today — it isn’t — but because it will keep passing your tests right up until the day the priors don’t hold, and then it will fail silently, on a case you can’t predict, with no way to have caught it in advance.

Move the test off the output and onto the journey

So stop asking only was the answer right? and start asking whether the agent travelled correctly to get there. Five questions, and every one of them is a concrete fact about a traversal rather than an opinion about an output.

1. Did it read the canonical source, or settle for a nearby mention?
2. Did it follow the edges a competent navigator would follow?
3. Did it avoid blind broad search when the graph should have been enough to walk?
4. Did it know when to stop, or keep dredging long after the map said it had what it needed?
5. Did it observe the claims that carry the organisation’s constraints — not only the ones that carry the answer?

That fifth question is the one I’d add to anyone else’s rubric, and it is the one most likely to catch a real problem. Constraint-bearing claims — the customer-trust page, the escalation rule, the “this repair looks unrelated unless you explain it” note — are precisely the material a model’s priors will never supply, because they are local to your organisation and were never on the internet. An agent can freelance the diagnosis. It cannot freelance your constraints.

The final answer is fuzzy and model-dependent: reword the prompt and it shifts. The path is concrete — a recorded sequence of pages and edges you can lay out and judge.

What are the four outcomes?

Grade both axes and something useful happens. The undifferentiated right/wrong splits into four distinct situations, each calling for a completely different fix.

Output-grading collapses all four into one undifferentiated verdict. The separation is the whole value — a reasoning failure, a navigation failure and a lucky guess each call for a completely different response, and the bottom-left cell, the one that grades as a pass, is the one most likely to hurt you later. You can only see it because the path was recorded.

Why is this a property of the substrate, not of diligence?

Because you cannot do it against a vector store, however conscientious you are.

Testing a vector store turns into a retrieval science project. The unit of the question is which query should return which chunk? — and when the answer comes back wrong, you’re left interrogating the machinery: was it the chunking strategy, the embedding model, the reranker, the metadata filter? You change one of them to fix one case, and now you have to re-index and re-test everything, because the change ripples through a representation no human can read.

Wiki testing has a surface a human can simply look at. Does the page summary make sense? Are the edges useful — do they point where a reader would actually want to go? Does the canonical source appear, or only second-hand mentions of it? Can the target user, arriving from their question, discover this page at all? Every one of those is a question you answer by reading, not by re-indexing.

RAG quality is hidden in the machinery. Wiki quality is visible on the page.

What you actually record

None of this is buildable from a principle, so here is the record itself. Keep it boring; the value is in completeness, not cleverness.

pin:               wiki@commit · dag@version · agent@version
opened:            [page, in order, with the query or edge that led to it]
traversed:         [typed edges, in order]
read_claims:       [claim ids actually consumed]
available_unread:  [claims in the retrieved neighbourhood not consumed]
entry_point:       how the walk started (routing index / search / direct)
fallbacks:         any broad-search fallback, and why it fired
stop_condition:    why the walk ended

Most of that is cheap. One field isn’t, and it is the one worth the engineering: available_unread. Computing it means knowing what was in the retrieved neighbourhood and comparing it to what was consumed, which is real work. It is also the only way to distinguish the map didn’t have it from the map had it and the agent walked past — two entirely different problems that produce identical logs in every system I have seen shipped.

Note also the split between opened and read_claims. Opening a page proves retrieval. Consuming a claim proves reading. They are not the same event, and Chapter 6 adds a third distinction on top of both.

The grading rubric

Five checks, most of them deterministic. That matters enormously for Chapter 9’s economics: anything a machine can compute is something you can run on every decision, and human attention gets reserved for what’s left.

The path is the cognition receipt

Which brings the instrument back to the argument. A recorded path is not a debugging artefact that happens to be useful for audit. It is the cognition receipt — the auditable record of what the agent actually knew, which is where governance and replay begin.

Everything Part III does with a governance trace depends on Part II having made the path a first-class object rather than a side effect of logging. If the path is something your observability stack happens to capture, it will be incomplete, unpinned and unresolvable at exactly the moment you need it. If it is a designed record, it is evidence.

Grade the answer and a lucky guess looks like expertise. Grade the path and the difference is right there on the page.

One catch remains, and it is a serious one. A recorded path is only evidence if every step in it can be opened. A list of page names is an assertion made by the system under audit — which is the exact category of thing Chapter 1 disqualified.

Your trace says the agent observed [[Heated Seat Failures]].

Who checked?

A page name in a log is an assertion by the system under audit. We spent Chapter 1 disqualifying the model’s story about its own reasoning; a page-name list is the model’s story about its own reading. Same defendant, shorter sentence, identical epistemic status.

This is the chapter where the argument gets harder on itself than any critic would, because the naive implementation of everything in Part II is very easy to ship and very hard to distinguish from the real thing until someone tries to use it.

The four-part evidence package

The fix is a format contract on every wire. Whatever crosses from one component to the next — sub-tool to agent, agent to reviewer, reviewer to forum — carries four things, not one.

Each one fails differently when it’s missing. A claim without an exhibit is an oracle speaking. An exhibit without a pointer is unverifiable — you have a quotation and no way to check it wasn’t assembled. A pointer that doesn’t resolve is worse than no pointer at all.

A dead pointer is a fake receipt — worse than none, because it buys trust it cannot redeem.

Which turns resolvability from a convention into an engineering requirement. Resolvability is a test that runs on a schedule, not a virtue people observe. If nobody has clicked a pointer in a month, you don’t have receipts — you have a formatting habit that nobody has audited.

And the fourth field, the one everybody drops. A component that declares its own uncertainty gives the next stage a gradient to follow: it lets expensive attention go exactly where the exhibits are thin. Without it every hop looks equally confident, and a reviewer facing forty uniformly assured statements has no way to prioritise. The confession is not modesty. It is routing information.

Oracles and witnesses, on one chain

The failure compounds down a chain, which is why the contract has to be on every wire rather than just the last one.

Now substitute the domain. Replace “this project uses Postgres for cost” with “occupancy sensor is the leading cause for this symptom cluster” and you have the shape of every service-AI decision that was ever defended with a page name. Somewhere in the chain a conditional pattern lost its conditions, and by the time it reached the parts order it was a rule.

The hardest thing you can say about a governance trace

Here is the criticism I want on the record, because it is the one that would land hardest if someone else made it.

They are complementary, and the relationship between them is the sharp bit: the witness convention is what makes a receipt’s “sources cited” field mean anything — otherwise that field is just another asserted claim.

So say the consequence plainly, about our own artefact: a governance trace whose observed-pages list carries no exhibits and no resolvable pointers is a receipt with a decorative sources field. It will look thorough in a screenshot. It will collapse the first time someone tries to open one.

What a witness convention doesn’t buy

The boundary, before anyone accuses us of overclaiming. A witness is checkable, not truthful. Quotes can be cherry-picked. An exhibit can be entirely real and still misleading in context. The convention doesn’t make the agent right — it makes it inspectable, which is a different and considerably more achievable thing.

The resolvable pointer is what turns “trust me” into “go look.” That is the entire claim. It is also more than almost any deployed system offers today, which is why a modest claim is worth making loudly.

Related, and worth one line: this is why a confidence score is not evidence. A confidence score is the system grading itself. Real trust is a receipt you can open.

Observation is not use

There is a second gap, and most implementations of everything in this book will miss it.

A page can be opened and ignored. opened proves retrieval. read_claims proves reading. Neither proves that the reading changed anything — and a system that ceremonially visits its required pages before recommending what it was always going to recommend satisfies every check in Chapter 5 while learning nothing.

The instrument that closes it is a participation receipt: a record not of what entered the context window, but of what entered the decision.

Three optional fields are worth the trouble: the counter-lens considered; the known absences (“we found no prior failure of this shape”); and confidence expressed as conditions rather than a self-awarded percentage.

“The wiki helped” is not a test.

The test is: this prior claim entered by this path, changed the work in this way, and this person accepted or rejected the transfer. That is a sentence someone can disagree with, which is the only property that makes a governance record worth keeping.

Record the absences

One more field, small and badly under-built.

A record that says the graph had nothing to say about software revision 2026.14 is more governable than one that silently omits it. The absence is a fact about the decision. Without it, an auditor has to discover the gap by accident — and if they do, everything else in the trace becomes suspect, because the record has been shown to be selective about what it reports.

Absences are also the janitor’s work queue. Every recorded “we had nothing on this” is a precise instruction about where the map is thin, generated by real demand rather than by someone’s intuition about what ought to be documented. Significance without a pointer is marketing, not memory; and an absence with a pointer to the question that exposed it is the cheapest map improvement you will ever get.

The artefact is now specified well enough to build: pinned in Chapter 3, gradeable in Chapter 5, resolvable and effect-bearing here. Time to look at one, complete, for a real decision.

Back to the heated seat.

The complaint is simple: the driver’s seat doesn’t heat. The likely cause is not. On a good number of these, the fault is upstream — an occupancy sensor that has decided nobody is sitting in the seat, so the heater never arms. Replace the sensor and the heat comes back.

Which means the correct repair looks, to the customer, like the workshop ordering the wrong part. They said the seat doesn’t heat; you’re ordering a sensor. Non-obvious repair path, high trust risk, and — the reason it is the right worked example for this book — a decision where being right is not remotely the same thing as being defensible.

The service product around this case is a different book. Here it is a specimen.

How the loop produces a trace

Compressed, because the engine was Chapter 2 and the pin was Chapter 3. Closed cases compile into the graph — ingestion writes claims and typed edges, the janitor compacts them. The agent walks the graph and generates candidate service plans. A deterministic graph evaluates each one against nodes most organisations would never think to include:

• Can the customer understand why this recommendation makes sense?
• Can the concierge defend it without faking expertise?
• Does this create a likely second visit?
• Does the cheaper path spend customer trust?
• Does the accepted proposal explain why the cheaper ones were rejected?

Failed proposals go back for repair rather than straight to a human. Accepted proposals execute. The outcome writes back into the graph.

The artefact

This is the thing to picture. Everything abstract in this book resolves into it.

Case:          Heated driver seat complaint
Vehicle:       Model 3 RWD, 2023

Pins
  wiki snapshot:   service-wiki@a83f21c
  DAG version:     service-triage-dag@2026.06.17
  agent version:   triage-agent@1.8.2

Observed pages — claim · exhibit · resolvable pointer
  [[Heated Seat Failures]]
    claim:   occupancy detection is a common upstream cause
    exhibit: "…intermittent driver-presence detection can suppress
              seat-heater activation on 2023 seat modules."
    pointer: wiki/heated-seat-failures.md@a83f21c#L44
  [[Driver Occupancy Sensor]]                  → wiki/occupancy-sensor.md@a83f21c#L12
  [[Model 3 Seat Module]]                      → wiki/m3-seat-module.md@a83f21c#L61
  [[First Visit Resolution]]                   → wiki/first-visit-resolution.md@a83f21c#L8
  [[Customer Confusion: Non-obvious Repairs]]  → wiki/non-obvious.md@a83f21c#L23

Traversed edges
  heated-seat-complaint    -possible-upstream-cause->  occupancy-sensor
  occupancy-sensor-fault   -can-disable->              heated-seat-activation
  non-obvious-repair-path  -requires->                 customer-facing-explanation
  high-return-visit-risk   -consider->                 backup-part-staging

Available, not observed
  [[Seat Harness Corrosion, Coastal]]   (in neighbourhood, unread)

Known absences
  no claim covering software revision 2026.14 seat-heater logic

Stop condition
  constraint claims covered; no unread edge above relevance threshold

Candidate proposals
  A. Occupancy sensor only
     FAIL customer-explanation    · note absent
     FAIL first-visit-resolution  · return-visit risk medium
  B. Heated-seat element only
     FAIL diagnostic-evidence     · weak against remote signal
  C. Occupancy sensor + stage heated-seat element
     PASS diagnostic-evidence · PASS customer-trust · PASS front-desk-explainability
     concierge note generated

Accepted:          C
Effect on work:    [[First Visit Resolution]] moved the recommendation A → C
Confession:        could not verify current stock latency for the element
Customer note:     "Occupancy sensor can affect heated-seat activation; we'll check
                    this first and verify the heater circuit while the car is here."
Human disposition: accepted by service-lead@site-14 under standing delegation

Six of those blocks did not exist in the first edition of this artefact, and they are exactly the difference between a plausible list and a record. The exhibits and pointers come from Chapter 6 — without them the observed-pages list is an assertion. Available-not-observed and known absences come from Chapters 3 and 6 — they are what turn a story into an audit. Effect on work proves the reading changed the recommendation rather than decorating it. The confession tells the next reader where to spend attention. And the stop condition makes the walk gradeable rather than merely visible.

What does this give an auditor that a log can’t?

Three things, and they are worth separating because organisations tend to have one and assume they have all three.

The efficiency manager arrives, six months later

Nothing in the artefact earns its keep at the moment of the decision. It earns its keep the first time someone reviews the parts budget and asks a perfectly reasonable question: why is the AI ordering the occupancy sensor and the heating element?

That is the difference between waste and strategy. Without the receipt, management sees “AI is over-ordering parts.” With it, management sees “AI is deliberately rejecting lower-cost proposals to protect the service experience.” It is also, bluntly, how you stop an efficiency review quietly killing the good version of your system — which is a more common cause of death than technical failure.

One honest caveat, and it matters for Part IV. The receipt does not win the argument. It changes what the argument is about — from “the AI is wasteful” to “here are the trade-offs we encoded, do we still accept them?” That is a better conversation, not an automatic verdict, and anyone selling you provenance as a way of ending arguments is selling you something else.

What the trace deliberately doesn’t contain

The obvious objection at this point is that the trace shows what the agent read but not what it thought. Correct. It doesn’t, and it doesn’t need to.

That is governable. Not because it reveals private chain-of-thought — it does not need to. It reveals decision provenance. Which is, in any case, the thing the industry has actually been missing: as IBM puts it, most enterprises can now stand up an agent that books, files or triggers something, and far fewer can show the audit trail behind that action — the hard part of agentic AI is being able to explain, after the fact, why it acted, what it read, and who is answerable for it.¹⁵

Tool calls are not just plumbing. They are evidence of cognition. If the agent used the wiki, the trace proves it. If it skipped the wiki, the trace proves that too.

What it costs

Briefly, because the next chapter is about affordability and this is the setup.

Storage is trivial — these records are text. The expensive parts are precisely the ones people skip: computing available_unread, keeping pointers resolvable on a schedule, and capturing effect-on-work rather than mere retrieval. Each of those is real engineering, and each is the difference between an artefact and a decoration.

Which is exactly why the next four chapters are about the operating model rather than the artefact. You can build this trace in a fortnight. Making it something an organisation actually uses, can afford, is willing to act on, and is permitted to deploy behind — that is the hard part, and nobody talks about it.

Starting with a question that sounds identical to the one this trace answers, and isn’t. This trace tells you what the system knew on the day. Half of every real audit is asking what was true.

The first edition of this book sold the rewind as the temporal move in AI governance. Restore the commit. Re-trace the path. Reconstruct the world as of 9:17 am on the day the case was booked. It is a real capability, I would build it again, and it is the mechanism Chapter 3 described.

It is also one clock. There are two, and a record that has only one of them is not defensible.

The question that breaks it

Was this compliant when it was lodged?

The current standard operating procedure is version 21. The lodgement happened under version 19. Restoring the wiki to the lodgement date tells you what the system knew then. It does not tell you what bound the organisation then.

Those are different facts, and they diverge exactly when it matters — because the system’s knowledge can be stale, incomplete, or simply wrong about the rules. An audit is not asking about the system’s knowledge. It is asking about the rules.

And this class of question is not an edge case. High-stakes organisational questions are disproportionately past-tense: was this compliant then; what bound the team on the incident day; which playbook governed this contract at signature; what did the intake team actually get trained on in someone’s first week. A knowledge base that only knows the current state answers all of them wrongly, with full confidence — which is the worst available failure mode, because nothing in the output signals that anything went wrong.

Valid time and transaction time

The fix is not new. It is decades old and lives in a corner of data modelling most AI teams never visit.

Bitemporal history treats time as two independent axes. Martin Fowler, following Snodgrass and the SQL:2011 standard, names them valid time (also: actual time) and transaction time (also: record time).¹⁶ SQL:2011 exposes the pair as application-time periods and system-versioned tables; a table with both is bitemporal.¹⁷

Leave policies aside for a moment and consider payroll, a domain where wrong answers about the past have always been expensive. A payroll system knows an employee’s rate is $100/day starting 1 January. Payroll runs on 25 February. Then, on 15 March, we learn the rate actually changed to $211/day effective 15 February. What was the rate for 25 February?¹⁸

The honest answer is: it depends which clock you ask. By valid time the rate was $211 on 25 February, because the change was effective 15 February. By transaction time — what the system knew when it ran payroll — it was $100. Both answers are correct, to different questions.

A compliance conversation that cannot ask each clock separately is not careful. It is incomplete.

A clean division of labour

Map that onto the stack and what looked like a collision between two pieces of doctrine becomes a division of labour so clean it is almost embarrassing.

So: the rewind was never wrong. It was half. Cognitive provenance answers transaction time; the as-at walk answers valid time; and you need both, because an auditor will ask both and will not tell you which one they mean.

Currency is not applicability

Name the two properties precisely so they cannot be smuggled into each other.

Currency asks which version is latest — tip of the chain, highest number, most recently published file. It answers what do we use now? Applicability asks which version’s validity window covers business date D. It answers what governed the world then?

They only agree when nothing material has changed since D. In a living organisation, policies move, training packs get rewritten, checklists grow an attestation step that didn’t exist two years ago. Which produces an uncomfortable rule of thumb:

Overwrite is not hygiene

The filesystem instinct is overwrite: one current object, history optional. The warehouse instinct is different — when a value changes you insert a new version with effective dates rather than destroying the old one. That is a slowly changing dimension, Type 2, and it powers every serious data warehouse that has to answer “what did we know, and when was it true.”¹⁹

Most organisations run filesystem instinct on their policies and then expect warehouse-grade answers from the AI sitting on top. That is not a model gap. It is a modelling gap.

And the blunt version, because it is worth being blunt: “delete the old procedures so nobody uses them” is not sophistication. It is how you make the past un-queryable, and then act surprised when an audit asks a past-tense question.

Deprecated but binding

Real organisational knowledge carries status: current policy; deprecated policy still binding on old contracts; two departments in genuine disagreement; a path tried and abandoned with the reason attached.

Applicability does not mean keeping every obsolete page as a default. It means keeping the binding version addressable for the dates it still owns. Which is what a supersedes edge is for — not a synonym for delete, but a typed succession: version B replaces version A as the default for new work, while A remains addressable with its validity window intact.

Why the substrate decides this too

Chapter 2’s table pays off a second time here, and more sharply.

A folder full of policy_v19.pdf, policy_v20.pdf, policy_v21_FINAL.pdf has the versions but not the succession — nothing tells you which validity window covers which date. And retrieval is worse than useless for this, because similarity has no notion of time at all: on the wrong query the 2020 chunk out-scores the 2024 chunk and returns a stale answer with full confidence.

The supersedes chain is the only structure that makes “walk to the version valid on this date” a mechanical operation instead of a manual archaeology dig. And the pleasant part is that it arrives nearly free — because the ingest agent records each succession as an edge as it witnesses it, rather than overwriting the page and calling it hygiene.

Put this in the brief

Concept without procurement language stays a blog post. Watch the sentence that fails in architecture briefs and RFPs: ingest all policies into the knowledge base. That buys currency-shaped demos. If you do not name as-at, vendors will not build as-at. They will build chat.

If a proposal cannot point to those six, it is not proposing a defensible record. It is proposing a knowledge base that is good at now — which you may still want, but should buy under its real name.

If you cannot point to the version and the window, you do not have a defensible record. You have a knowledge base that is good at now.

What “done” looks like

Pass: the system returns v19, its validity window, and the succession edges it walked. A past-tense question without a date prompts for the date instead of inventing one.

Fail: a fluent paragraph, no version id, no window, tip-default on historical questions, or a mid-chain chunk selected by similarity alone.

The record is now correct for the date and checkable at every hop. Which surfaces the question the first edition never asked, and the one every implementation eventually hits at about month three: who is going to read all of this?

Ten thousand decisions a month. Each one produces a trace with observed pages, traversed edges, exhibits, pointers, rejected proposals, a confession and a stop condition.

Nobody is reading them.

That is not a criticism of anyone’s discipline; it is arithmetic. And it matters more than it looks, because an unread governance record is not neutral. It manufactures the feeling of control — which is strictly worse than knowing you have none, since the feeling stops you buying the thing that would have worked.

The first edition of this book described an artefact and quietly assumed a reader. This chapter is that correction.

The shape that already solved this

Software teams hit the same problem first, under commercial pressure, and arrived somewhere useful. The pattern emerging from AI coding is not the model writes, then a senior carefully reads every line. It is closer to a barbell.

Heavy thought before implementation. Cheap implementation in the middle. Heavy verification after implementation.

Three things happened to make that work, and each has a direct analogue here.

Planning became a first-class mode. Not a suggestion, a permission: Anthropic’s Claude Code treats plan mode as a permission mode, so read-only exploration and constraint-setting happen before implementation is allowed at all.²⁰ Verification thickened and diversified — repository-wide graphs so that consequences not visible in the changed files alone become reviewable.²¹ And critically, human authority stayed the merge: GitHub’s Copilot code review gathers broad project context and comments on risk, and its review explicitly does not count as formal approval and does not itself block a merge.²²

That last one is nearly the exact architecture governance needs, and it deserves stating as a rule rather than an observation.

Hold that rule; it governs the next three chapters as well.

The barbell, applied to the knowledge path

Left plate — design the admissible path before commitment

This is where senior attention is worth the most, because it is cheap to change here and it determines everything the middle records. For a given decision class, decide and write down:

• Which pages are required knowledge before this class of recommendation is permitted at all.
• Which edges must be traversed before a non-obvious recommendation is allowed.
• Which claims carry organisational constraints as opposed to answers — the ones a model’s priors will never supply.
• What counts as a legitimate stop condition.
• What an acceptable fallback to broad search looks like, and when its use is a finding.
• And — borrowed directly from the design side of the barbell — record the rejections: which candidate admissibility rules you considered and why they lost, so the next reviewer inherits the reasoning instead of relitigating it.

Almost nobody does this, and it is the single reason path records usually turn into data nobody can interpret. Six months of traces with no declared admissible path is a pile of traversals that all look equally plausible.

Middle — record completely, review nothing

Recording is cheap. Reading is not. So the middle’s entire job is completeness and cheapness: every path recorded, every pointer resolvable, nothing triaged, no theatrical thoroughness. Delivery proceeds. Seniors handle exceptions, not volume.

The discipline in the middle is negative — it is about what you refuse to do. No sampling reviews that produce a monthly deck nobody acts on. No dashboards counting traces. No “path compliance rate” going up and to the right while nothing improves.

Right plate — verify at consequential gates, scaled by criticality

And here is the part that makes it affordable: you do not spend the same verification budget on every decision, because you are not making the same commitment with every decision.

You do not need the same cognition budget for every gate. You need the right barbell mass for the commitment you are about to make.

What makes the middle actually affordable?

The trick is not new and it is not clever. It is CI.

The checks that run on everything are deterministic and computed, not read:

• Is the trace pinned — all three versions present and resolvable?
• Do the pointers resolve? (Scheduled, per Chapter 6.)
• Was the required-page set covered for this decision class?
• Was available_unread non-empty for a constraint-bearing claim?
• Did a broad-search fallback fire where the graph should have sufficed?

Not one of those needs a model, let alone a person. They are set operations over a structured record. Human reading is then reserved for the gate and the exception — exactly the trick continuous integration plays, where cheap deterministic checks run on every commit and expensive human judgement concentrates at the merge.

When producing becomes cheap, verification becomes the job.

Two ways this goes wrong

So who does the reading?

Not a new department, which is the answer most leaders are quietly dreading.

The left plate belongs to whoever owns the decision class, with the accountable business owner in the room — because “which pages are required knowledge before we recommend a non-obvious repair” is a business question wearing technical clothes. The middle belongs to platform: it is instrumentation, and it should be as boring as logging. The right plate is your existing assurance function, given a better artefact and a much smaller reading list.

The change is not headcount. It is that the same people stop reading everything badly and start reading a little, at the moments that matter, with receipts.

And then a finding appears

So the deterministic checks fire on a Tuesday, and one of them lights up: a required page was not observed before a non-obvious recommendation. Chapter 4’s failure mode, caught in the act, exactly as designed.

The obvious next move is to make it a hard fail. Block the action. Escalate. Turn the light amber.

It is the wrong move, and the reason has nothing to do with technology.

The first edition of this book proposed a verdict scheme, and I still think it reads well:

• Required domain page not observed before a non-obvious recommendation → fail.
• Observed the diagnostic pages but not the customer-trust edge → partial fail.
• Full traversal with cheaper proposals rejected for explicit reasons → pass.

It would be quietly disastrous, and the reason has nothing to do with detection accuracy. It is about what happens inside an organisation when a machine-generated signal is given the power to change a status.

The amber trap

Amber has a cost. It triggers process, attention, escalation and, quite often, blame. Everyone who has worked near a governance function knows this in their body, even if it’s never written down.

Which produces a structural consequence: a governance system that can only express concern by changing a status will systematically suppress weak signals. Not through bad faith. Through ordinary organisational physics — the same physics that makes people round a risk down when rounding it up means a fortnight of meetings.

Now make the prediction concrete, because that is the part that should worry an operator. Make “required page not observed” status-changing, and within two quarters your required-page list will have been negotiated down to whatever the agent already reads. Not removed — negotiated, in a reasonable meeting, with a reasonable rationale about false positives and operational friction.

The list survives. The signal doesn’t. You will have built a control that measures its own convenience.

Two planes

The way out is not a better threshold. It is refusing to put the finding on the same wire as the status.

That second column is what makes the architecture adoptable, and it is worth saying explicitly to any risk function reading this: nothing here asks you to give up anything. The formal plane is untouched. What you gain is a sentence the old system could never say.

Formal status: green. Independent findings: three items warranting management consideration.

That is a far better outcome than forcing every weak signal into amber, because it lets a weak signal travel as a finding rather than a status change — which is the only way weak signals survive contact with an organisation at all.

Compute broadly, disclose narrowly

Underneath sits an order-of-operations bug that is hard to un-see once written down.

Be exact about what the inversion is not. It is not a proposal to flood executives with more detail; human attention is exactly as scarce as it was. What changes is that the organisation stops throwing most of its nuance away before anyone has looked at it. Management still receives a compact representation — but that representation is produced after the estate has been examined, not instead of examining it.

Applied to this book: record every path (Chapter 9’s middle), compute over all of them, disclose the handful carrying a shape worth a human’s time.

The finding card

A finding needs a format, or it becomes an email with an opinion in it.

Notice what the card refuses to do. It does not accuse. It does not claim the machine has proven anything. It surfaces a shape, attaches the receipts, states its own uncertainty, and hands the judgement back to a human. That discipline is what makes the whole architecture safe enough to run.

Are three independent reviews actually independent?

Now the trap on the other side, and it is the one that will surprise the assurance reader.

Three independent assurance lines review the AI decision. First line signs off on the process. Second line reviews the risk. Internal audit samples the population. Three green ticks, three separate departments, and a board that reasonably concludes the risk is well covered.

Now follow the evidence backwards. All three read the trace the agent produced.

That is not three lines of defence. It is one assumption reflected through three mirrors.

This is the organisational form of a failure engineers already know well: redundancy that shares a common dependency is not redundancy; it is a single point of failure wearing three coats. And it is precisely the failure the “three lines” model most invites, because that model describes independence in terms of organisational roles — management control, risk oversight, internal audit — rather than in terms of the evidence each line actually consumes.²³ Roles can sit in three different divisions and still drink from one well.

The fix is not a fourth reviewer

The instinctive response — add another line of defence — makes it worse. A fourth reviewer reading the same trace is a fourth mirror.

The real fix is adversarial: verify against a mechanically different evidence source, one that fails in a different way than the first.

Independence stops being a claim on an org chart and becomes a property you can query.

Learn from what you suppressed

One more guard, because a review system that learns only from what it flagged will compound its own early mistakes.

Attention is allocated from the cases the system itself judged important. An early classification error quietly feeds later priors, and within a few cycles the exploratory plane is confidently examining exactly the things it already believed were interesting.

So on a schedule, sample the decisions the system chose not to flag. Score the misses and the false suppressions. Feed outcomes back into the priors.

Learning only from what you kept is how echo chambers become code.

What does “hand it back to a human” actually look like?

Otherwise that phrase is hand-waving, so here is the shape. A dispute stops being a status contest that evaporates at the hour mark and becomes a transaction against a versioned record.

Both resolutions are wins, which is the part people miss when they hear “the wiki settles it” as machine supremacy. Either the map was wrong and the meeting produced a better institution, or the person was stale and the meeting ran the invalidation protocol that tenure never had. Meetings stop being where organisational knowledge goes to fight and start being where the map gets its work items.

The trace can now be produced, read at the right moments, and disclosed without lying by omission. Which raises the question of what it is actually worth — what signing it buys you, and what it conspicuously does not.

Decision governance already asks you to bind three things to a consequential decision. The authority: who was allowed to act, under what delegation, within what scope. The data: what case facts and evidence were actually observed. The graph: what deterministic policy evaluated the proposal and produced the outcome. Sign all three and bind them to the decision, so governance travels with the thing it governs rather than being reconstructed later by an investigation.

That model is a sibling’s territory and I take it as given. The gap this book fills is narrow and specific: none of the three records what the agent knew.

The fifth column

Sign the knowledge path.

And here is why it is signable at all, which ties the whole book together in one sentence: because the knowledge is restorable text under version control. You cannot sign a similarity search — there is no stable object to sign. You certainly cannot sign a prior. Every property Chapter 2 identified in the substrate exists so that this sentence can be true.

The machinery already exists

This is less exotic than it sounds, because the software supply-chain world built the infrastructure over the last five years and the patterns are mature.

SLSA defines provenance as “the verifiable information about software artifacts describing where, when and how something was produced.”²⁴ in-toto defines how to structure an attestation, and explicitly supports custom predicates — so domain-specific decision predicates are a supported extension pattern rather than a hack.²⁵ Sigstore removed the key-management objection.

What none of them covers is the layer that matters most to a regulator, and it already has a name: decision-control provenance. Build provenance exists. Data provenance exists. Model provenance exists. “Who was allowed to act, what policy validated that authority, what deterministic code executed the outcome” does not.

The direction of travel is not subtle. Gartner names digital provenance a 2026 strategic technology trend and predicts that by 2029 organisations that failed to invest will face “sanction risks potentially running into billions of dollars.”²⁶ Provenance is moving from the software supply chain to every digital artefact. Decisions are next.

What the fourth signature enables

Three statements become available that were previously unsayable — worded carefully, post Chapter 10, as findings routed to a human rather than automatic verdicts:

• Required domain pages were not observed before a non-obvious recommendation.
• The diagnostic pages were observed; the customer-impact edge was not.
• Full traversal; cheaper proposals rejected for explicit reasons; exhibits resolvable.

Each is a shape with receipts attached, and each is a genuinely new kind of claim about an AI system.

The correction

The first edition of this book closed on a line I still like: “The agent is replaceable. That is the governance win.”

It is right about ownership and over-claimed about safety. And the distinction is not academic — it determines whether an organisation funds one control or two.

Two leashes

There are two controls, on opposite sides of the model, and they do completely different jobs.

A wiki does not solve the “wicked AI” problem in the hard governance sense. An informed agent can still do something unauthorised. Models do not fear job loss, reputation or the mortgage; behavioural trust cannot be prompted into them, so architecture has to carry the burden. And an authority gate does not solve the knowledge problem either — it can safely prevent an ignorant agent from doing terrible things, but it cannot make the ignorant agent useful.

Prompts are neither. They are too small and flat to hold an organisational world, and too soft to enforce an execution boundary. A policy PDF is a prompt with a signature page.

The well-informed overreach

Now the part that makes the correction land rather than read as a disclaimer, because this book actively creates a specific danger.

A well-conditioned agent is more effective and more dangerous. That is not an argument against the architecture. It is the argument for the second leash.

A well-informed agent without an action leash can perform a highly contextualised overreach — the most dangerous kind, because it sounds like the company.

Sit with that. Everything in Parts I to III makes the agent’s proposals better grounded, better evidenced, and considerably more persuasive to the humans around it. An overreach from a system that has read your customer-trust page, cites your parts strategy and speaks in your organisation’s vocabulary is far harder to catch than an overreach from an obvious outsider.

And there is a specific failure that people who like this architecture walk into. If you only celebrate that the graph is alive — and never instrument whose lens was loaded, which pages dominated attention, and what the agent was allowed to do next — you have built a high-context confused deputy. Excellent judgement, no accountable boundary, which is exactly the shape of thing that does the most damage fastest.

What the second leash is

One paragraph, because it has its own book and this one only insists it exists.

In-path authority: an independent, model-agnostic enforcement boundary that verifies evidence, authority, policy and execution conditions before an action executes, returning allow, pause or deny — and creating the evidence as part of the decision path rather than reconstructing it afterwards through investigation. The diagnostic that tells you whether you have one is blunt: can this system technically prevent an unauthorised decision from executing right now? If the answer is a policy document, a dashboard or an approval matrix, you have compliance cosplay — useful theatre until the accountability moment. Most AI governance programmes are two-thirds complete: they establish what data is reliable and what models are permitted, and never build the layer that verifies whether this actor may take this action, right now, with proof.

What this chapter bought, and what it didn’t

Grounding conditions cognition. It does not authorise consequence. If you read this book and build only the graph, you have made a persuasive agent more persuasive and left the boundary unfunded — and you will find out, eventually, in a way you would rather have paid for in advance.

Which is also why “we can replay it” is not the same sentence as “we’re allowed to run it.” Nobody in your organisation is going to approve a decision. They approve a deployment.

Everything so far proves a decision. Nobody in your organisation is going to approve a decision.

They approve a deployment. And it doesn’t happen in one room. It happens in six or seven, sequentially, each with a different question, a different accepted evidence type, a different owner of residual risk, and a different reason to say not yet.

If you have shipped an agentic system into a regulated enterprise you already know the second problem is the harder one. This chapter is about what the knowledge path contributes to solving it — which turns out to be more than you’d guess, and in places nobody looks.

The question almost nobody can answer

Most programmes can answer: was the model validated? was the data broadly governed? Almost none can answer: who authorised this action, under what mandate, with what admissible evidence, at decision time?

Note precisely which words in that sentence this book has been about: admissible evidence. The other three clauses belong to the authority layer, and Chapter 11 drew that fence deliberately. What the last eleven chapters bought is one clause of a four-clause question — and it happens to be the clause nobody else was building.

Observability says what happened. Provenance and authority say who was allowed to drive.

Which is why “more logs” keeps failing as a strategy. Policies, dashboards, approval matrices, explainability reports and audit logs that cannot technically prevent an unauthorised action are compliance cosplay — useful theatre until the accountability moment.

Discover the governance workflow, not just the business one

Here is the move that makes the rest of the chapter possible, and it is a discovery activity rather than a build one.

Map the governance workflow as seriously as you mapped the business workflow. Which forums decide. Which evidence each one actually accepts — not which evidence you think is compelling. Who owns residual risk. What must be technically enforceable rather than merely documented.

Then build one joined package that compiles first-generation views for those forums from the same ground truth.

Where the knowledge path actually sits

The approval-ready deployment package is not a PDF dump after the build. It is the working system plus the artefacts that make permission and operation defensible.

Three rows are highlighted, and the point is what they are not.

If your evidence boundary doesn’t declare which knowledge is admissible for a decision class, Chapter 5’s grading has no reference and Chapter 9’s left plate has nothing to compile. If your observability traces tool calls but not traversals, you cannot produce Chapter 7’s artefact at all. And if your operating receipts don’t write observed path failures back into the eval set, the instrument never improves anything — you have built a measurement with no feedback loop, which is a hobby.

Note also the discipline underneath: build, release and run stay separated. Offline evals gate the build; the release is tagged with its metrics; production runs with monitoring and write-back into the next eval set. Path failures belong in that write-back exactly like any other observed production failure.

The approval manifest

Forum by forum. This is the artefact that converts “we have good governance” into something a person can hold.

The status column is the honest part. Real review produces Rejected → resubmitted and Rework then Conditional, because forums do their job. Which gives you a diagnostic worth remembering:

A manifest with nothing but green is a manifest nobody ran.

And the conditions column is where the knowledge path most often shows up as an actual control. Something like: no non-obvious recommendation without the canonical fault page observed; failures reported as findings, not gates — which is Chapter 10’s discipline, written into an approval condition where it becomes binding rather than aspirational.

What “approval-ready” means

It means ready to enter and survive the organisation’s own review path with inspectable evidence still attached.

It does not mean regulator-certified. It does not mean universally compliant. It does not mean safe. Say all three out loud, because the phrase is exactly the kind that gets quoted back at you in a steering committee with the qualifiers removed.

And note how it differs from Chapter 11’s artefact. An attestation package proves one decision. The approval-ready package makes the bounded system and its operating model inspectable to every forum that must permit it. Different objects, different scopes, both needed — and organisations routinely build the first and then wonder why the second still takes nine months.

The boundary that keeps this honest

One more, and it is the least comfortable idea in the book.

Passing the audit means you followed the procedure.

An organisation can pass every audit it faces and still, structurally, be carrying ceremonial controls, orphaned obligations and risks nobody is watching. Not because anyone was negligent — because confirming conformance is the affordable question. It samples, it ticks, it moves on. The deeper questions require reading and reconciling the entire estate across its whole history, which was simply never on the menu.

That is not a criticism of auditors. It is a description of an economic boundary that has only just started to move.

Which produces the correct posture, uncomfortable and useful in equal measure: treat “settled” as a hypothesis, not a fact. That is also, conveniently, exactly what Chapter 10’s exploratory plane is for.

How a path capability enters an approval conversation

Practically, because readers will have to do this and the instinct is to lead with the architecture.

Don’t. Lead with the forum’s question. Architecture asks about data flows and interfaces. Privacy asks about purpose limitation and retention. Model risk asks about residual risk at this autonomy level. Operations asks whether you can roll back.

The knowledge path answers a question each of them already has and could not previously evidence: what was this system allowed to consider, and can you show what it actually considered? Privacy hears purpose limitation with proof. Model risk hears a failure taxonomy with a detection mechanism. Operations hears reproducibility. Same artefact, three different sentences, and none of them mentions the word “wiki.”

Which is the last thing this argument has to be honest about — because everything in Parts I to IV has quietly assumed the corpus should be compiled in the first place. For a great many corpora, it should not.

Here is the sentence this entire book is at risk of being misread as: replace your RAG with a wiki.

Don’t.

I’ve spent a year arguing that agents want a wiki rather than a retrieval index, and I stand by every word of it — which is exactly why this chapter exists. Some corpora should stay a RAG, and converting them is a mistake that costs money going in and costs capability forever after.

Substrate is a decision, not an allegiance.

The rule

Three axes, run per corpus — not once for your whole stack. Two corpora owned by the same organisation routinely land on opposite substrates, and that is a correct outcome rather than an inconsistency to tidy up.

Run it honestly on one corpus you were about to compile. Is the typical query recall or synthesis? How often is the same understanding reused? Would compacting it destroy what you came for? If it is recall-shaped, rarely reused and loss-intolerant, leave it a RAG.

Stratify, don’t migrate

“Leave it a RAG” sounds like standing still, and I don’t want to leave you there, because there is an upgrade path. It just isn’t the one the word “migrate” implies.

Migration lifts the corpus out of one substrate and sets it down in the other. Stratification keeps the corpus exactly where it is and grows a thin new layer on top of it.

Keep the RAG as the raw layer — the complete, un-synthesised, recall-optimised ground truth. Then let a thin wiki atlas accrete above it. The discipline that keeps it thin is a single rule: only recurring themes earn a page. The first time you sweep the corpus for a question, you just run the RAG. The third or fourth time you find yourself asking a variant of the same question, that theme has proven it’s worth compiling.

And critically, the page does not replace the raw results. It routes down into them.

   THIN WIKI ATLAS   (compiled, cheap to read, only recurring themes)
   ┌───────────────────────────────────────────────┐
   │  page: "state persistence approaches"          │
   │   · the shape of the design space (synthesis)  │
   │   · edges to neighbouring themes               │
   │   · ▼ pointers, NOT a replacement ▼            │
   └───────────────────┬───────────────────────────┘
                       │  routes down for specifics
                       ▼
   RAG RAW LAYER   (complete, un-synthesised, recall-optimised)
   ┌───────────────────────────────────────────────┐
   │  every thread, every variant, every outlier    │
   │  chunk C … chunk Q — the seventeen solutions    │
   └───────────────────────────────────────────────┘

You get the wiki’s gift — a one-screen map of a sprawl, an agent that can orient before it dives — without paying to compile the whole corpus and without losing a single variant, because the variants still live intact in the layer below.

The atlas page, and what it refuses to contain

theme:        state-persistence-approaches
one_liner:    how people keep agent state across runs
the_shape:    2–4 sentences on the design space, NOT a winner
dimensions:   the axes the variants differ on (durability, cost,
              blast-radius) — so a reader can navigate
rag_query:    the exact query that pulls the full variant set
edges:        neighbouring atlas themes
earned_on:    date the theme recurred enough to warrant a page

Notice the omission. The schema stores the shape of the design space and the query that fetches the specifics — never a compacted “the best approach is X.” That refusal is what keeps stratification honest.

Why this isn’t a retreat

Now the part that makes this chapter a contribution rather than a caveat.

The atlas is exactly the provenance surface Parts II and III require — purchased at a fraction of the cost of compiling the corpus. Point by point:

You don’t need to compile the corpus to get cognitive provenance. You need to compile the routes.

Which reframes the build recommendation for most readers of this book. The first thing to build is not a wiki of your organisation. It is an atlas of the routes your agents actually take through it — grown one recurring theme at a time, over whatever raw layer you already have. The RAG below becomes the exhibit layer; the atlas above becomes the record of the walk.

What the atlas can’t do

Keep the honesty symmetrical, or this becomes a different kind of oversell.

Valid-time applicability — Chapter 8 — needs real version identity, validity windows and supersedes edges on the entities that carry obligations. An atlas of recurring themes will not give you that for policies. It can’t: themes don’t have validity windows, policies do.

But look at the properties of that corpus. Policies, procedures and checklists are synthesis-shaped (you want the binding rule, not seventeen variants of it), high-reuse (every case touches them), and versioned by nature. The rule sends them straight to the compiled substrate — and that corpus is almost always far smaller than people fear. It is hundreds of documents, not millions.

Two practical notes

Don’t fund the compiled layer by deleting the raw one

The old syllogism about unreadable archives was good logic: I can’t open it, so I can’t search it, so it has no usable value, so delete it. Every step was true when it was written, and Stewart Brand’s “there is no business case for archives” stood unchallenged for a quarter-century. What changed is not anyone’s diligence. It is the price of reading.

Applied here, it is very simple: the raw layer is your exhibit layer. Delete it to save storage and every pointer in every trace becomes a dead pointer — which Chapter 6 told you is worse than no pointer at all.

For live, churning sources: search, don’t index

If the source changes daily, a maintained vector index is a treadmill. ripgrep and BM25 at query time beat an index you have to keep re-embedding. And if anything gets embeddings, embed the compiled pages once you pass a few hundred — the layer that is small and ages well — not the raw material.

The decision, distilled

1. Substrate is a per-corpus decision. Run the rule on each corpus, not once for the stack.
2. Recall wants RAG. If completeness is the product, a vector store is the right tool, not a legacy one.
3. Reuse is the economic gate. Compilation only wins where the same understanding is read often enough to amortise it.
4. Stratify, don’t migrate. The atlas indexes; it never absorbs.
5. Compile the obligation-bearing corpus properly. That one earns versions and windows — and it is the one an audit will actually ask about.

The fence is now built. Which leaves the last question: after all of this, what do you actually own?

Start with the trap, because it is the thing that makes this a board conversation.

Or, as the same survey puts it rather well: once AI stops being an experiment and becomes the backbone of your business, you’re no longer adopting software — you’re entering a committed relationship with a slightly vague escape clause.

The hedge against that is not a procurement clause. It is an architecture.

Rent the model, own the map

A portable, diffable, model-agnostic markdown graph means you swap the engine and keep the mind. That is not a slogan; it is a list of things that survive a vendor change:

• the wiki — the compiled claims and edges;
• the DAG — the gates and the policy;
• the receipts — every governance trace you have ever produced;
• the proposal history, including everything you rejected and why;
• the outcome feedback that improved the map.

And a list of things that don’t: the weights, and whatever your vendor called “memory.”

You rent the model; you own the map.

Which is worth compressing into the sentence I’d actually put on a slide:

And the same idea as an engineering statement about where state lives: the LLM does not hold the process. The DAG holds the process. The wiki holds the institutional memory. The receipt holds the decision trace. Version control holds the historical truth. The agent, in that architecture, is a reasoning worker operating against externalised cognition — which is precisely why it can be swapped.

Closed-loop doesn’t mean the model learns

This is where the title comes from, and it is worth being precise about a word the industry uses badly.

People think of AI learning as something that gets built into the LLM. I think the wiki — the edges, the graphs, the claims — is the real nature of what we need to do now: use AI to process record-level interactions into the wiki.

The mechanism is three lines, and Chapter 7 already showed it running. Every closed case is a source. Ingestion extracts claims. The janitor consolidates them into edges. The next ticket starts from a better map. The system compounds not because the model magically learned something, but because the organisation’s map improved.

Closed-loop AI does not mean the model learns. It means the organisation remembers.

And the governance corollary, which is the reason this book exists at all: because the organisation remembers externally, the organisation can audit what it remembered. That is impossible when everything is baked into weights, and it is the whole difference between an asset and a dependency.

How does this asset rot?

Now the counter-case, and I want to give it real weight, because a self-maintaining graph is not a self-governing one and the failure modes are specific enough to name.

The first one deserves more than a table row, because it is the failure that would make this entire book self-defeating.

Calcified lore

A conditional pattern hardens into an unconditional rule. What began as an observation becomes, a few consolidations later:

“Always replace the occupancy sensor for heated-seat complaints.”

And now the graph is another hidden optimisation nobody can see or challenge — which is the exact governance failure it was built to fix, reappearing inside the fix. You have replaced an opaque model prior with an opaque institutional one, and the second is worse because it has authority.

Compare it with the governable version of the same knowledge:

“When a heated-seat complaint is paired with diagnostic signal X, model-year Y, and no heater-circuit fault code, the occupancy sensor should be considered before the heater element. A customer-facing explanation is required because the path appears non-obvious.”

It has scope. It has conditions. It has evidence. It has a customer-service implication and an escalation rule. That is what a governable claim looks like, and the difference between the two paragraphs is the difference between institutional memory and institutional folklore.

One related rule prevents the most common form of calcification: keep the relationship in the graph and route to the source system for the current figure. Stale numbers are dangerous; stable relationships are usually directionally fine. “Occupancy sensor is a common upstream cause of heated-seat complaints under these conditions” belongs in the map. “78% of resolved cases” belongs in a query.

Where else does this apply?

Everything in this book has been demonstrated on one service case, which is deliberate — one worked example beats three sketches. But the test transfers wherever decisions are consequential and reviewable.

The question is identical in all three: can you replay what it knew, and can you show what it was allowed to do about it?

What to run this quarter

Not a roadmap. Five things, each executable now, each of which will tell you something you don’t currently know.

The failure this book exists to make harder

It isn’t a wrong answer. Wrong answers are visible, arguable and correctable, and we have been managing them for as long as organisations have existed.

It’s a right answer nobody can check, acted on by someone who couldn’t have checked it, in a system that remembers only the conclusion.

That is the man at the counter in Chapter 1, holding a part order he had no way to argue with. Every mechanism in this book — the pin, the path, the pointer, the confession, the two clocks, the two planes, the two leashes — exists to make that specific outcome structurally harder. Not impossible. Harder, and visible when it happens.

Which is worth being clear about, because governance arguments have a way of drifting upward into abstraction until they are about audit committees. The point of a governance trace was never to satisfy an auditor two years later. The point is that the person standing in front of the customer has something to argue with.

Build the replayable system before the decisions you will have to defend have already been made — because provenance is the one control you cannot retrofit. You can add a gate tomorrow. You can tighten a policy this afternoon. You cannot, at any price, go back and create a record of what an agent read last June.

The model is not the memory. It never was.