The rescue-spec, or specifying a system before you touch it

When I inherit a broken system, mine or an AI's, and it is tangled enough that I do not fully understand it, I do not start fixing. I start with a rescue-spec: I write down what the thing is supposed to do before I touch how it does it. It feels like a detour when the pressure is to just fix it. It is the opposite. It is the fastest way through.

A rescue-spec is a normal spec, written backward. Instead of specifying something before you build it, you specify something that already exists so you can understand and repair it. What is this system supposed to do? What are its inputs and outputs? What must always be true about it, the invariants? What are the edge cases it clearly has to handle? You write those down from the outside, from behavior, before you go spelunking in the implementation.

Why spec something that already exists?

Because you cannot fix what you cannot specify, and a broken system you do not understand is a system you cannot specify yet. The act of writing the rescue-spec forces the understanding. When you try to state what the thing should do and you cannot, you have found the real problem: you were about to change code whose purpose you could not articulate, which is how a one-bug system becomes a three-bug system. The rescue-spec converts a vague mess into a concrete target you can check your fixes against.

It also gives you the thing you were missing: a definition of correct. Without a spec, "fixed" means "the error I noticed stopped happening," which is the surface-fix trap from the last lesson dressed up as done. With a rescue-spec, "fixed" means "the system now matches what I wrote down it should do," and you can verify that. The spec is the reference the repair aims at, and without it you are just poking the system until the visible symptom quiets down.

This is the same discipline from Track 1 pointed at a different moment. There, the spec came before generation. Here, it comes before the rescue. Same tool, same payoff: you do not touch the implementation until you can say, in writing, what correct looks like. On a system you did not fully build, that written definition is worth more than any amount of clever debugging.

The takeaway: Before repairing a system you don't fully understand, write a rescue-spec of what it should do. You can't fix what you can't specify, and the spec becomes the definition of correct your repair aims at.