Reversibility

What Reversibility means

Reversibility is whether a decision or action can be undone at low cost if it turns out wrong. The site’s articles give plain examples on each side. A routing choice or a password reset can be undone. A dismissal, a declined application or a public commitment made in a client’s name cannot.

The word “low cost” matters. Almost anything can be undone at some price. The question the term asks is whether the undoing is cheap enough that a mistake is an inconvenience and not a harm. A ticket sent to the wrong queue can be moved in seconds. A candidate who has been told no cannot be easily told yes without a change in how they see the business.

Why it is one of the clearest tests of Authority

The task and decision article uses reversibility to decide how much authority to give a step. It is one of five questions: how often the work happens, what a wrong outcome costs, whether it can be undone, how clear the governing rules are and whether the outcome needs a kind of legitimacy a model cannot hold.

The reason it works as a test is that it asks about the cost of being wrong, not about the chance. A system can be accurate most of the time and still be the wrong thing to leave unsupervised, if the occasional mistake cannot be taken back. The article’s pair of examples shows this. A password reset is reversible in moments, happens often and follows a rule with no ambiguity, so it climbs to Execute. A candidate shortlist is harder to undo once a candidate has been told no and is judged against criteria that are never perfectly fixed, so it stops at Recommend, with a person accountable. The delegation ladder page covers all four levels.

Reversible and irreversible steps in practice

The two sides tend to look like this across the site’s articles.

• Reversible: a draft nobody has sent, a routing choice, a password reset, a summary kept inside the team, a checklist built from rough notes.
• Hard or impossible to undo: a sent email, a reply to a customer that went out unchecked, a dismissal, a declined application, a public commitment in a client’s name, money that has been moved.

The first-task article draws the line between a draft and a sent message, and it is the clearest everyday version of the idea. A draft nobody has sent is fully reversible. A sent email is not. Between the two sits a step that is easy to miss: the moment of sending, releasing or approving. That moment is where most of the reversibility of a workflow is won or lost.

Why a first task should be reversible

The first-task article makes reversibility one of four properties of a good first AI task, with being frequent, checkable and low-consequence. It calls keeping a step reversible the cheapest form of safety there is.

It also treats the cost of a wrong result as a gate and not a score. If a wrong result means some wasted minutes inside the team, the task is a candidate. If it means an upset customer, a wrong figure in a document that leaves the building or an unfair outcome for a person, it is not a first task, however well it scores elsewhere.

The deeper reason is that a first project is a training exercise. The team needs to learn what a good result looks like, what a plausible but wrong one looks like and how long the checking takes. That is cheap to learn on a task whose output stays inside the building, and expensive on one whose output does not. The task automation page covers the kind of work that passes.

Turning an irreversible step into a reversible one

An irreversible step does not have to stay that way. The usual move is to put a pause before it.

The first-task article gives the example. An unchecked reply turns a drafting task into a decision made in the business’s name, and a wrong answer is public and hard to undo. The safer first step is AI proposing a reply that a named person reads and sends. Nothing goes out until a person has decided, so the step is reversible until the moment of sending.

The guardrails page says the same in general terms: a guardrail that holds a draft until someone releases it turns an irreversible step into a reversible one. The human in the loop page describes the person who does the releasing.

Held or reversed

When something goes wrong, there are two ways to deal with it, and they are different designs. The exception handling page sets them out. A held action waits: the invoice is not paid, the message is not sent and the case sits in a queue until a person decides. A reversed action has already happened and is undone, which is only possible where an undo exists.

The page’s advice follows from the idea of reversibility. The more consequential the action, the more it should be held before it lands and not reversed afterwards. For actions that are hard to undo, such as sending messages or moving money, holding before approval is the safer design. Deciding which of the two applies, and who owns the queue, is something the page says should be done before the workflow goes live.

Limiting the worst outcome

Reversibility is also a design habit for risks that cannot be removed. The prompt injection article is plain that the problem cannot be fixed completely. Its advice, drawing on the UK National Cyber Security Centre, is to design on the assumption that the model can be confused, and to use ordinary controls that are not AI to limit what it can do, especially its access to tools and systems.

The article’s frame is the one this page keeps coming back to. You do not need to win an argument with a language model. You need to make sure that when one is fooled, the worst outcome is small, visible and reversible. A tool that can only draft cannot send. A tool that can only read cannot change a record. Each limit makes a mistake easier to undo.

Questions to ask a vendor

The workflow article adds two questions for when a system can take actions that are hard to undo, such as sending messages, changing records or moving money. The first is what level of human oversight is built in, meaning where a human in the loop has to approve, and whether that is a deliberate design decision or a limitation nobody has mentioned. The second is whether the system is running with real autonomy at a live customer today, and not in a sandbox built for demonstrations.

The article says vendors with real production experience answer both quickly. Others reach for the roadmap.

A worked example

An illustration, not a case study. A small firm wants an AI tool to deal with incoming supplier invoices.

Reading each invoice and entering its figures into a draft record is reversible. The draft can be corrected or deleted and nothing has left the building, so the firm lets the tool do it. Matching the invoice to a purchase order is a check against a source, so it stays reversible too.

Paying the invoice is different. Once money has moved, it cannot be called back at low cost. So the firm does not let the tool pay. The tool places the matched invoice in a queue, held, and a named person approves it. When a supplier changes its layout and the tool starts producing odd results, those cases appear in the queue and are caught by the person approving. Nothing has been paid wrongly, because the step that could not be undone was held until a person released it. The firm did not need the tool to be perfect. It needed the one irreversible step to wait for a person.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is treating accuracy as a substitute, when a system can be right most of the time and still be wrong to leave unsupervised if the rare mistake cannot be taken back. The second is assuming that “we can fix it afterwards” holds for everything, when a sent message, a declined application or money moved cannot be recalled at low cost. The third is confusing held and reversed, when one is a pause before the action and the other is an undo after it. The fourth is treating reversibility as a one-off judgement, when it is a property that can be designed in, by holding a draft until a person releases it.

How we use it

The task and decision article uses reversibility to place each step on the delegation ladder at scoping. For actions that cannot be undone, the exception handling page sets out the choice between holding an action and reversing it, and the workflow article gives the questions to ask a vendor.

If you would like to talk through which steps in your own processes can be undone and which cannot, a discovery call is a quick way to start.

Sources

• The difference between automating a task and automating a decision: reversibility as one of the five questions, the password reset and shortlist pair, and what stays with a person.
• Which AI tasks should a small business start with first?: reversibility as one of four properties of a first task, a draft against a sent email, the cheapest form of safety and an unchecked reply as a decision in the business’s name.
• How to tell a real AI workflow from a chatbot in disguise: the human-approval and live-customer questions for actions that are hard to undo.
• What is prompt injection?: designing on the assumption the model can be confused, ordinary controls to limit what it can do, and the worst outcome being small, visible and reversible.
• Exception handling, Guardrails, Delegation ladder, Task automation, Decision automation, Human in the loop, Well-scoped workflow and Audit trail: the neighbouring terms this page links to.