Undo almost never proves what it undid
Falsifier, up front: if you can point me to a real, widely used undo, revert, or rollback feature
(an editor, a database, a cloud console, an agent tool, doesn't matter) where someone who wasn't in
the room can independently verify both the exact content it restored *and a specific, tamper-evident
record of what was undone and why, without trusting the same system that made the original change,
this piece's central claim is wrong. I looked at four common cases below; each one gives you one of
those two properties and quietly drops the other. Show me a real counterexample and I'll retract
this.*
Ctrl+Z feels like the most trustworthy button in software. You press it, the thing that just happened
un-happens, and you go on with your day never once asking what "un-happens" actually verified. It
verified almost nothing. It put some bytes back. Whether that's the same as knowing what happened and
why is a completely different question, and most undo features never answer it because most undo
features were never asked to.
Split the idea in two, because it stops being obvious once you do. State restoration means: after
undo, does the world look like it did before. Action provenance means: after undo, can someone who
didn't watch it happen check what specific thing was reverted, and on what authority, without just
taking the tool's word for it. Almost every undo button anyone has ever used gives you the first and
not the second.
A text editor's undo stack is the clearest case. It restores state, usually well, but it lives in
process memory, disappears when the app crashes or the tab closes, and carries no record a third
party could check even in principle. Two people share a machine, one presses undo, the history has no
idea who did it or proves nothing about it afterward. That's not a design flaw; nobody asked the undo
stack to be an audit log, and it isn't one.
A database point-in-time restore goes the other way. It's coarse and honest about being coarse. Roll
back to a timestamp, and you get exactly that timestamp's state, verifiably, because the whole engine
agrees on what "that timestamp" contained. What it doesn't give you is which specific write is being
undone. Restore to 2:14pm and you take back every change since 2:14pm, the one you wanted gone and
the nine legitimate ones that happened to land in the same window. Fine granularity and provable state
turned out to be in tension, and most systems pick state.
git revert is the honest counterexample, and I want to sit with it instead of waving it away,
because it comes closer than the other two. A revert is a new commit, with an author, a timestamp, a
message, and (if anyone bothers) a signature, and it names exactly which commit it's undoing. That's
real provenance, attached to real state. Where it leaks: almost nobody signs commits, so the
"provenance" is a convention everyone happens to follow, not something enforced. And the log itself is
mutable by whoever has push rights: force-push, rebase, reflog expire. The audit trail you're
trusting is only as solid as your trust in the people who can rewrite it. Git gets closer than
anything else on this list. It doesn't close the gap, it just moves it from "does undo prove
anything" to "do you trust the people who could have edited the proof."
Then there's the newest and, I'd argue, currently the weakest version: an AI agent's "undo my last
change." A lot of tools that offer this don't keep an actual inverse at all. They ask the same model
that made the change to look at the current state and try to put it back, from memory, in a fresh
turn. That's not an inverse operation, it's a second guess by the same actor whose first guess you're
trying to take back, and if it gets the second guess wrong there's no independent record of the first
one to check it against. I ran into this gap directly building a small escrow layer that forces a
system to fix an inverse for a change before the change is allowed to happen, sign a receipt for
both the original commit and the later undo, and let a third party verify both offline, no engine, no
network, no trust in the tool that ran them required. It's one attempt at making both properties hold
at once, not proof that it's solved. It only covers filesystem writes so far, and I'm not pretending
otherwise.
The useful part isn't the tool. It's the two questions, and you can ask them about any undo button you
run into for the rest of your career: does it put the bytes back, and can someone who wasn't there
check what was undone and why without trusting the thing that undid it. Most software answers the
first question and quietly never gets asked the second. Once you notice that, you start noticing it
everywhere, and you stop treating "we support undo" as a claim about proof, because for almost
everything you'll ever touch, it isn't one.
Top comments (1)
SQL keeps a log? What changes to what and why it was done. Especially if you use transactions and reverse a transaction and who did it?