Before deciding undo windows or confirmations, someone has to enumerate what can't be undone at all

What it is

Before any conversation about undo windows, confirmation strength, or hard blocks can even start, someone needs to know which actions in the product are actually irreversible — and that can't be figured out by a designer's intuition case by case. It requires a continuously maintained checklist that explicitly enumerates every action in the product with an irreversible external effect, noting why it's irreversible and how far its impact reaches. Without this checklist, any design decision about undo, confirmation, or blocking is built on a guess.

Why it happens

Irreversibility is often introduced quietly, rather than as something a feature team deliberately designed — calling a third-party payment gateway with no cancel endpoint, pushing a message straight to another person's device, triggering an effect in the physical world (printing, shipping, unlocking a door). The team building any of these is focused on whether the feature works, and may well not realize they've just introduced an irreversible action, because irreversibility isn't the feature's own goal — it's a side effect of some underlying capability it calls. By the time a user actually suffers a consequence from a mistaken action, it turns out the product contained an irreversible action that no one had ever identified or assessed — and by then the fix comes too late; what's left is a loss that already happened, not a line item that could have been caught at design time.

Where it stops holding

The checklist's job is limited to the two factual questions — is this action irreversible, and how far does its impact reach. It doesn't itself decide whether the response should be undo, confirmation, or a hard block — that's a separate design decision that has to weigh in how often the action occurs. The checklist just gives that later decision something concrete to work from; without it, none of the downstream trade-offs have anything to stand on.

Applying it

Maintain a continuously updated, product-wide inventory of irreversible actions covering anything that moves money, sends a message or data to a third party, has a physical-world effect, or permanently deletes something — each entry noting its trigger path, its blast radius, and whether it can be remedied after the fact. Make checking this list a mandatory step in any new feature's design review: whenever a feature's description includes a word like "send," "charge," "delete," or "authorize," require the owner to check the list first for whether this action already exists on it or needs a new entry. Verification: periodically sample recently shipped features and audit backward for whether every action with an irreversible external effect has a corresponding entry on the checklist. Any action found to be irreversible in production but missing from the list means the review step let it slip through — it needs to be logged retroactively and checked for whether it has a matching undo or blocking design.

Related

• Same group: A10.08.1 fault tolerance — the system stays recoverable after an error occurs · A10.08.4 preserving completed work under partial failure · A10.08.7 undo window length should scale with consequence severity
• Nearby: A10.04 description-similarity errors · A10.07 the Swiss cheese model
• Search terms: irreversibility audit · destructive action inventory · design review checklist