Your organisation can say exactly what a service needs before it takes production traffic: tests, objectives, a runbook, an owner, a rollback path. It has no equivalent for an AI feature. This framework sets out four gates and the artefact that proves each one, readable by someone who did not build it.
A versioned golden dataset built from real production traffic, not invented examples, with adversarial cases and the edge cases behind last quarter's complaints. It lives in the repository and is reviewed like production code. Offline evaluation runs in CI on every change to a prompt, model version, retrieval parameter or tool definition.
One accuracy number treats a misrouted ticket and a fabricated policy statement as interchangeable, and they are not. Name the error classes and attach a cost to each, alongside the input distribution, the output contract including refusal behaviour, the p95 latency budget and the cost ceiling per unit of work.
Chunking strategy, embedding model and version, index parameters and reranking configuration are reviewed configuration rather than values tuned in a notebook. Changing the embedding model is a migration with a backfill plan. Report recall at k and answerability separately, because a system can answer well while retrieving badly.
Task, input distribution, output contract, priced error taxonomy, latency budget, cost ceiling, escalation path. One page, signed by a named engineering owner and a named business owner before any build starts. A system without a written error taxonomy can be demoed, not evaluated.
Golden dataset from real traffic, metrics that match the task, a judge calibrated against a human-labelled subset with its agreement rate reported, and gates that block a merge. The artefact is the suite in the repository, its CI history and the calibration report.
Output validation at the boundary, timeouts, bounded retries, idempotency keys, a deterministic fallback, per-tenant cost breakers and shadow mode for anything acting autonomously. The artefact is a rollout plan with a real holdout and a rollback that pins prompt and model version together.
Full trace capture, sampled human review as a standing weekly process, quality and drift signals, cost per completed task, a runbook naming the AI-specific failure modes, and a deprecation plan. Providers retire models on their schedule, not yours.
For the first system, yes, by roughly a sprint. After that the eval suite makes every subsequent change faster, because you can merge a prompt or model change on evidence instead of holding a review. DORA's throughput gain is real. The stability loss is what the gates prevent.
A normal software review covers none of the failure modes that matter here: a priced error taxonomy, retrieval recall, judge calibration, drift on the input distribution, or a provider retiring your model. Add these four gates to what you have rather than running a parallel process.
No, because a system can produce good answers while retrieving badly, and end-to-end scores hide that until the query distribution shifts. Report recall at k and answerability, the share of queries where the retrieved context actually contains what is needed, against a labelled set.
Only once it is calibrated. Score a human-labelled subset, report the agreement rate next to every result, and re-check it whenever the judge model version changes. An uncalibrated judge is a random number generator with good manners.
Ask for the four artefacts: the capability spec, the eval suite with its CI history and calibration report, the rollout plan with a holdout and rehearsed rollback, and the dashboard with a named owner. All four are readable in an hour and none require code access.
Drop your details and we'll send Four Gates Between A Demo And An AI System You Can Operate straight to your inbox - no spam, unsubscribe anytime.
Our two-week trial sprint produces the capability spec, a working eval suite in your CI and an architecture note against these gates. The artefacts are yours either way.
Book a readiness review