What does a decision look like when you can prove it?

A loan application is declined at 14:02 on a Tuesday in March.

In a typical underwriting stack the pieces of that decision are already apart: the input sits on the originations service, the policy in a separate rules engine repo, the outcome in the core ledger, and the reasoning nowhere.

Six months later, the applicant’s solicitor writes in. By then policy v3.1 has been retired and replaced with v3.4.

The inputs survive and the outcome survives, but the policy version live at 14:02 cannot be checked against policy as it stood that afternoon. So the analyst stitches the pieces back together, and spends two weeks producing an answer that is plausible, defensible and partly invented.

A provable decision is a different shape. It is not a collection of logs, a trace or a timeline rebuilt from fragments — it is a single artefact you can retrieve, read and verify.

Captured once, not inferred later

Consider the same decision recorded as one object: not spread across systems, not dependent on what is still available, but captured at the moment it was made.

Everything needed to follow the decision is present: the input that was evaluated, the policy that applied, the threshold that triggered the outcome, the context it was made in, the exact policy version in effect, the time it happened, and a signature showing the record has not been altered since.

What the record settles is bounded, and worth stating plainly. It shows what was assessed, under which policy version, with what result, and that the content is unchanged. It does not establish that the inputs were accurate or that declining was the right call. Those remain questions for a reviewer — but they are questions asked of a record rather than of a reconstruction.

Six months later, the analyst does not rebuild the decision

When the solicitor’s letter arrives and someone asks why was this decision made, the analyst does not query five systems or reconstruct the context.

She reads it.

Better logging would not have produced this. The change is not more events about the decision; it is a different output. The system stops producing activity records and starts producing decisions.

A decision is the output, not a side effect.

A core banking platform treats a decision as something that happens inside the system and then disappears, leaving a record of activity behind it. A provable system treats the decision itself as the output — complete, self-contained, able to stand without the surrounding apparatus.

A decision the analyst must rebuild is always uncertain; a decision she can read is not, and that is the difference between logs and decision proof.

The practical standard is that anything a customer, a regulator or a risk committee may later challenge should be readable as one decision receipt rather than assembled from five systems. Take one such decision, decide what the record has to carry, and capture it where the decision is made — a receipt is what that record looks like.