Run acceptance tests and make the ship call

From a fresh clone/directory, run the commands that prove after 20k sessions, v2 groundedness +2.1pp, p95 latency +80ms within budget. A second person plays experiment owner measuring groundedness lift with SRM checks and follows your script without coaching. The demo includes limitations: what support-answer service comparing retriever_v1 vs reranking retriever_v2 still will not do.

Bundle: contract snippet, passing tests, metric snapshot for groundedness_lift_pp and srm_pvalue, security negative probe, rollback note, owner name. Reference AB-SRM-FAIL-27 as the drill you rehearsed. If any item is missing, the ship gate fails even if the happy path dazzles.

For A/B test lab, name the human who gets paged, the review date for thresholds, and the condition that triggers reevaluation. Endpoint POST /v1/support/answer remains the production surface you operate for support-answer service comparing retriever_v1 vs reranking retriever_v2 — not a slide. Keep AB-SRM-FAIL-27 in the handoff template so the next owner inherits the drill.

After the peer demo, schedule the next threshold review date. File a short changelog that mentions AB-SRM-FAIL-27 and the control that addresses it. Archive the evidence pack where your team already stores launch records. Resist rewriting everything “for real production” in one weekend — operate this slice until the metrics bore you, then widen. Final self-check: if telemetry vanished, would you still know to hold? If yes, you learned the operating posture this lane teaches.

Trim the demo script until every command is necessary. Record a peer signature line: name, date UTC, pass/fail. File known limitations as bullets, not apologies. Link the evidence pack from the README. Schedule the next game day on a calendar, even if it is solo. Archive the branch tag or release digest you actually shipped. In this chapter the product is support-answer service comparing retriever_v1 vs reranking retriever_v2, the human stakeholder is experiment owner measuring groundedness lift with SRM checks, and the incident id you design against is AB-SRM-FAIL-27. Re-state the oracle in your notes — after 20k sessions, v2 groundedness +2.1pp, p95 latency +80ms within budget — and keep the invariant visible: assignment sticky by user_id; analysis gated on sample ratio mismatch (SRM) p>0.001 fail. Track groundedness_lift_pp and srm_pvalue as the scoreboard. Surface under change control: POST /v1/support/answer. If you only have forty minutes, finish the fixture for reassignment every request → users flicker; metrics uninterpretable before polishing UI. Promotion language stays ternary: promote, hold, or roll back based on evidence, not hope.