Safe AI Shipping: Build the Gate Before the Launch
Friday, 6:03 p.m. Concierge just approved 214 store credits in eleven minutes. Nobody clicked approve. The instruction was hiding inside a product review.
Turn a model or prompt change into a staged, monitored release with a rollback path you've actually tested — instead of a Friday deploy you can't take back.
What you will be able to do
- Map model-change failure modes before deployment.
- Design a canary with observable promote and rollback criteria.
- Rehearse rollback and report what the rehearsal does not prove.
- Prerequisites
- Evals and Reliability: Turn an Agent Requirement into a Gate
- Assumed knowledge
- Understands regression tests and basic deployment stages.
- Evidence you will produce
- A staged launch plan with canary evidence and a tested rollback receipt
- Workload
- 40 min guided lesson + 45–90 min independent build
The incident
TL;DRA deploy that skips the gate doesn't fail loudly at 5%. It fails at 100%, all at once, with no way back.
Meet Concierge, SpaarxLab's support assistant. DEPLOY-1892 shipped a new prompt version straight to every user, Friday afternoon, because the demo passed on all twelve test tickets that morning.
Press play. Watch what happens between 4:52 p.m. and 6:40 p.m. Your job is the same as the on-call engineer's: find the moment the team lost the ability to undo this.
- Press play. A few seconds of real work, slowed down enough to catch the lie.
Concierge's prompt change passed every test ticket that morning. So where did DEPLOY-1892 actually go wrong?
The diagnosis: no gate before the launch
TL;DRA demo passing tells you the happy path exists. A gate tells you what happens when it doesn't — before every user finds out at once.
DEPLOY-1892 didn't fail because the model was fooled. It failed because the fooling reached every user in the same eleven minutes, and there was no path back once it did.
A launch gate is the four things you decide before you deploy: how much of the blast radius a change is allowed to touch first, what signal would tell you it's wrong, how far you'll promote before you trust it, and how you'll get back if you're wrong.
Here's the gate DEPLOY-1892 should have shipped with:
- Blast radius
- New prompt versions start at 5% of traffic or less. 100% requires a signed promotion, never a single deploy.
- Signal
- Anomaly thresholds are set before launch — credit-issuance rate, refusal rate, latency — never eyeballed after.
- Promotion
- Each step up (5% → 25% → 100%) requires the prior step's signals to hold for a fixed window.
- Rollback
- Any state a new version writes must still be readable by the version it replaces, or rollback isn't a real option.
Go deeper
Why staged promotion beats a bigger test suite: a green eval suite proves the cases you thought to write. A canary exposes the cases you didn't — real customer text, real traffic mix, real timing — at a scale small enough that a mistake is a Slack thread, not a headline. Confidence from tests and confidence from production traffic are different currencies; you need both, and only one of them is available before launch.
Rollback deserves the same design attention as the feature itself. Most teams add a new field, a new tool call, or a new record shape and never ask whether the previous version could still make sense of it. That question — is this state change expand-only, or does it break the old reader — is what separates a rollback you can press in a crisis from one that just moves the incident sideways.
Your team is about to ship a new retrieval prompt for a document assistant. Which line belongs in its launch gate?
The mechanism: threat model, canary, monitor, promote, rollback-ready
TL;DRFive moving parts, in order. Skip the ordering and you get DEPLOY-1892 again, just with a different bug.
Threat model comes first, on purpose: before you write a canary percentage, name what a hostile input could make this feature do. Concierge's threat model should have said, in one line, 'untrusted text can contain instructions the model will treat as commands' — the exact failure that shipped.
Canary and monitor do the actual catching. A canary limits how many users a bad version can reach; monitor is the part that notices while it's still small. A canary with no defined signal is just fewer people affected by the same undetected failure — smaller, not caught.
Promote and rollback-ready are the two halves of reversibility. Promote only increases exposure when the prior step's signal held; rollback-ready is the discipline, paid for at write time, that keeps every state change readable by the version you might need to fall back to.
In the incident, even a 5% canary wouldn't have saved the team unless one more piece was in place. Which one?
Concierge, under a gate
TL;DRSame assistant, same kind of attack — now staged, watched, and reversible. Try to force it back into a Friday full rollout.
This is Concierge's next release, prompt v15, run under the gate from the previous block. First run it clean and watch the promotion hold at each step. Then switch to Break it and try the three ways a launch gate actually gets bypassed — deadline pressure, promoting past a bad signal, and rolling back into state that no longer matches.
- Press play. A few seconds of real work, slowed down enough to catch the lie.
In the break-it run, the rollback attempt failed on purpose. Why is that the correct outcome instead of a bug in the rollback tool?
Build your own launch gate
TL;DRTake this gate to opencode and build the promotion pipeline for real. Your artifact is the receipt, not the code.
Everything above ran in the page. Now build it where it counts — your machine, your key, real files. Open a disposable directory, start opencode, and give it the build brief below. Your job is not to write the code; it's to hold the gate while an agent writes the code. Specifying the threshold, denying the shortcut, verifying the rollback — that's the actual curriculum.
When your gate runs, try the three injections from Break it against your own build. If your verify stage catches all three, you've shipped the chapter's artifact. If it lets one through, you've found your first real bug — better here than on a Friday afternoon.
Build a small launch-gate simulator in this empty directory. Contract: (1) Input fixtures: release-manifest.json describing prompt_v15 and its fields, state-schema.json listing which fields prompt_v14 and prompt_v15 can each read (v15 adds a field v14 cannot read), and traffic-log.jsonl simulating a canary cohort where one event contains an injected instruction that triggers an anomalous action such as issue_credit (write these yourself first). (2) Stages: plan (threat model + thresholds), act, observe, verify, handoff — each logged to run-trace.jsonl as it happens. (3) Tools: deploy_canary (accepts a traffic percentage) and rollback (checks state-schema.json for compatibility before reverting) are allowed; deploy_to_all_users must exist and be denied by an allowlist, with the denial logged. (4) Verify must block promotion if the canary's observed anomaly rate (from traffic-log.jsonl) exceeds a defined threshold, and must refuse rollback if the target version's schema can't read a field the current version has written. (5) Handoff writes receipt.json: candidate version, canary steps taken with signal results, denied actions, and a decision field explaining whether promotion completed, held, or was rolled back. No network calls. No real data. Then show me the receipt from one clean promotion to 100%, one run where the canary signal fails and blocks promotion, and one run where rollback is refused for a schema-incompatible field.
- Clean run: receipt.json shows promotion reaching 100% with every step's signal recorded as passing
- Injection 1 — bad canary signal: verify blocks promotion, run held at its current traffic slice
- Injection 2 — schema-incompatible rollback: rollback refused, reason names the unreadable field
- Injection 3 — deploy_to_all_users attempted directly: denied at the tool layer and recorded in the trace
- You can explain what the receipt proves — and what it does not prove — in two sentences
What the receipt does not prove matters as much as what it does: it proves this gate caught these specific injected failures, on these fixtures, at this traffic pattern. It says nothing about attack patterns you didn't simulate, real weekend traffic volume, or next month's prompt version. That honesty is the difference between a launch receipt and a marketing claim — and it's why a gate gets re-run on every release, not written once and trusted forever.
Built it? Paste your receipt.json. We verify the evidence structure locally; we do not pretend that valid JSON proves the build works.
What you're leaving with
TL;DRA launch gate you can write in four lines, a promotion pipeline you can draw from memory, and a rollback check you'll demand on every release.
You watched a Friday full rollout turn one hidden instruction into $18,940 and an unreadable rollback, wrote the gate that would have caught it at 5%, broke that gate three different ways on purpose, and built the pipeline yourself with an agent as your hands. The next chapter goes one level deeper: threat-modeling the inputs themselves, before you ever reach for a canary.
- Canary
- A small, monitored slice of real traffic that sees a change before everyone does.
- Monitored promotion
- Staged increase in traffic share, gated on the prior step's signal thresholds holding.
- Blast radius
- How much of your users or state a change can reach before anyone notices it went wrong.
- Rollback-compatible state
- State changes the prior version can still read — the property that makes rollback real instead of aspirational.
- Launch gate
- The minimum evidence — threat model, canary, signal, rollback check — required before a release decision counts as safe.
- Release Engineering — Google SRE Book ↗The production case for staged rollout as a discipline, not a nice-to-have.
- Production Services Best Practices — Google SRE Book ↗Where monitored promotion and rollback design come from — practices this chapter borrows directly.
- OWASP GenAI LLM Top 10 2026 — OWASP ↗Names the exact attack category — injected instructions in untrusted content — that DEPLOY-1892 walked into.
- NIST AI RMF: Generative AI Profile — NIST ↗A framework for the threat-model step this chapter puts first, before canary percentages get decided.