Designing Reversibility Into the Product

Designing Reversibility Into the Product is the work that makes Chapter 3's higher shapes available. Reversibility is not a property a system happens to have; it is a set of features somebody builds, and the amount a product genuinely has is almost always less than the amount its team assumes.

Key takeaways

• Ask who can reverse an action, using the product, in under a minute. If the answer involves an engineer or a database session, the product has no undo.
• The commit point is the object to design. Everything before it is staged and free to discard, and everything after it costs something to reverse.
• Reversibility can be manufactured where the domain does not supply it, usually by staging, a delay window, or batching commits into a reviewable set.
• Effects that leave your boundary are the hard cases. A sent message, a fired webhook and a cleared payment cannot be rolled back, only compensated for, and a compensating action is a new event rather than an erasure.
• Reversal has to be a normal operation with a normal interface. An undo path that is only ever exercised during incidents is a path that does not work.

Read this after Chapter 3, which decided which actions the system may take on its own, and before Chapter 5, which handles the cases where the system should decline rather than act. Chapter 11 designs what the user sees when a reversal is needed.

The design review reaches the undo question and the answer is confident. Everything is soft deleted, so nothing is ever really lost.

Somebody asks how a user undoes the specific thing the AI just did. There is a pause.

Soft deletion means a row carries a flag, and setting that flag back requires a query nobody has written, run by an engineer who has production access, after the user has described what happened well enough to be found. That is data recovery. It is not an undo.

Undo is a feature, and it has a test

The word gets used loosely, so it needs a test sharp enough to fail.

The test is this: can the person affected by the action reverse it themselves, through the product, in under a minute, without asking anyone. If any clause fails, the product does not have an undo for that action, whatever the database supports.

Run it honestly and most products fail for most actions. There is version history for documents and nothing for settings. There is a soft delete on records and no way to reach it. There is a support process that takes two days.

This matters more than it seems, because Chapter 2's second gate was reversibility, and the gate was being answered from the database's perspective rather than the user's. A feature scored reversible because a row can be restored is a feature that has been mis-scored, and it may have been promoted to act on that basis.

Four kinds of reversal, and what each costs

Not all reversal is the same operation, and being precise about which one an action needs prevents a lot of vague design.

Discard is the cheapest, and it is only available before a commit. The work exists in a staged state, nobody has relied on it, and abandoning it costs nothing but the compute already spent. Every design should try to spend as much time here as possible.

Rollback restores the previous state exactly. It works for state you own and version, it requires that you kept the prior value, and it is clean for a record and awkward for a derived thing like a search index or a cache, which have to be rebuilt rather than restored.

Compensation does not restore the previous state. It performs a new action intended to offset the first: a refund against a charge, a correcting entry against a posting, a follow-up message against a wrong one. The history now contains both events, which is sometimes exactly right and sometimes an embarrassment.

Acknowledgement is the last resort and it is still a design choice. Nothing can be technically reversed, so the product tells the truth, records what happened, and provides a route to a human. Choosing this consciously is very different from discovering it during an incident.

The commit point is the design object

Given those four, the highest-leverage decision is where the commit sits, because the commit is what separates discard from everything more expensive.

Push it as late as the product can bear. A model that has drafted, checked, retried and staged its work has cost you compute and nothing else. The instant it commits, you are in rollback, compensation or acknowledgement territory for every effect.

Making the commit explicit has a second benefit, which is that it becomes a place to attach things. Verification runs there. Policy checks run there. The audit record is written there. Confidence thresholds from Chapter 5 are evaluated there. Without a distinct commit point, those controls end up scattered through the code and some of them end up nowhere.

The pattern generalises beyond AI features, and AI features make it urgent. A deterministic system with a clear commit point is well engineered. A probabilistic one without a commit point has no boundary between thinking and consequences.

Manufacturing reversibility where none exists

When the domain does not offer reversibility, it can often be constructed, and this is product work rather than a technical trick.

Staging is the first move. The action produces a pending object rather than a real one, and a separate step promotes it. This converts an irreversible operation into a reversible one plus a commit, and it is what turns act into draft for the specific action that needed it.

A delay window is the second, and it is underused. The action commits, and the effect is scheduled rather than immediate, with a visible cancel available during the window. Sending mail after a thirty-second delay costs almost nothing in user-perceived value and converts a permanently irreversible effect into a reversible one for the period when mistakes are most likely to be noticed.

Batching is the third. Instead of committing each item as it is decided, accumulate a set and commit it as a reviewable group, which gives one human pass over many decisions and one reversal for all of them. This is how a high-volume drafting feature stays affordable in review terms.

Shadow mode is the fourth, and it belongs in every rollout. The system performs the action into a log without effect, so accuracy can be measured on live traffic before anything is at stake. It is reversibility taken to its limit, since nothing happened at all.

Effects that leave your boundary

Everything above assumes you own the state being changed. The hard cases are the effects that escape, and they need naming individually because teams keep forgetting one.

Messages to people are the most common: email, SMS, push, chat. Once read, they cannot be unread, and a recall feature is a request rather than a mechanism. Money movements are the second, where a cleared payment is reversible only by a second payment with its own fees and its own record.

