Construction, Not Recovery

There's a default move when something is broken: restore it. Get it back to how it was. Roll back to the last known good state, the baseline, the version before the thing went wrong. It's the correct instinct, for a system that had a good state to return to.

Plenty of systems don't. The baseline everyone assumes is a starting point turns out, on inspection, to be a thing that never actually worked, a process that was always improvised, a structure holding weight it was never designed to hold, a "how it used to be" that was never good, just familiar. Recovering that would mean restoring a version that was broken the whole time and only looked stable because nobody had tested it under real conditions yet.

Restore Assumes a Prior State Worth Returning To

That's the assumption hiding inside the word recovery: that there's a prior state worth getting back to. When there is, recovery is the right frame and you should use it. When there isn't, when the honest audit says the old version was never sound, recovery is a trap. It points all your effort at reconstructing something that shouldn't be reconstructed, because the goal slid into "make it like it was" instead of "make it work."

Construction is the other frame. You don't restore what was never built. You build it, forward, from the materials you actually have, in the configuration you're actually in, toward a state that may never have existed before. It's harder, because there's no template to roll back to and no "known good" to aim at. It's also the only frame that's honest about a system whose past was never worth preserving.

The two frames feel similar from a distance and produce opposite work up close. Recovery looks backward for its target. Construction looks at what's in front of it and asks what can be built from here. One assumes the answer already existed once. The other assumes it doesn't exist yet, and starts.

Building Forward Costs More and Assumes Less

Construction is the more expensive frame, and I'd choose it anyway when the situation calls for it, because it rules out the specific failure recovery invites: pouring effort into restoring a baseline that was never good, and calling it progress because it looks like the past.

Build what needs to exist. Not what used to. When the old version was worth keeping, recover it. When it wasn't, and the discipline is being honest about which, stop trying to get back, and start building forward from where you actually are.