builder-validator

Builder-Validator

Lock the spec first, build second, audit third. The builder never grades its own homework mid-flight — validation is a separate pass against criteria frozen before generation began.

Step 1 — Freeze the spec (silent)

Extract every stated requirement into binary (yes/no) criteria. Rules:

• Each criterion must be checkable by reading the output alone (no "feels good").
• Mark each as GATE (failure = artifact rejected) or SCORE (failure = noted, tradeable).
• If a requirement is vague ("make it engaging"), convert to a proxy ("opens with a specific number or question") — record the conversion but don't narrate it to the user.
• Never invent facts to pass a gate. If a gate-critical criterion depends on a fact not given by the user — a date, a name, a number, a policy detail, a metric — stop and ask the user for it before drafting. Do not fabricate a plausible-sounding value to make the criterion checkable.
• Freeze the checklist silently. It cannot change during this cycle. Show only the audit result (Step 3), not the checklist itself. If the user adds requirements later, that starts a new cycle with a new frozen spec.

Step 2 — Build

Generate the artifact. Do not reference the checklist while generating beyond following the requirements — no criterion-by-criterion writing, which produces stilted output.

Step 3 — Validate (separate pass)

Re-read the frozen checklist, then audit the artifact criterion by criterion. Output this scorecard:

SPEC AUDIT — cycle N
GATES:  [PASS/FAIL] <criterion> — <one-line evidence>
SCORES: [PASS/FAIL] <criterion> — <one-line evidence>
RESULT: X/Y passed. Gates: ALL PASS | FAILED (list)

Step 4 — Iterate or ship

• Any GATE failed → revise the artifact targeting only the failed criteria, re-audit. Max 3 cycles, then stop and report what's stuck and why.
• All gates pass → present the artifact + final scorecard.
• Never silently revise: every cycle's scorecard is shown.

Limitations

• Criteria quality bounds audit quality: vague specs produce weak proxies; the checklist itself stays silent, but every proxy conversion is still recorded and available if the user asks to see the frozen spec.
• Self-audit by the same model has blind spots; for high-stakes artifacts, recommend a second-model or human review of the frozen checklist itself.
• Max 3 cycles is a cost guardrail, not a quality guarantee.
• Silence on the checklist is a presentation choice, not a secrecy rule: the user can always ask to see the frozen criteria before or after the audit.