DECISION TOOLKIT · DELIVERY GATES
Make every transition earn the next one
The nine phases are not a checklist. They are a sequence of proof obligations: each transition reduces a different uncertainty and protects the next investment.
No evidence, no transition. Reopening a prior gate is a sign of learning, not failure.
Most AI project post-mortems blame the wrong culprit. The final report indicts the model: not accurate enough, not reliable enough, "not ready for our business." In our engagements we almost always observe something else. The model worked. What was missing was an entire phase of the project: nobody had measured the workflow before changing it, nobody had defined what would justify stopping, nobody had built an evaluation environment before exposing the system to real users.
When an AI project fails, look for the skipped phase before you look for the faulty model. You will almost always find the phase first.
The problem is not a general lack of method — organizations know how to deliver projects. It is that AI moves risk to unfamiliar places: quality is probabilistic, proof requires a baseline, permissions become an architecture question and value does not survive without governance. Hence this framework, distilled from our engagements: the complete anatomy of an enterprise AI project, in nine phases.
The framework at a glance
An end-to-end AI project moves through nine phases. Three are about deciding: intent, diagnosis, portfolio. Three are about building: architecture, foundations, pilot. Three are about value: evidence, industrialization, continuous value. Each phase produces identifiable deliverables, exposes a recurring trap and ends with a verifiable exit criterion. As long as that criterion is not met, moving on does not remove the work: it moves it further downstream, where it costs more.
The sequence does not forbid iteration — a pilot can send you back to architecture, evidence can reopen the portfolio. But the decisions are ordered: you do not choose a technical pattern before choosing a problem, and you do not scale a system before counting its errors.
The framework applies to a document assistant as much as to an agent that touches production: only the relative weight of the phases changes. A low-risk case can cross all nine phases in a few weeks with light deliverables; a case that influences customer decisions spends more time in architecture, foundations and piloting. Skipping a phase is never a time saving: it is a transfer of debt into production.
Phase 1 — The intent decision
Every project starts with an intention; few start with a decision. Phase 1 turns "we need AI" into an explicit choice: which problem, carried by which sponsor, with which abandonment criterion. That last point is the most important deliverable — and the most rarely produced. Deciding before you invest what would justify stopping costs an hour of clarity; deciding it afterwards costs a political negotiation.
Deliverables. A one-page intent note: the problem stated as a workflow outcome to change, a named sponsor with time genuinely reserved, the budget for the proof phase and the abandonment criterion in writing.
The classic trap. The mirror project: launched because a competitor announced something, with no problem of your own. The sponsor is a name on a slide, not a person who will arbitrate when a hard call is needed.
Exit criterion. You can move to the next phase when the sponsor can state, without notes, the outcome to change and the stopping conditions — and both appear in a document they have signed.
Phase 2 — Diagnosis and baseline
You cannot improve a workflow you have not measured; you can only change it. Phase 2 documents the real workflow, not the official process: who does what, where time is lost, where rework concentrates, which data flows and under which legal constraints. This is also the moment to freeze the baseline that will make any later proof possible.
Deliverables. A map of the workflow as it is actually practiced; quantified baselines — cycle time, rework rate, exception rate, unit cost, quality variation; an inventory of the data and systems involved, with their owners.
The classic trap. Measuring after the fact. Without a baseline, the team will have to prove the pilot's value against memories — and memories always lose to a skeptical CFO. A frequent variant: documenting the theoretical process from the quality manual, which nobody follows.
Exit criterion. You can move on when you know what the workflow costs today, with numbers, and the person who runs it recognizes those numbers as their own.
Phase 3 — Portfolio and first case
Even when the mandate covers a single use case, it must be chosen against alternatives. Phase 3 builds a portfolio of candidates and scores them on two axes: potential — economic materiality, user impact, strategic relevance — and executability — data access, integration complexity, control requirements, evaluation feasibility. The first case is not the one that promises the most: it is the one that combines meaningful value with the shortest path to trustworthy evidence.
Deliverables. A portfolio scored on potential × executability; a first case chosen and documented; the list of deferred cases with the reason for their deferral — it will keep the same debate from replaying every quarter.
The classic trap. Choosing the most spectacular case: often customer-facing, often high-risk, almost always the slowest to prove. A visible first failure costs more credibility than three quiet successes earn.
Exit criterion. You can move on when the sponsor, the workflow owner and the technical team defend the same first case — for the same reasons.
Phase 4 — Architecture and boundaries
Before building, draw the boundaries: which data enters, which permissions apply, which technical pattern carries the case, and what remains reversible. On pattern choice, our rule matches the engineering guidance Anthropic has published on building agents: start with the simplest pattern that suffices — a tool-equipped call, a prompt chain, a router — and move toward agency only when the case demonstrably requires it. On integration, open standards such as the Model Context Protocol reduce vendor coupling and prepare reversibility.
Deliverables. A data-flow diagram with owners; a permission model in which the system inherits the user's rights — never more; a pattern choice justified in writing; a reversibility analysis: what a change of model or vendor would cost.
The classic trap. Over-architecture: building an autonomous agent where a prompt chain would have sufficed, then spending months debugging autonomy nobody needed. The inverse trap exists too: ignoring permissions and discovering during the pilot that the assistant surfaces documents the user should never have seen.
Exit criterion. You can move on when every piece of data entering and leaving the system has a documented path, an owner and a verifiable permission boundary.
Phase 5 — Foundations
Phase 5 builds what a demo never shows: cleanly provisioned identities and access, reliable data connectors, operational controls and, above all, the evaluation environment. That environment is what separates a steerable project from a blind one: a set of real, representative, deliberately awkward cases, replayable after every change. The NIST AI Risk Management Framework says the same thing in its own vocabulary: you can only govern what you can map and measure.
Deliverables. Service accounts with minimal scope; operational, logged data access; an evaluation set built from real cases, including the edge cases; the basic controls — logging, alert thresholds, an incident procedure.
The classic trap. Skipping the evaluation environment to "get to the pilot faster." The team then tunes prompts by feel, unable to tell an improvement from a regression, and the pilot becomes a sequence of contradictory impressions.
Exit criterion. You can move on when you can replay your evaluation set and obtain a reproducible score — before a single real user has touched the system.
Phase 6 — The supervised pilot
The pilot does not test the technology: it tests the modified workflow, its controls and its humans. Phase 6 exposes the system to a restricted, named scope, with systematic human validation at the start, then sampled as confidence is built on facts. Every error is typed: severity, cause, detectability. It is this accounting of errors — not the enthusiasm of early users — that will feed the phase 7 decision. Supervision is not distrust of the system: it is the instrument that will allow you, evidence in hand, to lift it progressively.
Deliverables. A written scope: named users, covered cases, explicitly excluded cases; a human validation loop with sampling rules; a register of typed errors; quality thresholds set before launch, not after.
The classic trap. The demo pilot: three enthusiastic users, no error register, and a scaling decision based on anecdotes. The errors you do not count during the pilot get counted later as incidents.
Exit criterion. You can move on when you have an error rate measured by case type, compared with the human baseline from phase 2 — not a general feeling.
Phase 7 — Evidence and the scaling decision
Phase 7 is a decision room, not a celebration. Three outcomes are legitimate: scale — the thresholds are met, you extend; adapt — the value exists but elsewhere or otherwise, you reconfigure; stop — the evidence is missing, you stop and bank the learning. A stop decided on evidence is a governance success; scaling by inertia is a deferred failure. Orders of magnitude remain ranges — processing time reduced by 30 to 50 percent on standard cases, for example — and it is your phase 2 baseline that turns a range into a fact.
Deliverables. An evidence file: delta against baseline, full costs — build, run, supervision —, incidents and their resolution, actual adoption; a written decision — scale, adapt or stop — signed by the sponsor.
The classic trap. Scaling by inertia: "the pilot went well," so you extend, without comparing results to thresholds — often because no thresholds were set in phase 6. Stop was never a real option, only a line on a slide.
Exit criterion. You can move on when the decision is made on numbers, signed, and stop was genuinely on the table.
Phase 8 — Industrialization
Going to production is not the end of the project: it is the beginning of operations. Phase 8 turns a pilot that works into a service that holds: observability — traces, cost per request, quality drift —, a clear operating model — who responds when it breaks, under which commitments —, cost management, and training teams on the new workflow, not just the tool. This is also where the system's economic durability is decided: a cost per request accepted in a pilot can become indefensible at scale if nobody watches it.
Deliverables. Production observability dashboards; an operations runbook with a named owner; budgets and cost alerts; a training plan anchored in the workflow; the production security review.
The classic trap. The ghost handover: the project team moves to the next topic, nobody is on call, costs drift silently and quality degrades unobserved. The system dies in production — slowly, and without a death certificate.
Exit criterion. You can move on when the system has a named operational owner, a tracked budget and quality measured continuously — not only on incident days.
Phase 9 — Continuous value
The last phase has no end: it is the steady state. Baselines become living again — re-measured at regular intervals, because the workflow, the volumes and the models change. A short monthly governance review examines value, costs, risks and trade-offs. And demonstrated gains fund the next cases in the portfolio: it is reinvestment, not enthusiasm, that turns a first project into a program.
Deliverables. Re-measured, dated baselines; a monthly review with a fixed agenda — value, costs, incidents, risks, decisions; a reinvestment logic linking proven gains to the portfolio's next cases.
The classic trap. Declaring victory at go-live and no longer measuring. Six months later, nobody knows whether the system still creates value — or whether it ever did. The next budget is then negotiated on faith, opposite a CFO who has none.
Exit criterion. This phase is not exited; it is held. You are at the right operating rhythm when every monthly review produces at least one decision: extend, adjust, stop or reinvest.
The nine exit criteria in one table
| Phase | You can move on when… |
|---|---|
| 1. Intent decision | The sponsor states, without notes, the outcome to change and the abandonment criterion. |
| 2. Diagnosis & baseline | The workflow's current cost is quantified and validated by its owner. |
| 3. Portfolio & first case | Sponsor, business and engineering defend the same case, for the same reasons. |
| 4. Architecture & boundaries | Every piece of data has a documented path, an owner, a verifiable permission. |
| 5. Foundations | The evaluation set produces a reproducible score before any real user. |
| 6. Supervised pilot | The error rate is measured by case type and compared to the human baseline. |
| 7. Evidence & scaling | The scale, adapt or stop decision is made on numbers and signed. |
| 8. Industrialization | Named operational owner, tracked budget, quality measured continuously. |
| 9. Continuous value | Every monthly review produces at least one decision. |
From framework to execution plan
Nine phases fit in an article; their execution fits in a plan. To show concretely what each phase produces, we have anonymized a complete implementation plan of roughly fifty pages from a real engagement: it walks through the nine phases deliverable by deliverable, from the phase 1 intent note to the phase 9 monthly reviews, with the document templates and thresholds used.
Two rules summarize how to use the framework. Skip no phase: each one exists because its absence has a documented cost. And do not turn it into bureaucracy: on a simple case, a phase can fit in one meeting and two pages. What matters is not how long a phase takes; it is that its exit criterion is met.
Where to start on Monday
- Name the sponsor and have them write the abandonment criterion — before any conversation about tools.
- Pick one workflow and measure it for one to two weeks: cycle time, rework, exceptions, unit cost.
- Score three to five candidate cases on potential × executability, and keep only one.
- Draw the data flows and the permission model of the chosen case on a single page.
- Build an evaluation set from real cases — including the awkward ones — before writing a single prompt.
- Set the pilot's quality thresholds in writing, along with the date of the scale, adapt or stop decision.
- Book the monthly review in calendars now: governance that is not scheduled does not exist.
The difference between an AI project that proves and an AI project that promises is rarely decided by the choice of model. It is decided by the discipline of the nine phases — and it shows from the first week.