Default to reversible

Before you write the action, write the undo. Not as a stretch goal, not as a fast-follow, not as the thing you will add once the feature ships and someone asks for it — before. When your system does something consequential to a person, a balance, or an account, the first question at the design table should not be how to execute the action. It should be how to take it back. Because reversibility is one of those properties that costs almost nothing to design in at the start and is close to impossible to bolt on afterward, and the day you discover you needed it is the day it is already too late to have it.

Most systems default the other way. The natural shape of code is immediate, hard, irreversible execution: the row is deleted, the message is sent, the funds move, the account is closed, and the function returns. It is the simplest thing to build, so it is what gets built. Reversibility asks for more — a staging area, a pending state, a window during which the action is intended but not yet final, a way to represent the difference between decided and done. That extra structure looks like overhead right up until the moment an error has become a fact in the world, and then it looks like the only thing that would have mattered.

This is the trap. The cost of irreversibility is invisible while you are shipping and catastrophic once you have shipped, so it is exactly the cost a delivery deadline will talk you out of paying. You will not feel the absence of the undo when the feature works. You will feel it the first time the feature is wrong about someone — and by then the account is closed, the notice is sent, the record is gone, and the remedy you would have reached for was foreclosed by a design decision nobody remembers making.

Build the undo first

The reason to build reversibility first is not discipline for its own sake. It is that reversibility is a structural property of a system, and structural properties have to be designed in from the frame. A soft-delete is trivial if the schema was built to carry a deleted state and nearly a migration nightmare if it was not. A staged rollout with an abort window is a natural shape if execution was modeled as a queued, cancellable job and an architectural rewrite if the action was wired to fire synchronously the instant it was decided. You are not adding a feature when you add reversibility late. You are changing the physics of the thing after it has set.

And the action you most need to be able to reverse is precisely the one a naive design makes hardest to. An irreversible action forecloses its own remedy: it does not merely risk being wrong, it removes the ability to correct being wrong. The decision that turns out to need undoing — the wrongful closure, the mistaken flag, the deletion that should not have run — is by definition a consequential one, and consequential actions are where irreversibility does the most damage and where systems most often default to hard execution because that is where the code feels most decisive. Build the undo first and you have it for the case that will need it. Build it last and you build it, if you ever do, for the cases that never will.

Reversibility is an accountability property

It is tempting to file all of this under user experience — the courtesy of an undo button, the polish of a grace period. That undersells it. Reversibility is an accountability property, and it changes what the rest of the system owes. An irreversible action forecloses the remedy, so it has to carry a far stronger justification and clear a far higher bar before it fires: if there is no taking it back, the record that authorized it had better be complete, the rules it followed had better be frozen and legible, and the threshold it crossed had better be one someone was willing to defend in advance. Irreversibility raises the evidentiary stakes of everything around it, because it is the one case where getting it wrong cannot be fixed, only litigated.

A reversible action forgives a thinner record, because it offers something better than a strong record: it offers a correction. When a mistake can be undone, the response to error is to reverse it, not to argue about it. When it cannot, the response to error is a dispute — and disputes are expensive, slow, adversarial, and frequently unjust to the party with the least power to sustain one. This is the connection the series keeps returning to. An explanation you cannot act on is a courtesy. An action you can undo is a remedy. Reversibility is the other half of accountability, the half that turns a good record from a document into a lever.

An irreversible action is a decision that has pre-spent its own appeal; design as if you will be wrong, because sometimes you will be.

Make it the default, justify the exceptions

So make reversibility the default for consequential actions, and invert the burden. The patterns are ordinary and well understood: a hold before a hard commit, a staged rollout with an abort window, a queued execution that can be cancelled before it runs, a soft-delete that precedes any hard one. None of these are exotic. What is uncommon is treating them as the default and requiring an explicit, recorded decision to opt out — to make something irreversible on purpose, with the stronger justification that irreversibility is now understood to demand. Flip the smell. “Irreversible by default” should read as the thing that needs defending, not the thing you assumed. If an action is going to be unrecoverable, someone should have decided that, in writing, and been willing to say why the window was not worth the wait.

This is a default, not a universal law, and honesty requires saying where it stops. Some actions are genuinely irreversible and no amount of design will make them otherwise. A message, once sent, has been read. A physical act, once taken, has happened. An external system you do not control has done what you asked and will not un-ask it. Reversibility cannot be conjured where the world does not allow it. But notice that the answer for those cases is not to shrug and let them fire like any other action — it is the opposite. The genuinely irreversible action is exactly the one that earns the pre-commit human gate and the strong record: the deliberate pause, the confirmation, the account complete enough to justify a step that cannot be walked back. You cannot give those actions an undo. You can give them the seriousness that the absence of an undo demands.

The rule, then, is not that everything must be reversible. It is that reversibility is the default you build toward and irreversibility is the exception you justify — with a window where a window is possible, and with a gate and a record where it is not. Design as if you will sometimes be wrong, because you will be, and the whole question is whether being wrong is something your system can correct or only something it can regret. Build the undo first, and it can correct. Ship the action alone, and all it can do is regret — after the mistake has already become a fact about someone else's life.

— Dispatches · Summit Cognitive