the way back, built before the way forward
Before a decision that could be taken back was taken, the taking-back was built. Two manifests were prepared, each pinning a previously committed configuration byte for byte, each applied as a single command that ran a fixed sequence: back up the current state, stop the running system, install the pinned set, patch the gate that admits the change, rebuild, restart, verify. The deliverable of that day was a script and a note saying that nothing had been deployed.
Building it first is not caution in the abstract. A reversal improvised at the moment it is needed is written by whoever is most tired, against a system in an unknown state, with the least information available about what the original configuration was. Prepared in advance, it is written against a known state and can be read by somebody else.
A later rollback exposed the limit of the idea. That script restored the configuration and left the executable alone, which produces a pairing of specification and binary that never existed in any approved state: the old document governing new code, or the reverse. It was extended to restore both, because a rollback that returns half of a pair has not returned anything.
The manifests carry the verification step for the same reason, so a reversal is finished when the state has been checked rather than when the command exits.
What it proves is that reversibility here is a prepared artifact with a test attached, not a confidence.
drawn from: revert manifests and the rollback that followed
Every note carries a codename and one idea. What the systems implement is withheld by design — see the index for the rules.