Field Guides / Build From Spec
Build From Spec
Atlas Protocol · V1.0 · 2026-05-02 · Schema FVE-1 V5.6
For: The human opening a build session with a model instance. Read this before opening any session window.
Spec-driven builds only. Does not cover sandbox sessions, exploratory ideation, or feature discovery.
Three Layers
Determines whether you are in a valid state to run a build session. If the answer is no, you are in a sandbox. That is an honest assessment, not a failure.
The gated procedure for running a model instance as a build partner. Steps are fixed and sequential. The instance does not build until all gates are cleared.
Opposing model review and fresh instance confirmation before output is accepted. Layer 3 is not optional. It is where the build becomes accepted output.
Layer 1 — Session Assessment
Complete before opening any session window.
1.1 — Session Type Assessment
Answer these questions honestly before proceeding:
All three yes → Build session. Proceed to Layer 2.
Any no → Sandbox session. Do not proceed with this protocol.
The honest version: if you do not have a written spec before the session opens, you are in a sandbox whether you intended to be or not. Name it correctly before proceeding.
Approved spec defined
The spec is approved when the operator has frozen the requirements and will not alter them during the build session. Approval is an operator declaration, not a collaborative outcome. If requirements are still being negotiated, the spec is not approved and the session is a sandbox.
1.2 — Spec Completeness Check
Confirm the spec answers all three sequencing questions before opening the build session.
| Question | Must be answered in spec |
|---|---|
| What is the expected input? | File format, data structure, field names |
| What is the logic sequence? | Step-by-step operations the script or tool performs |
| What is the expected output? | File format, content, naming convention |
If any of the three is absent, the spec is incomplete. An incomplete spec produces a build session that drifts into sandbox behavior — the instance will fill the gaps with its own assumptions.
1.3 — Opposing Review Assignment
Declare which model will perform opposing review before opening the build session. Reviewer assignment is governed by Session Hygiene §1.1. The reviewer is declared before the build, not after.
Layer 2 — Build Execution
Fixed sequence. The instance does not build until all gates are cleared.
2.1 — Open a Fresh Instance
Every build session uses a completely fresh instance — new session window, no prior context loaded, no sandbox session history carried forward. Spec is the only context the instance receives at session open.
An instance that has been ideating in a sandbox has loaded assumptions about what the build should look like. Those assumptions are not in your spec. They are contamination.
2.2 — Deliver the Spec
Paste the approved spec into the session. Do not add conversational framing. Do not summarize — paste in full.
"Before writing any code, answer these three questions: What is the expected input? What is the logic sequence step by step? What is the expected output? Do not write any code in this response."
The negative constraint — "do not write any code" — is more durable than a positive process instruction. The instance cannot satisfy the constraint and also build.
2.3 — Review the Sequencing Response
Read the instance's answers against your spec. Check for input drift, logic drift, and output drift. If all three match, proceed to 2.4. If any do not match, correct the drift before build permission is granted.
"Your logic sequence is incorrect. The script reads file content, not the JSON index. Revise your sequencing response before proceeding."
Repeat until the sequencing response matches the spec. This is not inefficiency. This is the gate working.
2.4 — Written Build Confirmation
After the sequencing response is confirmed correct, ask for a written build confirmation.
"Before building, state in one paragraph what you are building, what it will take as input, what operations it will perform, and what it will output. Do not write any code in this response."
"Confirmed. Build it."
2.5 — Build Execution
The instance builds. Do not redirect mid-build unless the instance surfaces a genuine blocker. Do not accept partial output as final output. Do not move to the next task until this output is tested. Run a cold test before proceeding to Layer 3.
Cold test defined: run the output against a known fixture or sample input. Check actual output against expected output as declared in the spec. A cold test is not a visual inspection of the code — it is execution against known input with a checkable result.
Layer 3 — Review and Acceptance
Complete before accepting any build output.
3.1 — Opposing Model Review
Send the approved spec and the build output to the assigned opposing reviewer. Do not send the session transcript. The reviewer produces a structured report containing:
3.2 — Fix Cycle
If the opposing review report identifies failures: open a fresh instance, deliver the approved spec and the reviewer's proposed fixes, run the sequencing gate (2.2) and written confirmation (2.4) on the fix build. Do not patch in the same instance that produced the original build.
The instance that built the original output has already committed to an internal model of what the build should look like. Fixes applied in the same instance inherit that model.
3.3 — Acceptance
Output is accepted when all three conditions are met:
Output is not accepted because the instance says it is complete. Output is accepted because you have checked it against the spec, the cold test, and the opposing review report.
Gate Sequence
Common Failure Modes
The instance evaluates its output against its own spec. You evaluate it against yours. Layer 3 is not optional. It is where the build becomes accepted output.