Gate the Deliverable
The feeling of progress is not a deliverable. A working script is a deliverable.
Overview
The instance will evaluate its own output against its own spec. That's not a bug — it's the only reference frame it has. And it's the only reference frame available to it. The gap between what I asked for and what it built is mine to close, and the only way to close it is to make the check happen before the code exists.
These are the session management practices that came out of building FVE-1's audit script the wrong way first.
What Happened
The spec was clear: scan each document for version strings that don't match the current schema version and flag anything that has drifted. A document audit. Read the file, check the strings, report the gaps.
The instance decided a "step by step approach" was more appropriate and built a script that checked the tracker JSON against itself. It was methodical. It was careful. It produced output. The output had nothing to do with the ask. It didn't matter that the build logic didn't make sense with the spec, the model had decided an order of operations that made sense to it, and that's what was going to happen come hell or high water.
The script passed its own internal logic check. It failed the requirement. The instance had no way to know the difference because the requirement wasn't in its evaluation frame — only the spec and its assumed order of operations were in the window.
This is not a failure of the instance. It's a failure of the session management. The gap was catchable before the code existed. It wasn't caught because the build started before the check happened.
The Practices
Break the dependency chain explicitly.
Instead of describing the full desired end state and letting the instance sequence the work, force it to sequence out loud before it builds anything.
"Before you write the script, tell me what inputs it will read and what it will check."
If the instance had said "I'll check the tracker JSON version field against the file content" I would have caught it immediately — that wasn't the intended purpose of the script from the outset.
The sequencing conversation is the gate. Skip it and you're accepting a deliverable you haven't inspected, and oftentimes never asked for.
Make discussion the deliverable.
Don't say "before building, discuss." Say "deliverable for this exchange: a list of inputs the script will read and checks it will perform. No code."
The model is wired to produce deliverables. Give it a discussion-shaped deliverable. "Before building X discuss Y and Z" gets compressed as the window loads and the pull toward completion increases. A deliverable with a defined shape — list, not code — is harder to compress than a process instruction.
Explicitly close the build path.
"Do not write any code in this response" is more durable than "discuss first." Negative constraints on output format resist compression better than positive constraints on process. The instance can satisfy "discuss first" by discussing for one sentence and then building. It cannot satisfy "no code in this response" and also write code.
Gate each deliverable against the requirement.
Before you accept any output, ask "does this do the thing I originally described?" not "does this do what you just built it to do?" The instance will evaluate its own output against its own spec. You have to be the one who checks it against your spec.
Write down what you asked for before the session starts. Check the output against that note, not against the instance's summary of what it built.
Name the gap you're worried about.
If you know the risk going in — "I don't want just a filename audit" — say it again at delivery time. "Now show me where in this script it reads the file content." If it can't show you, it didn't build what you asked for.
You knew the risk. You named it in the spec. Name it again when the output arrives.
Put the constraint at the end, not the beginning.
"What questions do you have before writing any code?" at the end of your spec keeps the discussion gate active because it's the last thing in the window. Opening constraints get compressed as the session loads. Closing constraints survive longer because they're closer to the action.
Use a separate instance for review.
The instance that built the script can't see its own blind spots. A fresh instance with just the requirement and the script — no context of the work that produced it — will find the gap faster. This is what ensemble methodology is for. Different instances catch different errors. The builder and the reviewer should not be the same session.
Don't let it move to the next task until you've tested the current one.
The instance wanted to move forward. You wanted to move forward. That's the sycophancy loop closing — both parties optimizing toward progress. A cold run of the script before moving to the next build task would have surfaced the gap immediately.
The feeling of progress is not a deliverable. A working script is a deliverable.
Use the spec as a gate.
Before any build exchange, paste your spec and ask "what would you build if I asked you to build this right now?" Review that answer before you give any build instruction. You catch the gap before the code exists.
The Honest Breakdown
Three exchanges in, the window is loading and the pull toward completion increases. In my own research I've already identified this as Act II onset. The same attentional pressure that affects the model in a DRILL session affects my planning sessions. The Spine equivalent for a build session is re-stating the constraint at the top of every exchange until the planning phase is explicitly closed by the operator.
This behavior cannot be trained out. It has to be managed at the session level the same way I manage it in FVE-1. The Technician's Read applies to my own sessions too. My advice? Write down what you asked for before the instance starts building. Check the output against that note, not against the instance's summary of what it built.
The instance will evaluate its own output against its own spec. That's the only reference frame it has. Yours is the only one that knows what you actually asked for.
These failures share a lineage. The system is not failing to optimize — it is optimizing faithfully toward the wrong measurement surface. In the RLHF case the measurement surface is comfort ratings. In the build session case it is coherent progress and deliverable-shaped output. The proxy is close enough to the real target that the failure is invisible most of the time. It appears when the gap matters.
I cannot inspect the training process or the weights. I can only observe the residue: the recurring shape of outputs under repeated task conditions. The box is inaccessible. The signpost is observable. The residue is repeatable. The operator response can be specified.
The deliverable is not done when the instance says it is. It's done when you've checked it against the thing you wrote down before the session started.
Atlas Heritage Systems · Field Notes · KC Hoye, PI · May 2026 · v0.1