The drift check, or scoring the build against the spec

Verification needs something to verify against, and this is where the spec from Track 1 stops being paperwork and starts earning its keep. The drift check is a single deliberate question asked after the build: how far did the implementation drift from what I specified? And crucially, I make it a number, not a feeling, because a feeling will always tell you it's close enough.

I score it zero to four. Zero and one mean it matches the spec, acceptable, ship it. Two or more means it drifted enough to fix before it goes anywhere. The exact scale matters less than the act of forcing a discrete judgment. "Does this match the spec, and by how much" is a question with an answer, and asking it out loud catches the slow, quiet divergence that's invisible when you only ever look at the code and never back at the contract. The build always looks reasonable on its own. It's only against the spec that you can see it answered a slightly different question than the one you wrote down.

Why score it instead of just eyeballing it?

Because eyeballing grades on a curve that moves with your investment. The more effort you've sunk into a build, the more "close enough" the drift looks, because sunk cost quietly relaxes your standard exactly when it should hold. A number resists that. Scoring the drift zero to four forces you to actually compare the implementation to the properties, the interface, the edge cases you specified, one at a time, and name where they diverge. You can talk yourself into "it's basically what I asked for." It's much harder to talk yourself into a two when the spec is sitting right there saying otherwise.

The prerequisite this exposes

The drift check only works if you have a spec to check against, which is the whole reason the spec track comes first. Verification without a reference is just re-reading the code and nodding, because you have nothing to measure it against except your own memory of what you wanted, and your memory has been quietly editing itself to match whatever got built. The spec is the fixed reference that memory can't drift. Check the build against it, score the gap, and fix anything past the line.

The takeaway: score the build against the spec zero to four instead of eyeballing it, because a number resists the sunk-cost drift that "close enough" hides, and the spec is the fixed reference your memory can't quietly rewrite.