# Judge 1: three pipeline proposals (2026-09-30)
Lens: DORA outcomes (lead time, deploy frequency, change failure rate, recovery time) plus cost.

## Ranking
| Rank | Proposal | Why |
|---|---|---|
| 1 | P2 reliability-first | Only one that starts from measured red-main causes (drift pins about 69% of failing test lines, repeat-failing tests about 30%, vCPU launch failures) and gives each cause its own fix: an always-on drift set, a flake quarantine, retry on launch failure only. That hits change failure rate and "far fewer red builds" directly. Deploys main tip first (the #14289 class). Weakest part: the cost numbers. |
| 2 | P1 cost-first | Best on cost levers: tiered review model, one verdict per head, one shared runner spec, token footer, spot-only pools. Its $450/mo target is not credible (see disputes). Moving semgrep and evals to nightly delays catching problems. |
| 3 | P0 throughput-first | Same queue backbone, plus a good canary and auto-rollback design. It inherits the wrong "181 merges/day" figure and a 1,000/day capacity claim, and it has no fix for the #1 cost item (on-demand fallback). |

All three share the same backbone: one CI workflow, a merge queue running the full suite, no push:main rerun, deploy the main tip, prod canary. They differ in emphasis, not in architecture.

## Winner: P2, with grafts
| Graft | From | Reason |
|---|---|---|
| Widen spot families and cap the on-demand fallback | P1 (risk table) + waste audit #1 | 59% of Sep 29 runner spend was on-demand ($157 of $266, FACT). This is the biggest single $ lever, and none of the proposals leads with it. |
| Tiered review model, one verdict per head, no re-review after 🟢/🟡, $/token footer | P1 | Review runs were 1,266 on 09-29 (FACT). Token spend is unmeasured, so log it first. |
| Aggregate required checks ("PR Gate" / "Queue Gate") | P1 | Required-context names are simpler to keep stable across `pull_request` and `merge_group`. |
| Canary alarm needs both a noisy-metric breach and a synthetic probe failure; convert the 10 non-alias lambdas to aliases | P0 | Fewer rollback flaps; gives every lane a recovery path. |
| Measure change failure rate and recovery time as tracked metrics | research #11 | Neither is measured today, so DORA claims can't be checked. |

## Disputed numbers
| Claim | Proposal | Finding | Verdict |
|---|---|---|---|
| "$750/mo CI + $325 review" today | P2 | AWS Cost Explorer: about $219/day, so about $6.6k/mo (ci-waste-audit §5) | Wrong by ~9x. It prices 2-vCPU spot at $0.05/h and ignores 8-core on-demand. |
| Target "$450/mo" runners | P1 | Assumes all spot at $0.05/h. On Sep 29, 8-core on-demand alone was $97 in one day. Runners are arm64 (P1 itself admits the x86 assumption). | Not credible. A defensible estimate is ~$1.5-2.5k/mo (73% fewer minutes × current mix, less the spot shift). |
| "Merges/day ~181 today" (P0 labels it FACT, P2 too) | P0, P2 | 181/day is main commits (5,440/30d). Merged PRs on Sep 29 were 341 (ci-waste-audit). | Mislabeled metric. |
| Capacity "~1,000/day" | P0 | Pure queue math. It ignores bisects and the 320 vCPU cap. | Estimate, optimistic. |
| Capacity "~800/day" | P1, P2 | Queue math halved for failures | Plausible estimate, unmeasured. |
| Red main "16%" vs "20%" | P0/P1 vs P2 | pr-lifecycle: 4 of 25 (n=25). P2: 202 of 1,000 push:main runs. | Both sourced; P2's has the larger n. Prefer 20%. |
| Red-main reduction 70% / 80% / 85% | P1 / P0 / P2 | Only P2 derives it from the cause shares | All are estimates. P2's is best grounded. |
| "Machine-min per PR ~220" | P0, P1 | 55/push is n=15. The audit says machine-min per job could not be sampled. | Estimate on a thin sample. |
| "~72 review machine-min per PR (13k min/day)" | P2 | No 13k min/day source found in the findings | Unsourced. |
| Review "-40% runs" | P0, P1 | No basis given | Estimate only. |