phase1-exit-check

name

phase1-exit-check

description

Exit rubric for Phase 1 (Method Design). Load after the Architect ↔ Confirmer loop has converged (Confirmer Verdict = ALL CLEAR) and the Main Agent needs to determine whether the confirmed spec is complete enough to hand off to Phase 2 (Small-Scale Verification). Returns PASS or NEEDS-REWORK with specific failing criteria listed. Evaluates structural completeness and dual-anchor alignment only — semantic judgments (clarity, quality) are the Confirmer's responsibility upstream.

Phase 1 Exit Check

Read the latest phase_1_design/method_design_v{n}.md and its matched phase_1_design/confirmer_report_{n}.md. Apply the four criteria below in order. Each criterion is binary: pass or fail. Do not score, weight, or partially credit them.

A single failing criterion means the overall result is NEEDS-REWORK.

This check is structural. It asks: did the Architect ↔ Confirmer loop produce a handoff-ready artifact? It does not re-evaluate the clarity or correctness of individual modules — the Confirmer did that across the loop.

---

Criterion 1 — Confirmer converged (or user override recorded)

Pass if the latest confirmer_report_{n}.md has Verdict: ALL CLEAR.

Pass also if the latest method_design_v{n}.md has a top-of-file acceptance note recording a user override of non-convergence (option (b) from the pipeline's deadlock menu), AND the note cites the specific confirmer_report_{n}.md whose findings were accepted.

Fail if the latest Confirmer verdict is REVISIONS NEEDED and no override note is present. The loop should not have reached the exit check in this state — if it did, the pipeline was misdriven; halt and escalate.

---

Criterion 2 — Required sections present

Pass if the latest method_design_v{n}.md contains all of the following sections, in this order:

1. Header (with IDEA version, EXPERIMENT_SETUP version, round number, date)
2. Revision Note (absent on v1 only — acceptable if v1; required on v2+)
3. Overview
4. Modules
5. Data Flow
6. Claim Trace
7. Experimental Integration (the "Deviations" subsection may be "None", but the subsection header itself must be present)
8. Decision Log
9. Risk Flags (may be "None — no high-risk premises identified" but the section must be present)
10. Open Questions (may be "None" but the section must be present)

Fail if any section is missing or is empty in a way the template did not anticipate. An explicit "None" entry counts as content.

---

Criterion 3 — Claim coverage

Pass if the Claim Trace table in method_design_v{n}.md contains at least one row for every Core Claim in phase_0_ideation/ideas/IDEA.md, AND every row's "Module(s) that test it" field names at least one module from the spec's Modules section (i.e., the claim is operationalized, not just listed).

A row with "Module(s): none yet" is an explicit acknowledgment that the claim is not operationalized — this fails Criterion 3 because the spec is not yet ready for implementation. (It is legitimate as an interim state within the loop, but not at exit.)

Fail if any Core Claim from IDEA.md is missing from the Claim Trace, or if any Claim Trace row fails to name a module that exists in the spec.

To check: read IDEA.md's "Core Claims" section, enumerate each claim, then verify each appears in the Claim Trace with a named module.

---

Criterion 4 — Experiment setup alignment

Pass if every resource (dataset / metric / baseline / LLM / reused code) referenced by any module in method_design_v{n}.md either:

• appears in phase_0_ideation/experiment_setup/EXPERIMENT_SETUP.md, OR
• appears in the spec's "Deviations" subsection with a stated reason.

Pass also if the spec uses no resources at all (unusual, but possible for highly abstract method specs) — in which case Deviations is "None" and this criterion trivially passes.

Fail if any resource used by a module is absent from both the audited setup and the Deviations subsection. These are invisible deviations — the worst kind, because Phase 2 will discover them as implementation blockers.

To check: walk the Experimental Integration table and every module's Dependencies / Operation fields. For each external resource mentioned, confirm its traceability.

---

Output

After evaluating all four criteria, output exactly this block:

## Phase 1 Exit Check

**Result: PASS / NEEDS-REWORK**

| Criterion | Result | Note |
|-----------|--------|------|
| 1. Confirmer converged (or override recorded) | PASS / FAIL | [what was found — verdict or override reference] |
| 2. Required sections present | PASS / FAIL | [what was found — list missing sections if any] |
| 3. Claim coverage complete | PASS / FAIL | [what was found — list unmapped claims if any] |
| 4. Experiment setup alignment | PASS / FAIL | [what was found — list invisible-deviation resources if any] |

**Failing criteria:** [list by number, or "none — all criteria passed"]

**Open findings under override:** [If Criterion 1 passed via override, list the
Confirmer findings the user accepted — these propagate to Phase 2 as known
risks. Otherwise "not applicable — natural convergence."]

**Risk flags carried forward:** [one-line count from the spec's Risk Flags
section, e.g., "2 flags: retrieval-order premise, LLM-token-limit premise".
Or "none flagged."]

Do not suggest how to fix failing criteria. The phase1-method-design pipeline handles routing — continue, accept, retreat, or abandon — based on user decision.