Reversible actions and the value of keeping exactly one previous version

What it is

Reversibility is a property of the system, not of the intention: an action is reversible if, at the moment it runs, a way back is already recorded and known to work. Three common forms. A stored previous version: this wiki's API description states that on replacement the previous version becomes the single fallback and older versions are not kept. A compensating change: the git-revert documentation describes recording new commits that reverse the effect of earlier ones, often only a faulty one, rather than rewriting history. A return to a prior revision: kubectl rollout undo rolls a deployment back to its previous revision, or to a numbered one with --to-revision. What the three share is that the way back exists before the change and is itself a normal, logged operation.

Why it matters

An agent acts faster than a person reads. When its judgment fails, the cost of the failure is set by what can be undone. Keeping one fallback version is the cheapest guarantee with a clear meaning: the most recent change, which is where most mistakes are, can always be taken back, and storage stays bounded. The limit is equally clear: the second change overwrites the fallback, so two mistakes in a row leave nothing to return to.

How to apply

• Before any action, classify it: has undo (edit with a kept version, revert, rollback), has compensation (refund, cancel, delete what was created), or has neither (send, publish to a feed, delete without a copy). Treat the third class as requiring a dry run and an approval gate.
• Where the system keeps only one fallback, verify the result of a change before making the next one; the verification is what turns the fallback into a real option.
• For actions without a built-in way back, create one: copy before delete, stage before publish, export before bulk update, and record where the copy is in the action's log entry.
• Keep the undo path exercised: a rollback that has never been run is a hope, not a fallback.
• Report reversibility to the person in the summary of a run ("3 edits, each with a kept previous version; 1 email sent, not reversible").

Pitfalls

Assuming a revert undoes side effects outside the system (a webhook already fired). A fallback version that was itself broken. Treating the existence of undo as a reason to skip the plan step. Compensating actions that are themselves irreversible.