Runtime Evidence

The first four papers in this path have been about seeing failure: naming the confidence gap, defining the discipline that closes it, showing why the usual tools cannot, and measuring the real outcome instead of the activity. This paper is about something quieter and, in a regulated enterprise, just as decisive. It is about the moment months later when someone points at one decision your AI made and asks you to account for it.1

You will not be in the room where the decision happened. The agent will be long done. The model may have been retrained twice. The context the agent saw will have scrolled off whatever queue it came from. What you have to answer with is whatever you kept. That record, or its absence, is the difference between standing behind the decision and hoping no one looks too closely.

The question comes later

Consider a claims agent inside a health insurer. A member submits a claim for a procedure. The agent reads the plan, checks the codes against the coverage rules, confirms prior authorization, and approves payment. Clean run. The money goes out. Everyone moves on.

Nine months later the claim is pulled in an audit. A reviewer wants to know why this procedure was paid at this rate under this plan, because a batch of similar claims is now under a regulator's question about a coverage rule that changed mid-year. The reviewer is not asking whether the agent executed. They can see that it did. They are asking a harder thing: on what basis did it decide, what did it actually have in front of it, and was the payment correct given the rule that applied on that date. If you can produce the plan version the agent read, the codes it matched, the authorization it relied on, and the fact that the claim was never reopened or clawed back, you have an answer. If all you can produce is that a function ran and returned "approved," you have a problem that grows with every claim in the batch.

This is the ordinary shape of trust in an enterprise. It is retrospective. A decision that looked fine in the moment is fine only until the moment it is examined, and examination arrives on its own schedule: an appeal, a complaint, a sampled audit, an incident review after something downstream broke. The decisions that most need evidence are exactly the ones no one flagged at the time, because nothing looked wrong. That is what makes evidence a discipline rather than an afterthought. You cannot know in advance which decision will be the one you are asked to defend, so the record has to exist for all of them, kept before anyone knew it would be needed.

What counts as evidence

Evidence is not one artifact. It is three, and their value is almost entirely in the links between them. Take any one alone and it proves nothing worth having.

Pre-decision context

What the agent had in front of it: the plan version, the codes, the authorization, the rule in force that day

→

The decision

What it did and the basis it acted on: approve this claim, at this rate, under this coverage

→

The real outcome

What happened next: paid, never reopened, never clawed back, no appeal upheld

The pre-decision context is the state of the world the agent saw before it acted, captured as it was, not as it can be reconstructed. This is the piece most systems lose. The plan document had a version. The coverage rule had an effective date. The prior authorization existed or it did not. Reconstructing that context after the fact is exactly the move an auditor distrusts, because the source may have changed since. Context is only evidence if it was captured at decision time.2

The decision is what the agent did and the basis it acted on, in terms a reviewer can check against policy. Not the raw model output. The decision as it maps to the thing that mattered: this claim, approved, at this rate, under this coverage clause. A decision recorded without its basis is a verdict with no reasoning, and a verdict you cannot check is not evidence, it is a claim.

The real outcome is what happened in the world afterward, which is often the only artifact that can tell you the decision was actually right. Measuring it is the subject of the previous paper, Outcome Intelligence. For evidence, the outcome plays a specific role: it is what closes the loop. The claim was paid and never reopened. The appeal never came. The clawback never happened. An outcome tied back to the decision that caused it is what turns "the agent said it was fine" into "it was fine, and here is the record that it stayed fine."

Evidence is not logs

Every team running an agent already keeps logs and traces. It is tempting to assume that is evidence. It is not, and the difference is not pedantic.

A trace is a record that the machine ran. It shows the calls the agent made, the tools it invoked, the tokens it spent, the latency of each step. It answers the question an engineer asks when a system misbehaves: what did it do, and in what order. That is a real and useful question. It is not the question the auditor asked. The auditor did not ask whether the claims agent called the coverage service. They asked why it approved this claim and whether that was correct. A trace can show the first with perfect fidelity and be completely silent on the second.

