When the appeal outlives the system

A decision and the machine that produced it have very different lifespans, and we rarely notice the gap until it costs someone something. The machine is a temporary arrangement of code, configuration, and infrastructure that someone will eventually deprecate, migrate, or switch off. The decision is a thing that happened to a person, and the consequences of it can run for years — a denied claim, a flagged account, an eligibility ruling, a score that follows someone from one institution to the next. The software has a roadmap. The decision has a half-life. These two clocks are almost never set to the same time, and when they diverge, the person on the receiving end is the one who falls into the gap.

Consider how ordinary the gap is. The system that made a determination in one year is rebuilt in the next, ported to a new vendor the year after, and finally retired when the team that owned it is reorganized. None of this is misconduct; it is just the normal weather of operational software. But the determination it made is still in force. The person it bound still lives under it, and may only now — prompted by some downstream effect they could not have anticipated at the time — be in a position to ask how the decision was reached and whether it was sound. The right to ask has not expired. The thing that could answer has.

This is the quiet failure mode beneath a great deal of accountability theater. We build the capacity to explain a decision inside the system that made it, as a feature of that system, dependent on its databases, its logging, its particular version of the rules. The explanation is available right up until the moment the system is gone, and then it is not available at all. We have not preserved the account of the decision. We have preserved a query against a server that no longer exists.

A record that lives only inside the system that produced it dies with that system, and takes the possibility of appeal with it.

The window does not close when the system does

The right to contest a decision is governed by the consequences of the decision, not by the operational convenience of whoever made it. A statute of limitations runs from the harm, not from the last deployment. A person who discovers two years on that they were misclassified does not lose their standing because the classifier has been sunset in the interim. From their position, nothing has changed; the decision still binds them, and the question of whether it was justified is exactly as live as it ever was. The challengeable window is set by the decision's reach into a life, and that window has a way of being longer — often much longer — than any release cycle.

So the relevant question for anyone building a consequential system is not "can this decision be explained while the system is running." It is "can this decision still be answered for after the system that made it is gone." Those are different engineering problems with different answers, and most institutions only solve the first one, because the first one is the one that shows up in a demo and the second one is the one that shows up in a deposition years later, when nobody who built the thing is still in the room.

The difference turns on where the account of the decision lives. If it lives as a capability of the running system — a report you can generate, a log you can grep, a screen you can pull up — then the account is a hostage to the system's uptime. The moment the system is decommissioned, the migration drops a table, or the vendor contract lapses, the account becomes unrecoverable, and it becomes unrecoverable silently. Nobody files a notice that an appeal just became impossible. The capacity to answer simply stops being there, and its absence is discovered only by the next person who needs it.

A record that can leave home

The alternative is to treat the account of a decision as an artifact in its own right — something that is produced at the moment of decision, carries everything needed to stand on its own, and can outlive the machine that emitted it. This is the whole point of a Decision Receipt as a portable object rather than a database row: it holds the evidence that was actually consulted, the rules that were actually active, and enough state to replay the determination later, all sealed together at the time, so that none of it depends on the originating system still being alive to be interrogated. A record built this way can be handed to an archive, to a regulator, to the person it affected, and it remains an account that can be checked even after everything that produced it has been turned off.

The test is plain enough to apply to anything an institution runs. Imagine the system gone — fully retired, the team dispersed, the infrastructure reclaimed — and then imagine someone arriving with a legitimate question about a decision it made while it was alive. Is there an object that can answer them, an object that does not require the dead system to be resurrected? If the honest answer is no, then the appeal was never durable; it was on loan from the operations calendar, and it expired the day the system did, whether or not the person's right to it had. That is not preservation. That is deferral with a deadline nobody published.

None of this asks an organization to keep its software running forever, which would be absurd. It asks for something narrower and more achievable: that the durable thing be the record, not the runtime. Systems are supposed to be replaceable; that replaceability is a virtue, and pinning accountability to a system's continued existence quietly converts that virtue into a liability for the people the system acts upon. Decouple the account from the machine, and the machine can be retired with a clear conscience, because the decisions it made remain answerable for as long as they matter. Leave them coupled, and every sunset is a small, undeclared amnesty — one the institution grants itself, at the expense of whoever still has standing to ask.

— Dispatches · Summit Cognitive