Log the override

Find the place in your system where a human can overrule the automated decision — the review queue, the approval screen, the manual flag that flips an outcome. Now look at what you write down when someone uses it. In most systems the answer is the final outcome and nothing else. The record shows the case was approved. It does not show that the model had recommended denial, that a reviewer disagreed, that she typed a reason into a box, and that six months later she turned out to be right. The system logged what happened. It discarded the fact that what happened contradicted what it recommended — and that contradiction was the most informative thing in the entire transaction.

An override is the moment a human and a machine disagree about a consequential call. That disagreement is not noise to be smoothed over. It is signal — the richest single signal a decision system produces — because it is exactly the point where someone judged the model wrong, or the model caught a human error, and either way responsibility, model failure, and human judgment all concentrate in the same event. Everywhere else in the pipeline the human and the machine are agreeing, and agreement teaches you very little. The disagreement is where the learning is, where the accountability is, and where, if something later goes badly, the investigation will begin. So of course it is the part your system throws away by default. The interesting record is always the one nobody thought to keep.

This is a build decision, and the directive is specific: capture every override as a first-class record. Not the outcome alone — the whole disagreement. What the system recommended, what the human did instead, who that human was, why they said they did it, and how it turned out. Do this in both directions, because overrides run both ways. Sometimes a person overrules the automation; sometimes the automation overrides a person's judgment, holding a line against a reviewer who wanted to wave a case through. Both are disagreements between human and machine, and both are worth exactly the same care.

The disagreement you threw away

Consider what a bare outcome log actually tells you and what it cannot. It tells you the case ended in approval. It cannot tell you whether that approval was the model's call, ratified by a reviewer who agreed, or a reviewer's call, imposed over a model that wanted to deny. Those are opposite situations with opposite implications, and the outcome record collapses them into the same row. When the case goes wrong a year later and someone asks what the system was thinking, you can produce the verdict and not the argument that produced it. You logged the destination and erased the fork in the road.

This matters more than any other gap because the override is where three things you care about live at once. It is where responsibility becomes legible, because someone stepped in and took the decision away from the default — you can see, precisely, whose judgment the outcome now rests on. It is where model failure surfaces first, because a human overruling the recommendation is a human telling you, in the field, that the model was about to be wrong. And it is where human judgment is doing its actual work — not the routine ratification of cases the model already handled, but the hard cases where a person saw something the model did not. Discard the override and you discard your only direct view of all three. You are left monitoring a system that appears to agree with itself, because you deleted the evidence of every time it did not.

The moment a human overrules the machine is the moment your system is most worth recording and most likely to forget.

What an override record must capture

An override record has to hold five things, and it is worth naming them because most systems keep one or two and imagine they have kept the rest. First, the recommendation: what the automation actually proposed, frozen as it stood at that instant, not reconstructed later from a model that has since been retrained. Second, the action taken: what the outcome actually was, so the divergence is visible in the record itself rather than inferable by cross-referencing two tables. Third, the actor: who made the override, because a decision re-assigned to a human is only accountable if you know which human. Fourth, the stated reason: what they said justified it, in their words, at the time — a free-text sentence is worth more than a dropdown, and a dropdown is worth more than nothing. Fifth, the outcome: what happened afterward, fed back in when it becomes known, so the override can eventually be scored against reality.

Then there is the case that looks like the absence of a decision and is not: the non-override. When a reviewer looks at the model's recommendation and lets it stand, that is not nothing happening — that is a human ratifying the machine, taking the model's call and making it her own. It should be recorded with the same seriousness as an override, because the difference between a decision no human examined and one a human examined and endorsed is enormous, and it is invisible unless you write the endorsement down. A system that logs overrides but treats agreements as silence has recorded only half of the judgments its people actually made. Both the override and the ratification are decisions. Capture both.

Feed the disagreement back

A record you never look at is a cost, not an asset, so the point of capturing overrides is what you do with them. They pay back in three directions. As an audit surface, the override log answers the question every oversight process eventually asks — who overrode what, and were they right — which you can answer only if you kept both the override and the outcome to check it against. As a model-improvement signal, overrides are the most honest labeled data you will ever get: when reviewers systematically overrule the model in a particular kind of case, they are marking, for free and from the field, exactly where the model is wrong, and ignoring that pattern is choosing not to learn from the people closest to the failure. And as an accountability record, the override is the trace of a human re-taking responsibility — the documented moment when a decision stopped being the system's and became a person's.

Here is the honest nuance the directive has to carry, or it curdles into a story about wise humans correcting foolish machines. Not every override is the human being right. Rubber-stamping is real — a reviewer who approves whatever is in front of her to clear a queue is not exercising judgment, she is laundering it. Reflexive overriding is real too — the person who distrusts the model on principle and overrules it into worse outcomes than it would have reached alone. An override is not self-justifying. It is a claim that the human knew better, and claims can be false. Which is precisely why the reason and the outcome are not optional fields. Capture the stated reason and you can tell a considered override from a reflex. Capture the outcome and you can tell, over time, which reviewers and which reasons actually improve on the model and which merely disagree with it. The record does not assume the override was correct. It makes the override evaluable — and that is worth keeping precisely because sometimes the evaluation will find against the human.

So instrument the disagreement. At the seam where a person can move an outcome away from the recommendation, or where the automation holds an outcome against a person, write one record: recommendation, action, actor, reason, outcome. Make it a decision the system takes seriously, not a side effect it forgets. Do this and the next time someone asks why a call came out the way it did, you can say not only what was decided but who decided it, against what advice, on what stated grounds, and whether they turned out to be right. That is the difference between a system that records its outputs and one that can account for its judgments.

— Dispatches · Summit Cognitive