Lesson 15. From Pilot to Production and Back

A payroll-services company piloted an assistant that answered employees' questions about their payslips, grounded in each client's pay rules. The pilot "went well": the sponsor liked the demos, the twelve pilot users said nice things, nobody could point to a failure. So it was declared production, rolled out to every client's HR portal, and the pilot team moved on. Adoption stalled within two months. Most employees still emailed HR, because the assistant lived on a separate page nobody visited and HR staff, who had not been trained, told people not to trust it. Six months later the model vendor changed its pricing; the prompts were written in that vendor's dialect, the evals ran only on that vendor's platform, and the contract had no notice period for price changes. The company paid, because the alternative was a rebuild. Nobody had written down what "went well" meant, so nothing had ever been checked. Decide now: which of the two failures (adoption, exit) was cheaper to prevent, and at which stage?

Illustrative composite. Adoption in the story stalled at roughly 11% of the target users and the vendor's price roughly doubled. The figures are a teaching device, not a measurement from a real company.

The exit, at the PoC stage, for the price of provider-neutral prompts and a golden set that runs anywhere; adoption is dearer and starts at the pilot gate. This lesson's deliverable is 12-rollout-plan.md in your Dossier. A staged rollout plan for your case: entry and exit criteria per stage, the HITL policy per stage, the adoption plan, and the exit options. It closes the Run stage of Frame / Decide / Prove / Run, and its final section starts the next Frame.

What is actually going on

A stage is a bet with a fixed budget, and a gate is the written criteria that decide the bet before the stage starts. "Went well" is not a criterion, because it is decided afterwards by whoever is in the room. The payroll company had stages without gates, so the pilot could only end by momentum, and momentum always points at production.

The evidence on why pilots die points at the same gap. The most quoted study of enterprise generative-AI pilots reported that around 95% showed no measurable profit-and-loss impact within months; its critics note the metric measures documented impact in a short window and that most pilots had no baseline to measure against, which attacks the precision of the number, not its direction (Forbes on the MIT report and a critique of the claim, observed 2026-09-09). Gartner predicted on 25 Jun 2025 that more than 40% of agentic AI projects will be cancelled by the end of 2027, citing cost, unclear value and weak risk controls (Gartner press release, observed 2026-09-09). Every one of those causes is a gate that was not written: no baseline, no value criterion, no risk criterion.

Four stages, each with an entry gate, an exit gate and a kill criterion. A PoC proves feasibility on real examples and is thrown away. A pilot puts the system in front of real users with real data against a measured baseline, for a fixed window. Production means the SLOs, the runbook, the security review and the adoption plan are live. Scale means a window of attained SLOs, an exercised error budget, showback and a completed model-swap drill. Every exit that is not "next stage" goes back to Frame, which is the "and back" in this lesson's title: a killed pilot that produced a written reason and a revisit date is a success of the method. The state machine below is the plan's skeleton; look at where the arrows go when a criterion is not met.

Two arrows matter most: production can fall back to pilot when the incident record says so, and scale ends in Frame rather than in a bigger production, because the review of one use case is the discovery for the next.

The rule and its condition

PoC, pilot and production are gates with written entry and exit criteria set before the stage starts; the human-in-the-loop policy loosens one notch at a time, only when the eval record and the incident record for the current notch say so, and tightens on any incident; an adoption plan and an exit option are parts of the architecture, not appendices. Use a pilot when a baseline exists and can be measured during the pilot window; otherwise measure the baseline first, because a pilot without a baseline cannot exit on evidence and will exit on momentum.

The gate criteria this course uses as defaults are below; every number is a starting point to adjust to your case's budgets from lesson 2, and the kill criteria are written next to them, before the stage, by the person who will have to enforce them.

Human oversight that loosens on evidence

Oversight is a dial, not a switch, and it is set per action class. Read-only outputs (a draft, an answer, a summary) can move through four notches: a human reviews every output; a human reviews a sample; only flagged outputs are reviewed (low confidence, high-risk category, new pattern); autonomous with audit. Reversible actions (a booking with a cancel, a ticket update) can reach exception-only review once the compensation from the runbook exists and has been exercised. Irreversible actions (a payment, a legal notice sent to a customer, a deletion) never fall below exception-only, and the exception rule is written by the risk owner, not the product owner.

The dial moves one notch at a time, on a fixed evidence window per notch: the golden set passed at target on every scheduled run in the window, the quality SLO was met, zero severity-one or severity-two incidents were recorded, and the implicit signals (edit distance, rejection rate) stayed flat. It moves back a notch on any incident of those severities, on a quality SLO breach, or on a classification change from the compliance annex, and it does so automatically, before the meeting. The picture shows the dial; every forward arrow is labelled with the evidence, every backward arrow with the trigger.

