Proof is a design decision

There is a comforting belief, common in organizations that build automated systems, that proof can be sourced on demand. The decision happens; the system runs; and if anyone ever asks how a particular outcome came to be, you will reconstruct it then. Logs will be consulted, engineers will trace the path, an account will be assembled. Proof, in this picture, is a thing you go and fetch when the question arrives. It is the same intuition that lets people defer documentation, defer testing, defer the hard parts of accountability: the belief that the capability will still be there when you finally reach for it. With proof, it usually will not be.

The reason is structural, and it is worth stating plainly. A decision can only be proven sound later if the evidence required for that proof still exists later. And whether it exists is not determined when the question is asked. It is determined at the moment the decision was made, by whether the system preserved the right things. A process that did not capture its inputs, freeze its rules, and retain enough state to be run again has not merely failed to write down what it did. It has destroyed the evidence — quietly, continuously, as a matter of routine — by the simple act of moving on without keeping it. You cannot interview a record that was never created.

This is why I think of provability as an architectural property rather than a documentation task. An architectural property is one that is decided in the shape of the system and is expensive or impossible to change afterward — load paths, data flow, what is durable and what is transient. Provability sits in that category. It is fixed by what the system retains at the instant of action, which means it is fixed by design choices made long before any dispute. The system that can prove its decisions and the system that cannot are not the same system in two moods. They are different architectures, distinguishable on day one, if you know to look.

You do not decide whether a decision can be proven when someone challenges it. You decided that when you chose what the system would keep, and what it would let fall.

What proof requires, and when it can be captured

Concretely, a proof that a decision was sound has to reach three things, and each can only be captured at the time. It has to reach the inputs that were actually present — not a reconstruction of what was probably available, but the specific evidence consulted, in the form it had then. It has to reach the rules that were in force at that instant, frozen as they stood, because rules drift and a later version cannot be trusted to describe a past decision. And it has to reach enough of the system's state to replay the decision: to put the same inputs back through the same process and see whether the same outcome falls out. Replay is what turns an account into something checkable, because it does not ask anyone to believe the system's story about itself; it reruns the story and watches.

Notice that none of these three can be manufactured after the fact. Inputs not captured are gone the moment downstream state mutates. Rules not frozen are overwritten by their own successors. State not retained cannot be reconstituted from a system that has since moved a thousand decisions further on. Each of these is a use-it-or-lose-it property, available only in the narrow window when the decision is happening. Miss the window and there is no later effort, however diligent, that recovers it. There is only a more elaborate guess, dressed as a finding.

Why retrofitting fails

The standard organizational response, when accountability becomes urgent, is to commission it as a project: add logging, build a reporting layer, generate an audit trail. This works for some things and not for this. You can retrofit a dashboard. You cannot retrofit the contents of a record that was never written. A system asked to start preserving proof today can prove the decisions it makes from today forward; it can prove nothing about the decisions it already made and did not preserve. The gap is not a backlog to be worked down. It is a permanent hole, the exact shape of everything the system threw away before someone decided proof mattered.

This is the sense in which proof is a design decision and not an operational one. The choice is not whether to invest effort in accountability; it is whether the architecture preserves, at the point of action, the material that any future proof would have to be built from. A Decision Receipt is one expression of that choice made deliberately — a structure that captures the inputs, the active rules, and the replayable state as the decision occurs, so that admissibility is a property the record is born with rather than one a team scrambles to approximate later. The receipt is not the proof. It is the decision, made early, that proof will be possible at all.

I find the cleanest way to hold this is to treat provability as a question you answer in the present tense, continuously, every time the system acts — not a question you will answer in the future when challenged. The future-tense version is an illusion; by the time the challenge arrives, the answer is already fixed and usually already lost. The honest question for anyone building a consequential system is therefore not will we be able to prove this if asked. It is are we keeping, right now, what proof would require. If the answer is no, the system has already decided it cannot be proven. It simply has not been asked yet.

— Dispatches · Summit Cognitive