A decision log nobody can replay is not a ledger

Picture a supplier disputing an order six months after it was placed. The quantity was three times the usual, the goods were made to order, and the buyer now says the order was a mistake. The order was placed by software. You open the logs and find exactly what logs usually contain: a timestamp, a job identifier, a request to the supplier’s endpoint and a success response.

What you do not find is anything that explains it. Which demand forecast was the system looking at? That table has been recalculated every night since. Which version of the ordering rules was active? They have been edited twice. Did it consider a smaller order and reject it? Nothing says so. The decision happened, and the reasons for it no longer exist anywhere.

Logs and ledgers answer different people

The cause is not carelessness. Logs are written for an engineer debugging a problem that is happening now: events, errors, durations, enough context to find the failing line. They assume a reader who already knows the system and is looking at it the same day.

A decision ledger is written for somebody else entirely: the owner who has to answer for the decision, the auditor, the counterparty, the court. That reader arrives months later, does not know the system, and needs to know what it saw, what it concluded and why. In an operation where a person approved every consequential step, the person was the ledger, more or less. Remove the approval, as we argue in the last human in the loop is a signature, and the record has to carry what the person used to carry in their head.

Where decision records fail

They record actions, not observations. “Order sent” is an action. What the system saw before sending it is the part that explains the action, and it is usually stored only by reference to tables that keep changing. A reference to mutable data is not a record of it.

They do not pin versions. “Rule 7 fired” means nothing once rule 7 has been edited. The same goes for model versions, prompts, thresholds and configuration. A record that names logic without naming its exact version will eventually describe something that never ran.

They can be edited by the thing they record. If the loop has write access to its own history, the history is a claim, not evidence. This does not require malice; a cleanup job or a migration is enough.

They stop at the action. Nothing links the decision to what happened next. Without the outcome attached, nobody can compare what was expected with what occurred, and the part of the system that is supposed to improve has nothing true to learn from.

They are kept by accident. Retention is whatever the logging tool shipped with. The questions that matter, such as a dispute, a claim or an inspection, tend to arrive long after a default retention window has closed.

What a ledger entry has to contain

Four parts, each of them answerable from the record alone:

What was observed. The inputs as they were at that moment, either copied or stored by content hash against data that is never overwritten.

What was concluded. The decision, the alternatives that were considered and rejected, and the exact version of every piece of logic that produced it. If a model was involved and its output can vary between runs, its raw output goes in the record too.

What was done. The action as it was actually sent, with the counterparty’s reference, so that the entry can be matched to the other side’s records.

What happened next. The outcome, attached later and linked to the entry, so that the record of the decision and the record of its consequences are one thing rather than two systems that have to be reconciled.

Around those four parts sit three rules. The ledger is append-only. It lives outside the loop’s write path, under credentials the loop does not hold. And its retention is set by the longest period for which anybody could be asked about a decision, not by disk budget.

None of this is exotic. EU rules on artificial intelligence increasingly expect systems that make consequential decisions to keep automatic, traceable records over their lifetime, though what exactly applies in a given case depends on the sector and the use. The open question is not whether records are kept but whether they can answer anything. The useful standard is replay: given an entry, can you re-run the decision with the same inputs and the same versions and get the same answer? If you can, the ledger explains the decision. If you cannot, it only proves that one was made.

It is also what makes self-repair auditable. A system that can rebuild its state from a durable record and a system that can explain its decisions from one are drawing on the same discipline.

A test you can run today

Pick one automated decision your systems made last month: an order, a price change, a refund, a ticket closed without a human. Give yourself an hour and answer four questions from records alone, without asking anybody:

1. What did the system see when it decided?
2. Which version of the logic made the decision?
3. What else could it have done, and why did it not?
4. What happened afterwards?

Count the answers you could find. Every one that depended on somebody’s memory is a gap that an autonomous operation would not be able to fill, because the person who remembers is exactly the one it removes.

The ledger is one of the six components this programme treats as essential, and it is the one that decides whether the others can be checked at all.