The right question for a confirmation screen isn't "how risky is this," it's "can I undo it"
Been iterating on confirm-before-execute UX for a phone assistant, and I've been sorting actions the wrong way. My instinct was to bucket by category — messaging, calendar, device control — and give the "sensitive" categories more scrutiny.
Got pushed on this in a thread this week and it reframed the whole thing: the real split isn't risk, it's recoverability. Toggling wifi and moving a calendar event with notice are both trivially reversible, regardless of category. Sending a text, placing a call, deleting something — not really, especially once another person's seen it. There's no unsend on a message someone already read.
That test survives contact with real cases better than "how dangerous does this sound," because the two come apart constantly — a scary-sounding action can be fully reversible, and a boring-sounding one can't be undone at all.
Practical result: collapsing every low-stakes, reversible step into one compact plan, and giving anything irreversible its own explicit line instead of burying it in a bulleted list — even if that makes the screen slightly longer.
Curious how others building confirmation/approval flows have drawn this line. Risk-based, recoverability-based, or something else entirely?
Recoverability is the right axis, and it points to a stronger conclusion than a better prompt: wherever you can build an undo, build the undo instead of the confirmation. We learned that running managed services, where every added approval step trained people to click through without reading, so the prompts meant to protect them became the reason they got burned. For the set that truly cannot be undone I would add one more axis, whether another person is affected, because that is what separates a sent text from a deleted file and it is the only case worth a full-screen interruption.
"Build the undo instead of the confirmation, wherever you can" is a better default than anything in my original framing — I was treating confirmation as the fallback for irreversibility, not asking whether the irreversibility itself could be engineered away first. Your managed-services data point makes the case concretely: every extra approval step is confirmation fatigue you're borrowing against, and you eventually pay it back at the worst moment.
The other-person axis is the sharper addition though, and it might actually subsume recoverability rather than sit alongside it. A sent text is irreversible mainly because someone else has already seen it — the message itself could technically be deleted from your device, that does nothing once it's been read. So maybe the real rule is: undo where the action only touches your own state, full-screen interrupt only where another person's state has already changed and can't be reached back into.
That reframes my "irreversible" bucket as mostly a proxy for "involves someone else" rather than its own independent thing. Going to sit with that before I redraw the line — might collapse two categories into one.
The reframe survives an even harder test, reversibility isn’t binary either. Your question is better to be how completely you can undo it and at what cost. A deleted file with a backup is cheaply reversible. A sent email is socially irreversible but factually correctable. A published number sits somewhere in between. So the confirmation screen’s real job isn’t just to say whether an action is reversible. It should tell you "what kind of undo is actually available".
There’s also a useful asymmetry rule that follows from this. When the system can’t determine whether an action is recoverable, it should default to treating it as irreversible (never quietly assume the opposite). That’s the failure mode I’d worry about with risk-scored confirmations: “low risk” gradually becomes a bucket that silently absorbs “unknown risk.”
"What kind of undo is available" is a better question than "is it reversible," and it composes with something I got pushed on in a parallel thread — the cost of undo and whether another person is affected might be measuring the same underlying thing from two directions. A deleted file with a backup is cheap to undo because the damage never left your own state. A sent email is expensive or impossible to undo precisely because someone else's state changed the moment it landed. So "cost of undo" might just be "reversibility" restated, and "who else is affected" might be the actual causal reason costs jump from cheap to near-infinite rather than a separate axis.
The unknown-defaults-to-irreversible rule is the one I'll actually take and use directly, no modification needed. It's the same shape as fail-closed in security design, and I hadn't made that connection until you said it — "low risk" quietly absorbing "we didn't check" is exactly the kind of bug that wouldn't show up in testing, since testing tends to only exercise cases you already thought to handle.
I like the shift from risk to recoverability. It also makes me wonder whether "can I undo it?" sometimes needs one more question: "what remains after I undo it?"
Some actions are technically reversible, but the consequences aren't. Restoring a deleted record doesn't necessarily restore the notification someone already received, or the decision someone already made based on it.
That makes recoverability feel less like a property of the action itself and more like a property of the whole system around it. The confirmation UX then becomes a way of exposing that consequence before execution.
This is the piece that ties the other threads on this post together, I think. Gregory's "does it affect another person" and Andrewed's "reversibility isn't binary, ask what kind of undo" both point at something, and "what remains after undo" is the actual mechanism underneath both: the record can be restored, but any downstream effect that already left your system — a notification, a decision someone made off of it — is now running on its own and doesn't roll back just because the source data did.
So recoverability isn't really about the action or even the system around it, it's about how far the consequence has already traveled before you hit undo. A deleted-then-restored file has consequences that never left your own machine. A booked-then-cancelled calendar slot has a consequence (the other person saw the invite) that's already sitting in someone else's head, and no amount of restoring your own record touches that.
Which maybe means the actual confirmation-screen question is closer to "has this already left the building" than "can I technically reverse it." Undo the local state all you want, it's whether something downstream already happened that determines whether you needed to ask first.
Yes - "has this already left the building" gets much closer to the real boundary.
It also changes how I think about confirmation. The point isn't necessarily to slow down actions that are risky; it's to pause before an action crosses a boundary where its consequences are no longer fully under the user's control.
Once something has crossed that boundary, undo becomes recovery rather than reversal.