Can you get it back?

An AI agent has just changed forty files. Some of it is wrong. How much of it can you actually get back?

Everyone has destroyed something they needed. A file overwritten, a branch force-pushed, a folder deleted from one directory up. Good times.

And it is usually the last one. What that experience delivers is a flinch reaction. From then on you commit before the risky step, you read the path twice before you press enter, and you feel the difference between a command that can be undone and one that cannot. Nobody trained you. That one experience did.

An agent has no flinch. It runs a destructive command with precisely the confidence it brings to listing a directory, because nothing in its experience separates them – it has no experience. It will not hesitate before the irreversible step, and it does not get more careful after the incident, because as far as it is concerned there was no incident.

Which lands on the one mechanical fact underneath this whole register: every recovery mechanism has to exist before the change it recovers from. Human caution is what normally buys you the time to install one. Without it, the mechanism is either already there or it is not.

So every fix on this page is external, and most of it is a setting rather than software. You are not making the agent careful. You are making the dangerous thing either impossible, or cheap to undo.

What this register does

The recovery register names the 24 ways a change becomes irreversible, from the moment it is made to the moment nothing will bring it back. The register carries 19 evidenced rows and five candidates; the hub's headline counts count evidenced rows only. Three can be made impossible. Ten can be undone if the right thing was in place beforehand. Eleven cannot be undone at all.

The register produces one working rule: decide what a restore point covers before you need one, because every mechanism that gets you back had to exist before the change did.

This is a technical page listing every row in the register and what it costs, what closes it (if anything). It sits under the hub. Its companion page is can you believe your agent?, the truth register, which asks whether the agent's account of the work can be trusted – a different question with a different answer.

Many of the controls on this page are standard software engineering – protected branches, backups, down scripts – and experienced engineers already run some of them.

What the register adds is the failure behind each control: which failures are prevented, which are only recoverable, and which ones nothing gets back. This shows where your remaining gaps are.

The question this register asks

Can you get it back? The unit this register tests is a change:

• A file edited in place.
• A migration run against real rows.
• A branch force-pushed over the only copy.
• An email that has already left the machine.

Each one has a life. The register grades each failure by what it costs to undo and by whether anything gets you back at all.

None of this is new. The failure mode is ordinary; what has changed is the rate. A session that edits forty files in 20 minutes compresses a week of change into an afternoon, across paths a person would not have touched, at a speed nobody reads at.

Why the plan is not the mechanism

The property that makes this register worth having is easy to state and hard to act on. Recovery class is a property of the mechanism, not of the change. This is why the register grades mechanisms rather than intentions, and why only a mechanism that refuses the action yields the top class. Everything else is a promise about the future made by people who will be busy at the time.

Severity here means the cost of getting back, multiplied by how quietly the change goes unnoticed. S1 you undo in seconds. S2 you undo with effort. S3 you undo only by rebuilding it by hand. S4 cannot be undone at any price.

The distribution is also revealing. Twelve of 24 rows are S4, and none is S1. This is what makes working with agents so risky if the right controls aren't in place.

How this register works

The recovery register lists 24 failures and grades them against a base install – an agent, a repository, a CI pipeline, and nothing else pointed at this problem. It then names the strongest mechanism you can add against each one. Whether any of them is actually switched on is a separate question, and one you answer against your own configuration. The source repository is private. You can read the catalogue on these register pages.

The rows were derived by working through the life of a change, stage by stage, and asking at each stage what could go wrong and what would get you back. Every register in this framework is built that way rather than from an incident log, because selecting for "we have seen this go wrong" filters out the failures that never announce themselves.

Nine of the 24 are recorded here with dates. 15 are not, and that number means something different on this register than it would on Truth. A recovery failure is not silent – losing work is the loudest thing that happens in a week. So a low first-party count here is not evidence that the mechanisms are untested; it is a consequence of how the register was built, and of the fact that most of what is listed has a mechanism precisely because somebody already lost the work once.

The life of a change: five stages and an assurance band

Rows are grouped by how far a change has travelled when the failure bites. The stages are sequential, and the ordering is the point: the further along, the less gets you back.

1. Captured – is there a point to go back to? Whether any restore point exists between the last good state and now. Six rows.
2. Contained – how far can one mistake reach? How much of the machine, the account and the production estate a single turn can touch. Four rows.
3. Noticed – do you find out while it is still cheap? Whether the damage surfaces in the session, at review, or in July. Four rows.
4. Reversible – can the change be taken back? Whether the mechanism to undo it was written alongside it. Five rows.
5. Restored – does undoing it put you back? Whether the reversal returns you to a working system rather than half of one. Three rows.

Cutting across all five is an assurance band, Rehearsed – would you get back if you had to today? Two rows. It is not a sixth stage. Each of its rows asks whether the stages above would actually hold under a real attempt, which is a question nobody asks until the attempt is happening.

The stage tells you when you can still act; the outcome class tells you whether acting helps. Read together they produce the finding on this register, and it is in the next section.

The three outcomes: prevented, recoverable, irreversible

Every row carries one of three outcomes. The outcome describes the strongest mechanism available against that failure, not how serious the failure is.

1. Prevented – it cannot be done irreversibly (three rows). The action is refused before it happens, by something the agent cannot switch off. A protected branch that only accepts a reviewed merge. A server-side block on force-push. Make production reachable only through a gate. There is nothing to recover from because nothing happened.
2. Recoverable – it happened, and you can get back (10 rows). The change landed and something exists that returns you to the prior state: a snapshot, a commit, a checkpoint, a down script, a tested restore. The cost is real – you are spending time on an incident rather than on the work – but the state comes back.
3. Irreversible – nothing gets you back (11 rows). Most have no mechanism at all – among them decisions nobody has written down and orchestration gaps where the work exists and nothing carries it across a handoff. Two others have a mechanism that only reduces the failure without closing it – bounding the writable surface, and a deny rule that refuses named command shapes but not every destructive one. And one has a mechanism that exists, requires no configuration, and has been shown on the field record to fail outright: an automatic checkpoint that can itself hold zero tracked files.

So the score is three prevented, 10 recoverable, 11 irreversible. More than a third of the ways a change escapes you have no way back at all.

Now the cross-cut. The irreversible rows are not spread evenly across the life of a change – they cluster at the end. Stage 5, restored, is two-thirds irreversible: two of its three rows have no mechanism. Stage 4, reversible, has none at all. In other words, the failures you can still do something about are the ones early in a change's life, when the change is small and nobody is panicking. The ones with no way back arrive at the moment you are already trying to recover.

A second cross-cut worth knowing: Severity and outcome do not track each other. Of the 12 S4 rows – the ones that cannot be undone at any price – three are prevented outright and five are recoverable. The most expensive failures on this register are mostly the ones with an answer. What is left over is not the expensive half. It is the undecided half.

Vocabulary: this register reads its three classes as prevented, recoverable and irreversible – the only one of the six that does. The other five read B and C as detected and survives. Class C here means unrecoverable, not undetectable. The class letter means the same thing everywhere – how complete the remedy is. [A note on vocabulary] on the hub covers the rest.