Status flow — PROPOSED → ACTIVE_ALGORITHM_LEVEL → ACTIVE_RUNTIME

Every gate has a status. The status reflects the strength of the evidence that the gate is correctly asserting what it claims.

The three statuses

PROPOSED

• The gate is defined in the contract YAML.
• No test asserts it yet (or tests exist but don't pass deterministically).
• A grep + structural search confirms the gate has a body in the YAML, but the assertion is not yet mechanical.
• CI may print "WARNING: gate-X is PROPOSED" but does not block on it.

ACTIVE_ALGORITHM_LEVEL

• A deterministic, repeatable test asserts the gate.
• The test passes on every CI run.
• But no measured discharge has been recorded — i.e., no operator has dispatched a real bench against real systems and stamped the result into evidence/.
• The gate is algorithm-validated but not empirically validated.

ACTIVE_RUNTIME

• A measured discharge exists in evidence/ with a date, an n, and an aggregate score.
• The gate is now both algorithm-validated AND empirically validated.
• This is the highest status; gates that reach ACTIVE_RUNTIME are the project's hardest evidence.

Transition rules

                +-------------+
                |  PROPOSED   |
                +------+------+
                       |
                       |  (1) write a falsifier test
                       |  (2) test passes deterministically on CI
                       |  (3) flip status in contract YAML
                       ▼
            +-------------------------+
            | ACTIVE_ALGORITHM_LEVEL  |
            +------------+------------+
                         |
                         |  (1) operator dispatches a real bench
                         |  (2) evidence/<phase>/<artifact>.json captured
                         |  (3) calibration record on file (CCPA-019)
                         |  (4) flip status in contract YAML
                         ▼
                  +----------------+
                  | ACTIVE_RUNTIME |
                  +----------------+

Every transition is a YAML-level edit reviewed in PR, gated by pv validate, and asserted by FALSIFY-CCPA-012 (pv_contract_gate_on_commit).

Status distribution at v1.32.0

DISCHARGED is the terminal state — the gate's claim was empirically met, and the gate-as-assertion is preserved for historical record but no longer fires.

The V1_ gate prefix (Phase 6)

V1_001..V1_004 are distinct from CCPA-NNN. They live in aprender's contracts (qwen3_moe-serve-dispatch-v1.yaml et al.) and gate the infrastructure that V1_004 (Phase 6 student pass rate) depends on:

• V1_001 — qwen3_moe serve dispatch (ACTIVE_RUNTIME)
• V1_002 — sampling (temperature/top_k/top_p) (ACTIVE_RUNTIME)
• V1_003 — streaming SSE (DISCHARGED on gx10 Blackwell)
• V1_004 — Phase 6 non-zero student pass rate (open as of this writing)

Once V1_004 discharges, CCPA-017 (project_scale_parity_bound) becomes eligible to flip from PROPOSED to ACTIVE_ALGORITHM_LEVEL.