The FIRST real sealed measurement (operator-decrypted 1,319 held-out GSM8K)
found `0 correct / 5 WRONG` — a wrong=0 breach hidden for weeks because the
working metric was the 50-case train sample the bridges were tuned to. Bisection
isolated it to the product_bridge serving promotion (ADR-0195).
- generate/math_candidate_graph.py: REMOVE both serving promotion bridges
(product_bridge + goal_residual/ADR-0207 §5 step 2). Serving = main-graph-only.
Restores sealed 0/0/1319 (verified by bisect: disabling product_bridge -> 0 wrong).
Production modules remain in generate/derivation/; only serving promotion is
unwired, until a gate is proven wrong=0 on the SEALED set (never the train sample).
- Honest numbers everywhere: train_sample 7/43/0 -> 4/46/0 (the bridges' "correct"
was train-overfit). report.json + coverage probe regenerated. 7 ADR test lanes
de-pinned from the inflated count. corpus: cv-0005 (R4) reverts to refuse; cv-0020
(a "baseline control" that solved ONLY via product_bridge) reclassified.
- docs/claims_ledger.md: dated wrong=0-breach-and-remediation note + the rule:
the train_sample number had ZERO predictive validity for the exam; never the score.
- docs/analysis/gsm8k-lift-program-strategy: the program to actually move the 1,319.
NOTE the exit gate stays `correct>=10 AND wrong==0` — refusing-everything is an
explicit FAIL, not a wrong=0 pass; serving still commits (main graph). Verified:
broad regression 848 passed, smoke 73 passed.
763c46d2f4