Notice that a fall from notch 3 lands on notch 1, not notch 2: an incident at the autonomous level is evidence that the exception rule missed something, so the sample review comes back until the rule is rewritten.

Adoption and exit are architecture

Adoption fails on friction, and the friction is rarely the model. The assistant that lives on a separate page loses to the email habit; the assistant that appears inside the tool people already use, with the sources shown and an escalation path one click away, wins by default. The adoption plan therefore names the surface (where the output appears in the existing workflow), the training (short, role-specific, by the people who will use it), the champions (one per team, with time allocated), the incentive (the metric the team is measured on, which must be the business metric, not "letters generated"), and the measurement (usage against the target population and the implicit signals from the runbook). The MIT coverage cited above frames the failure as companies avoiding friction; the plan is where you go looking for it.

Exit is the part nobody wants to fund until the invoice changes. Four pieces make a system portable. A provider abstraction at the gateway (L08), so the application never speaks a vendor's dialect. Prompt portability: provider-neutral prompts with thin per-provider adapters, and a golden-set score for every candidate model, because the golden set is the portability test: if the alternative passes it, you can move. An open-weight fallback, scored on the same set and costed with the self-host break-even from L11, even if it fails the bar today, because the gap is a number you can watch. Data export: the golden set, the traces, the feedback labels and the grounding documents in formats that leave with you, with embeddings treated as re-computable. The contract carries the rest: the client owns prompts, evals and data; the vendor may not train on the client's data; model changes and price changes need notice; costs pass through at list with monthly showback. US federal procurement wrote this shape into policy in 2025, requiring contract terms that bar vendors from training on non-public government data without consent and address portability and interoperability (OMB memoranda M-25-21 and M-25-22, observed 2026-09-09); private clients can borrow the language.

The model-swap drill is where exit stops being a clause: at the scale gate, route a slice of traffic through the alternative, score it on the golden set and the implicit signals, and record the result and the cost. A drill that fails is still a success, because it prices the exit.

The review and the summary