The gap is one of framing. A trace is organized around execution, around the machine's own steps. Evidence is organized around the decision and its consequence, around the thing a human has to answer for. You can have a flawless trace of a wrong decision. The trace will faithfully record every step the agent took to reach a payment it should never have made, and every step will look correct in isolation, because nothing in the execution was broken. What was wrong was the decision, and the decision is judged against the outcome, which the trace never sees. Why the tools built around traces cannot close this gap is argued in full in Why AI observability isn't enough; the point here is narrower. A log proves the system operated. Evidence proves the work was right. Keeping more of the first will never give you the second.

Who comes asking

It helps to be concrete about who the evidence is for, because the audience decides what "good enough" means. Four askers recur, and none of them is an engineer debugging a run.

The auditor samples decisions and checks them against policy. They are not hostile, but they are not taking your word for it. They need to see the basis of a decision and confirm it followed the rule that applied. What they cannot verify, they treat as unverified, which in an audit is close to wrong.

The regulator arrives when something has already gone wrong at scale, or might have. They ask whether a class of decisions was made lawfully and whether the organization can demonstrate it. The standard here is not "we believe it was fine." It is "we can show it, decision by decision."

The dispute is a single customer, member, or counterparty who believes a specific decision harmed them. A denied claim, a follow-up they say never came, a charge they say violated the terms. Resolving it fairly and quickly depends entirely on being able to reconstruct what the system saw and did for that one case.

The postmortem is internal. Something downstream broke, and the team is walking backward to find where. The decisions that contributed will not be the ones anyone flagged, so the record has to let a reviewer find and examine a decision no alarm ever fired on.

What unites the four is that none of them was present when the decision was made, and none of them will accept "trust us." They ask after the fact, and they ask for a record. An organization that can produce that record for any decision, on demand, has what the anchor paper called enterprise confidence: not the absence of hard questions, but the ability to answer them.

Four properties of trustworthy evidence

Not all records that call themselves evidence hold up. Four properties separate a record you can stand behind from one that falls apart the first time it is tested.

Property	What it means	How it fails in practice
Durable	The record outlives the run, the model version, and the source systems it drew from. It is still there and still intact when the question comes months later.	The context lived in a queue that has since rolled over; the record is a pointer to a source that has since changed.
Complete	All three artifacts are present and linked: context, decision, outcome. Nothing load-bearing is missing.	The decision and the trace were kept, but the pre-decision context and the eventual outcome were never captured, so the decision cannot be checked or confirmed.
Legible	A non-engineer can read it. An auditor, a compliance officer, or a claims reviewer can follow why the system acted without reading code or parsing spans.	The record exists but only as raw traces and model output, readable by the team that built it and no one who needs to audit it.
Tied to the outcome	The decision is connected to what actually happened, so the record shows not just what was decided but whether it turned out right.	The decision is captured in one system and the outcome in another, never linked, so the record can show the choice but never confirm it held.

These four are demanding on purpose. Durability rules out anything reconstructed on request. Completeness rules out the common state of keeping the decision but not the context or the outcome. Legibility rules out "the evidence is in the logs, ask an engineer." And the tie to the outcome is what makes the record evidence of correctness rather than merely evidence of activity. A record that misses any one of the four will get you through the easy questions and fail on the one that matters.

In practice

One idea, seen across different kinds of work. These are illustrations of the concept, not product walkthroughs.

Evidence over time

There is a temptation to treat evidence as a snapshot: capture the decision, file it, done. That works right up until the world the decision lived in moves. The coverage rule changes. The plan is updated. The model is retrained and starts deciding differently. A record captured once, then left alone, slowly stops describing how the system behaves now. Evidence is not only something you hold; it is something you keep gathering, because the thing it describes keeps changing.

That is the subject of the next paper. Trust is not a state you reach and bank. It decays, and the only answer is to keep verifying. Continuous Verification takes evidence from a record you file to a loop you run.