What Proves You Right When the Customer Pushes Back
At a quarterly business review, the customer's CFO points at a number on the screen and asks: "where…
Res ipsa loquitur. "The thing speaks for itself." — an old maxim of Anglo-American tort law, commonly invoked in findings of negligence
At a quarterly business review, the customer's CFO points at a number on the screen and asks: "where does this accounts-payable conclusion come from?" The room goes quiet. If the system can pull up the source documents and pinpoint the exact passage — which invoice, which statement, which contract, and which page of each — the challenge gets settled on the spot. If the only answer is "let us go check and get back to you," then even if the number turns out to be right, trust has already taken damage in the waiting.
A moment of challenge is a moment of reckoning for trust, and what a reckoning calls for isn't attitude — it's evidence.
I. Trust Is a Three-Story Building
A customer's question of "can I trust this result" breaks down into three layers: What is this answer based on? What was the process behind this judgment? What caused this particular failure? — a citation you can trace back, a decision you can replay, an anomaly you can diagnose (see Figure 13-1).
Figure 13-1: Trust isn't a line about "the model is accurate" — it's the answer, the process, and the failure all being inspectable.
All three layers share one property, and it's the most important sentence in this chapter: they're not reporting material assembled for the customer to see — they're natural byproducts left behind by the system as it runs. A chain of evidence isn't a packet compiled after the fact once someone raises a challenge; it's a recording capability built into the architecture from the start — logging is an architectural decision, not damage control after the fact. Open-source enterprise agent engineering practice has already turned all three layers into standard components, and the supervision mechanism among the five harness elements a front-line company described likewise requires an audit trail to follow every action — recording what the agent did, and why1.
II. Layer One: Every Answer Carries Its Source
The most basic layer: every conclusive answer the agent gives carries an EvidenceRef attached to it — which document it's based on, where exactly, and how confident it is2.
The full version of the question the last chapter closed on lives right here: the customer asks "where does this number come from," and the answer comes in three parts — what the source is (file name, system, timestamp), where exactly it points (paragraph, page number, field), and how confident it is. With all three parts present, the customer can follow the citation and check it themselves — every check earns a little more trust.
This layer also hides the other half of hallucination governance. Everyone hopes a stronger model just stops making things up, but the engineering discipline is harder-edged than that: when retrieval fails, the answer has to say "not found" — it is never allowed to make something up. Saying "not found" is just a failure; inventing a plausible-looking answer is an overdraft against trust. So the architecture has to enforce this: a conclusive output with no EvidenceRef attached is not allowed to go out. If retrieval quality falls short, the citation chain breaks first, and any reasoning or explanation built on top of it never gets off the ground.
III. Layer Two: Every Decision Step Has to Be Replayable
The second layer goes one level deeper: it's not just the answer that carries a source — the entire process of arriving at that answer can be replayed.
In engineering terms this takes the shape of a run trace: every run the agent makes gets recorded event by event — what data it read, what tool it called, what parameters it passed, what result it got, how it reasoned along the way. One timeline, start to finish2.
The value of replay pays off in three scenarios. When the customer challenges a result: you can give them not just "where the number came from" but "exactly how, step by step, it got reasoned into this number" — the EvidenceRef from Section II is a snapshot; the run trace is the full recording. During incident review: when something goes wrong, an event-by-event replay pinpoints exactly which step things started to drift — Chapter 11's approval ticket recorded "who approved it"; the run trace adds "what the system was looking at right before the approval." When evaluation catches a failure: for a sample that failed in the Regression Set, open the trace and see exactly which step it failed at — this connects right back to Chapter 12's diagnosis, and leads into this chapter's final layer.
IV. Layer Three: Failures Have to Be Classified, or You Can't Fix Anything
With a trace in hand, an anomaly can finally be diagnosed. But diagnosis has one precondition: failures have to be classified, because different classes of failure get fixed in completely different ways.
Failures in production split into at least four classes:
- Retrieval failure — it didn't find what it should have. The fix lives in the data: fill in the index, tune recall, adjust the chunking. No matter how smart the system is, it's useless if you can't feed it the right material.
- Reasoning failure — it found the right thing, and used it wrong. The fix lives in the model and evaluation: improve the prompt, add a judging rule, put this case into the Regression Set.
- Tool failure — the tool was called, and the tool failed. The fix lives in the engineering implementation: timeout, retry, graceful degradation (Chapter 14's four resilience primitives).
- Data failure — the source itself was wrong. The fix lives on the customer's side: upstream data-quality governance, which may mean going back to Chapter 10's Data Contract.
Four classes of failure, four different directions, four different owners of responsibility. Lump them together — the most common way is calling everything "the model isn't good enough" — and there's no telling where to even start fixing it: throwing a model upgrade at a retrieval failure, throwing a prompt rewrite at a data failure — plenty of money spent, the same errors keep showing up. The run trace is what classification runs on: replay to the failing step, see whether it got stuck fetching material, judging, executing, or at the source, and the class sorts itself out.
V. The Playbook for Proving Yourself: Four Standard Moves
The architecture provides three layers of capability — how do you use them to actually face a challenge? There's a standard four-move playbook:
Move one, make the challenge concrete. Don't say "our system is reliable overall." Say "which specific case are you referring to — let me pull it up." Pin a vague challenge down to a specific record.
Move two, put the evidence on the table. EvidenceRef plus the run trace, produced right there on the spot — source, location, process, all three laid out on the table, not "we'll check and get back to you."
Move three, attribute and classify. If there really is a problem, classify it on the spot — which of the four failure classes it falls into, and where the line of responsibility sits (a problem at the data source belongs to the customer's governance; a reasoning problem belongs to our fix).
Move four, commit to the fix. This failure case goes into the Regression Set (Chapter 12's mistake log), and the fix has to pass the release gate before it ships — give a deadline with acceptance criteria attached, not a vague "we'll optimize it."
These four moves turn "proving yourself" from a defense into a live demonstration of quality improvement. Facing the same accusation of "you got this wrong," a customer who's been walked through the four moves doesn't see a company admitting fault — they see a system operating. In a lot of long-term relationships, handling one challenge well is worth ten smooth status reports. This playbook echoes forward and back with Chapter 8's responsibility handoff table and Chapter 17's handoff checklist: the responsibility table answers "who do you go to when something goes wrong"; this answers "once you've found them, what do they actually show you."
VI. The Cost of Leaving a Trail, and the Payoff of a Single Audit
A chain of evidence isn't free. A full, event-by-event trace means real storage and logging overhead — record the complete replay for every single run, and the bill arrives before the value does. So recording needs its own tiers: fully record critical runs (anything touching money, approval, or an outbound send), sample-record routine runs (with a sampling rate aligned to evaluation's own spot-check rate).
The basis for tiering is the exact same one from Chapter 11's risk tiering — a high-risk action gets a high-specification trail2. This storage bill ultimately lands in Chapter 14's cost governance; here, the principle to plant is this: the specification of the trail follows risk, not a compulsion for completeness.
One last scenario, to see the commercial payoff of getting this wall down:
A customer's audit department ran a routine spot check, randomly pulling 20 historical outputs and demanding a documented source for each one. The vendor came back the same day: 18 of the 20 had a fully traceable chain of evidence — source file, location, and run trace all present; 2 were missing due to a recording-policy change that month, with an explanation and a backfill plan attached. The audit department didn't ask a second question. On the renewal negotiation table, that 18-out-of-20 record later became a slide in the vendor's deck — an evidence-completeness rate turned into leverage for renewal.
At this point, the two hardest walls of the eight to quantify — provable results, trustworthy results — are both standing. The last set of walls in Part Three are two sides of the same coin: the cost bill and stability. That's what the next chapter takes up.