Before the production gate, the Dossier goes through a Well-Architected-style review: a question set, grouped by pillar, each answered with a file in the Dossier or a named gap. The cloud vendors publish their own lenses for generative-AI workloads (AWS Generative AI Lens, Azure Well-Architected AI assessment and Google's AI and ML perspective, all observed 2026-09-09); they are useful as a second opinion and vendor-shaped in what they emphasise. The course's own checklist, grouped by Frame, Decide, Prove and Run, is the capstone's centrepiece.

The executive summary is one page for the buyer, written last and read first. It states the decision requested, the problem and its measured baseline, what the system does and does not do, the evidence (eval result, cost per task and twelve-month total, threat-model residuals, compliance classification), the rollout with its gates and dates, the risks with owners, the exit option and its price, and the signature line. The template is in the example files below; the capstone gives a worked one.

Worked case

Harbor Mutual's claims-correspondence assistant passed the pilot go/no-go in the evidence pack. The product owner now proposes to skip a formal pilot: the PoC "went well with the adjusters who tried it", so run a three-month soft launch on the whole motor team and call it production. Constraints: the charter (L01) names the pilot exit evidence as a measured reduction in handling time per letter with equal audit quality; the compliance annex requires a human sender in phase one; the runbook's HITL evidence window needs scheduled golden-set runs and an incident record; the CFO's number from L11 assumed a time saving that has not been measured. Decide now: soft launch, or pilot, and what is the soft launch actually missing?

A pilot, and the soft launch is missing a baseline, a gate and an end. Step one: the baseline. Four weeks of instrumented current practice on the motor team, measuring handling time per letter and the audit rework rate, run while the PoC hardens. Without it the CFO's model can never be confirmed and the production budget stays unfundable. Step two: the pilot, twelve adjusters, eight weeks, with entry criteria (golden set at target, DPIA signed, runbook live in reduced form) and exit criteria written by the claims operations lead, who also owns the kill criterion. Step three: oversight at notch 0 for every letter type during the pilot, because the evidence window has not started; the booking tool at notch 2 from day one, because it is reversible and its cancel compensation was exercised in the runbook's paper incident. Step four: the adoption plan, whose main line is that the draft appears inside the claims system's letter screen rather than in a separate tool, with a ninety-minute session per team and one champion per team. Step five: the exit, already cheap because the gateway and neutral prompts exist; the open-weight candidate is scored on the golden set and recorded as below the bar with the gap, and the contract gets notice and ownership clauses. The soft launch would have cost what the payroll company paid: a production system nobody could evaluate, an oversight policy that could never loosen because it had no evidence window, and a price change with no answer.

Illustrative composite. The pilot's exit criteria: at least a 20% reduction in handling time per letter against the four-week baseline, with audit quality equal or better; at least 10 of the 12 adjusters using the assistant three or more times a week by week six; zero letters sent with a wrong clause; SLOs attained through the window. Kill criteria: under 10% saving at the midpoint, or any wrong-clause letter sent to a customer that the review step did not catch. The open-weight candidate scored 0.93 on the clause criterion against a bar of 0.99, so the exit is recorded as "available at reduced quality, gap 0.06, re-score quarterly".

The rollout plan Harbor Mutual signed is below, in the shape your Dossier uses.

# 12-rollout-plan.md: Harbor Mutual claims-correspondence assistant
Gate owner: Head of Claims Operations · Risk owner: Model Risk lead · Revisit: each gate

## Stages
| Stage | Entry criteria | Exit criteria | Kill criteria | Window |
|---|---|---|---|---|
| Baseline | Charter signed; metric definitions agreed | Handling time and rework rate measured on motor team | none | 4 weeks |
| Pilot | Golden set at target; DPIA signed; runbook live; 12 adjusters trained | Delta >= target; adoption >= target; zero wrong-clause letters sent; SLOs attained | Delta below half target at midpoint; uncaught wrong-clause letter | 8 weeks |
| Production | Security review passed; runbook and on-call live; cost model at scale; system card v1 | 90 days SLO attainment; error budget exercised; showback live; swap drill done | Repeated Sev-1; cost per draft over ceiling for a month | 90 days |
| Scale | Production exit met; review written | Next use case chartered from the review | n/a | ongoing |

## Oversight policy (notch per stage per action class)
| Action class | Pilot | Production | Scale | Loosen when | Tighten when |
|---|---|---|---|---|---|
| Acknowledgement letters (read-only draft) | 0 | 1 after 4-week window | 2 after further window | golden set at target all window; zero Sev-1/2; edits flat | any Sev-1/2; SLO breach; reclassification |
| Settlement letters (read-only draft, high impact) | 0 | 0 | 1 after bias suite passes and 90 days | as above plus bias suite | as above |
| book_visit (reversible, cancel compensation) | 2 | 2 | 3 after compensation exercised in production | compensation exercised; zero double bookings | any double booking |
| Any irreversible action | not in scope | not in scope | not below 2, risk owner writes exception rule | n/a | n/a |

## Adoption plan
- Surface: draft appears in the claims system letter screen; sources shown; "write it myself" one click away
- Training: 90 minutes per team, run by the team's champion; refresher at production
- Champions: one per team, half a day a week during pilot
- Incentive: teams measured on handling time and audit quality, not on drafts generated
- Measurement: weekly active adjusters vs target population; edit distance; rejection rate; escalations

## Exit options
- Gateway abstraction with a second provider adapter tested on the golden set
- Prompts provider-neutral; adapters versioned with the prompts
- Open-weight candidate scored quarterly; self-host break-even from 08-cost-model
- Monthly export: golden set, traces (redacted), feedback labels, grounding documents
- Contract: client owns prompts, evals, data; no training; 30-day notice on model or price change; list-price pass-through with showback
- Swap drill at the production-to-scale gate; result and cost recorded here

Faded case

Skip to the open case if this is familiar. Lumen's support agent serves forty tenants and its margins are thin, so the founder wants to move the agent to autonomous for every tenant and stop paying for human review. The agent answers questions (read-only), updates tickets (reversible, with a reopen compensation) and issues refunds up to a tenant-set limit (irreversible once the payment processor settles). Lumen has golden-set runs nightly, a quality SLO per tenant, and an incident record that shows one severity-two incident last month: a refund promised on a ticket the tool could not act on, caught by a tenant's agent.

The stages are clear enough: each tenant is its own pilot with its own baseline (their pre-Lumen handling time), and the production gate is per tenant. The decision left to you: which action classes can go to notch 3, for which tenants, on what evidence, and which cannot go there at all?

Open case

A digital agency built a catalogue assistant for a mid-sized retailer: it answers product questions from the catalogue and reviews, recommends alternatives, and can add items to the customer's basket. The pilot ran on one category for six weeks with the agency operating everything: evals, on-call, prompt changes. The retailer now wants to go to production across all categories, and the agency's contract ends at handover. The retailer has one platform engineer and no evaluation practice. You are asked to write the rollout plan's production gate and the handover section. The quiz's first item grades your answer.

Where this breaks

Gates can be gamed by the people who set them. A sponsor who writes a kill criterion nobody will enforce has written a wish. The gate owner is the person who loses if the criterion is ignored, and the criteria are recorded before the stage with a date, so a later edit is visible.

Baselines are politics. Measuring current handling time tells a team it is being measured, and the number moves before the pilot starts. Announce the measurement as the pilot's foundation, keep the window short, and record how it was collected; a contested baseline is still better than none.

Evidence windows assume stable traffic. A quiet month passes every window and tells you nothing about the busy one. Tie the window to volume as well as time, and hold the notch through the first peak season before loosening again.

The exit is never free. An alternative scored below the bar is an exit at reduced quality; a self-hosted fallback is an exit at a platform team's cost. The rollout plan records the price of the exit so the buyer decides with it, rather than discovering it with the invoice.

Key Takeaways

• Write entry, exit and kill criteria before each stage, owned by the person who will enforce them.
• Measure the baseline before the pilot, or the pilot cannot exit on evidence.
• Loosen oversight one notch per evidence window, per action class; tighten automatically on any incident.
• Put the output where the work already happens, train by champions, and measure adoption against the target population.
• Make the exit real with neutral prompts, a scored alternative, exportable data and contract clauses; price it with a swap drill.

What You Have Now

A staged rollout plan for your case: entry and exit criteria per stage, the HITL policy per stage, the adoption plan, and the exit options. It lives at dossier/12-rollout-plan.md and is the last numbered file before the executive summary. Its gate criteria are the charter's pilot exit evidence from 00-charter.md turned into measurements; its oversight policy reads the eval record from 07-eval-plan.md and the incident record from 11-runbook.md; its exit section cites the gateway from 06-integration-spec.md and the self-host break-even from 08-cost-model.md. It serves the Run stage, and its final section, the review, is the input to the next engagement's Frame.

Example Files

The executive summary template the capstone fills in:

# <System name>: executive summary for <buyer>            Date · Version · Author

**Decision requested.** Approve <stage> for <system>, budget <amount> over <window>, gate owner <name>.

**Problem and baseline.** <Who> spend <measured baseline> on <task>; measured <how, when>. Target: <delta> by <date>.

**What it does.** <Two sentences.> It does not: <non-goals from the charter>.

**Evidence.** Eval: <pass rate> on <n> cases, judge agreement <value>, gate at <threshold>.
Cost: <per task> today, <twelve-month total> under <scenario>, break-even vs self-host at <volume>.
Threat model: <residual risks accepted, by whom>. Compliance: <classification>, <dates that apply>.

**Rollout.** <Stage> from <date> to <date>; exit criteria <list>; kill criteria <list>; oversight at notch <n> per action class.

**Risks and owners.** <Three rows: risk, mitigation, owner.>

**Exit.** <Alternative> scored <value> against the bar of <value>; data exports monthly; contract notice <days>.

**Signature.** <Sponsor> · <Gate owner> · <Risk owner> · <Architect>

Further Reading

• Gartner on agentic AI project cancellations: the causes are cost, unclear value and weak risk controls, each of which is an unwritten gate.
• Forbes on the MIT pilot study: the friction framing of adoption, and a critique of the headline number.
• AWS Prescriptive Guidance on architecting a generative-AI PoC: hypothesis, success criteria and the decision, in a vendor's words.
• OMB memoranda on federal AI procurement: contract language on training, portability and interoperability to borrow.
• AWS Generative AI Lens and Azure Well-Architected AI assessment: vendor question sets to run beside the course's checklist.

Exercises

1. Write the gates. For your case, fill the stages table: entry, exit and kill criteria per stage, each criterion with a measurement and the name of the gate owner. Then check each exit criterion against your lesson 1 charter's pilot exit evidence; where they differ, decide which document is wrong.
2. Set the dial. List your system's action classes as read-only, reversible or irreversible. For each, write the notch per stage and the evidence window that moves it, and name the compensation that a reversible class depends on. Find the class you were tempted to loosen on enthusiasm.
3. Price the exit. Choose one alternative model (hosted or open-weight), run or estimate your golden set on it, and write the exit section: score against the bar, cost per task, what exports monthly, and the contract clauses you would ask for. If you cannot score it, write down what it would cost to find out.

Check your understanding