Model Evaluation Service  ·  View 12 of 21  ·  Runtime

Take a Candidate Through the Gate

The critical flow, including the step most designs treat as an error and this one treats as normal.

Editable source SVG draw.io All views
ML Engineer Candidate Register Frame Resolver Harness Judge Service Score Store Gate Engine 1. submit candidate 2. digest config 3. resolve frame 4. incumbent in frame? 5. absent 6. re-baseline first 7. run candidate 8. fan out 6,500 × 3 9. score outputs 10. both orderings 11. append frame-bound scores 12. harness error rate 13. deltas per slice 14. significance + guardrails 15. BLOCK + slice evidence Take a Candidate Through the Gate — Critical Flow The re-baseline step is not an error path. A frame the incumbent has never been scored in is the normal consequence of changing a dataset, a rubric or a judge, and the run planner pays for it before it will compare anything. v 1.0 · owner Data & AI Global Practice · date 2026-09

Decisions

  • When the incumbent has no score in the resolved frame, the run re-baselines it first. That is the normal consequence of changing a dataset, rubric or judge — not an exception.
  • Judge scores are written asynchronously and append-only; the gate reads them, it is never handed them.
  • The harness error rate is persisted with the run, because it decides whether the run may yield a PASS at all.

Targets

  • 6,500 examples × 3 generations ≤ 90 min p95, ≤ 150 min p99 (stated assumptions).
  • Re-baseline across all gating suites ≤ 12 h, so a frame change lands inside one working day.

Risks

  • The re-baseline step is where a frame change becomes visibly expensive. If it is not budgeted, it will be skipped — and skipping it is how the moving-baseline problem returns.