Calls to third-party systems are the third, and the worst-behaved. A webhook you fired, an order you placed in a partner's system, a record you created in a customer's CRM: the reversal depends on somebody else's API offering one, and many do not.

Anything a human has acted on is the fourth and least tractable. Once a person has read the wrong number and made a decision from it, no technical reversal reaches the consequence.

The design rule that follows is short. Every boundary-crossing effect gets its own explicit decision about shape, and none of them should sit behind an autonomous action without a delay window, a confirmation, or a documented acceptance of the risk.

Compensation is a new event, not an erasure

Compensating actions are the standard answer for irreversible effects, and they are routinely oversold, so it is worth being precise about what they buy.

A compensating action restores the business position, approximately, while leaving the history intact. A refund puts the money back and leaves a charge and a refund on the statement. A correcting entry balances the ledger and leaves two entries. A follow-up email corrects the record and leaves the customer having read both.

That residue is the cost, and it is not always tolerable. Two payment events on a customer's statement may trigger their fraud process. A correction to a regulator is itself a notifiable event. An apologetic follow-up is evidence of an error rather than the absence of one.

So compensation should be designed, tested and rehearsed rather than assumed. Write the compensating action for each irreversible effect at design time, and know its residue. If the residue is unacceptable, the effect needs a shape that prevents the mistake instead.

Make reversal a normal operation

An undo path that only runs during incidents is a path nobody has tested, and it will fail on the day it matters.

Three habits keep it working. Put reversal in the ordinary interface, where the person who took the action can find it without a support ticket. Exercise it continuously, which happens naturally when it is easy and needs a scheduled drill when it is not. And measure it, because the rate at which users reverse an AI action is one of the most honest quality signals the product produces.

That last point is worth more than it sounds. Reversal rate is cheap to collect, hard to game and directly meaningful, and it is the metric Chapter 12 uses when deciding whether the feature should continue to exist.

There is an organisational version of the same idea. MIT's Project NANDA report attributes the gap between successful and stalled generative AI deployments to integration and organisational learning rather than model quality, and an undo that requires an engineer is an integration failure of exactly that kind.

A worked example, composited and labelled

The details are composited from ordinary product shapes rather than one system, and the shape is exact.

A billing product adds an AI feature that reconciles incoming payments against open invoices. The first design matches and posts automatically, because matching accuracy tested well.

Reversibility analysis changes it in four places. The match becomes a staged proposal rather than a posting, so the common case is discard rather than rollback. Postings are batched into a set an accountant approves once, which keeps review affordable at volume. The customer notification that a payment was applied moves behind a delay window with a cancel, because a notification is a boundary-crossing effect. And for the small set of postings that must happen without review, a compensating correcting entry is written, tested and documented in advance.

The accuracy of the matching model is unchanged. The feature is now shippable, because the expensive reversal paths are reserved for the cases that genuinely need them.

The objection: staging and delay make the product feel slow

This is a real product cost and the objection should not be dismissed, because a feature nobody uses because it feels sluggish has no value regardless of its safety.

The first part of the answer is that the perceived cost is smaller than it seems for asynchronous effects. Nobody notices a thirty-second delay on outbound mail, because nobody is watching the outbox. A delay window on something the user is waiting for is a different matter and should not be used.

The second part is that staging often improves perceived quality rather than harming it. Users of drafting features regularly report that seeing the work before it commits is the feature, because it converts anxiety about what the system might have done into confidence about what it did.

Where the objection genuinely holds, the resolution is per action rather than global. Keep the interactive path immediate and reversible in your own state, and reserve the delay for the boundary-crossing effects where the asymmetry is stark: a small delay against an unrecallable mistake.

Chapter summary

Reversibility is built rather than possessed, and the test is whether the affected person can reverse the action themselves, through the product, in under a minute, without asking anyone, which most products fail for most actions because their reversibility was scored from the database's perspective rather than the user's. Four kinds of reversal cost different amounts: discard, available only before a commit and costing nothing but spent compute; rollback, which restores owned and versioned state and requires rebuilding derived things like indexes and caches; compensation, which offsets rather than erases and leaves both events in the history; and acknowledgement, which is a legitimate conscious choice and a poor discovery during an incident. The commit point is therefore the object to design, pushed as late as the product bears, and made explicit so verification, policy checks, audit records and confidence thresholds have somewhere to attach. Where the domain offers no reversibility it can be manufactured through staging, which converts an irreversible action into a reversible one plus a commit, a delay window with a visible cancel, batching that gives one human pass and one reversal over many decisions, and shadow mode that measures accuracy on live traffic while nothing happens. Effects that leave your boundary are the hard cases, being messages people have read, cleared payments, calls into third-party systems whose reversal depends on somebody else's API, and anything a human has already acted on, and each needs its own explicit shape decision rather than sitting behind an autonomous action. Compensation must be written, tested and rehearsed per irreversible effect, with its residue understood, since two payment events or a correction to a regulator may themselves be the problem. And reversal must be an ordinary operation in the ordinary interface, exercised continuously and measured, because the rate at which users reverse an AI action is a cheap, ungameable quality signal.

Reversibility handles the wrong answers the system commits. The better move, where it is available, is not committing them: letting the product decline when it is not sure, and making that decline useful. Chapter 5 is Confidence, Abstention, and Escalation.