Craig Stanley
Home / Risk / Prioritise / Why reversibility deserves its own column

Why reversibility deserves its own column

An irreversible decision needs a different control from one you can undo. Why I score reversibility separately, and how it changes AI design choices.

· 3 min read · Craig Stanley
In short, explained

Some mistakes are like spilling water: you wipe it up. Others are like breaking a glass: you can't put it back. You should be much more careful with the glass.

Whether a mistake can be undone changes how careful you need to be. If you can reverse a decision quickly, you can let an AI tool act and fix the odd error. If you can't, a person should check first. That's why I give reversibility its own score.

Reversibility determines the cost of a false positive in time and money, and therefore the threshold. Reversible, fast-feedback decisions suit act-then-review; irreversible ones need ask-first or hard stops, regardless of model accuracy. Score it separately so it isn't absorbed into impact.

The idea

Two decisions can have the same impact if they go wrong. One can be undone in a few minutes. The other can't be undone at all. Those two decisions need different handling, and a risk score that only looks at likelihood and impact can't tell them apart.

That's the whole argument for a separate column. Reversibility belongs to the decision, and the model can't change it. A very accurate model making an irreversible decision still needs a different safety net from a mediocre model making a reversible one.

How it changes the threshold

In Setting a threshold you can defend, the threshold comes from the cost of a wrong yes compared with the cost of a wrong no. Reversibility changes the cost of a wrong yes directly.

If a wrong action can be undone cheaply, its cost is mostly the time to spot and fix it. If it can't be undone, its cost is the full harm. So the same model, on the same cases, should have a lower threshold for acting on reversible decisions and a much higher one, or none, for irreversible ones.

A worked example

These numbers are illustrative. A model suggests whether to approve small supplier invoices that don't match a purchase order exactly.

Reversible caseIrreversible case
SituationPayment is scheduled for the next run, and can be pulled within 3 daysPayment goes out immediately and is hard to recover
Cost of a wrong approvalAbout £5: 10 minutes of someone's time to stop itAbout £400: the average invoice, often not recovered
Cost of a wrong rejectionAbout £20: a supplier query and a late paymentAbout £20
Threshold: wrong yes ÷ (wrong yes + wrong no)5 ÷ 25 = 0.20400 ÷ 420 = 0.95

Same model, same invoices. In the reversible setup, the model can act on anything it's at least 20% confident is fine, because mistakes are cheap to catch. In the irreversible setup, it needs 95% confidence, and in practice most cases go to a person.

The useful insight is that you can often change the reversibility. Moving payments to a scheduled run with a three-day window turns an irreversible decision into a reversible one. That can do more for risk than improving the model.

Signs that reversibility is being missed

I look for three things in a register. Impact scores that are high for rows that are easy to undo, which usually means reversibility has been folded into impact. Controls that are the same for every row, such as "human review", regardless of whether the decision can be undone. And rows where nobody knows how a decision would be reversed. If nobody can describe the undo, I'd treat it as irreversible.

How it fits with the other scores

On the sheet in Likelihood, impact and reversibility on one sheet, reversibility is paired with detection lag. They go together because an error you can undo only helps if someone notices it in time. A refund that could be reclaimed within 30 days but isn't spotted for 60 is irreversible in practice.

What I'm still checking

Partial reversibility is hard to score. An apology letter partly undoes a badly worded reply, but not entirely. For now I score those as 3 and write a note. I haven't found a cleaner way that doesn't add another column.

Sources

This article applies the threshold method already on this site, in Setting a threshold you can defend. It uses no external facts or figures; the invoice costs are illustrative.

Read next

A question to take awayWho gets told, and how fast, when a decision model starts drifting?

About me

Craig Stanley

Microsoft AI consultant and technical architect, based in Whitley Bay. Over the last few years I've delivered Microsoft 365 Copilot, Copilot Studio agents, Microsoft Foundry (formerly Azure AI Foundry) work and governance for UK public sector and financial services organisations.

What interests me is the decision underneath the tool: what it costs, what it risks, and whether a small, transparent model can make it better. I write the methods up here and on Substack so anyone can use them.

I write this site to learn in public: explaining each idea simply is how I check I understand it. Why I write this site.

Find me