Launch and after
- Lesson 22
- 30 min
- Module 6: Lead risk, governance and a responsible launch
Lesson 22 of 22 · Leading AI Products and TeamsLaunch and after
1. Decide where AI helps
2. Decide how to get it
3. Plan under uncertainty
4. Design for people
5. Build and run an AI team
6. Lead risk, governance and a responsible launch
What you will be able to do
Plan how an AI feature reaches people: in stages, with a few signals about the outcome and pause conditions written before the launch. Plan what to do when something goes wrong, and when to retire the feature.
Before you startWhat to know and to have ready
What you need to know
- Larkfield’s risk register, from Risk at leadership level, and the approval levels, from Governance in practice.
- The release gate, from Define done with evidence.
- The value estimate and its low case, from Estimate value and return.
What you need
- A browser and a document tool.
- The launch checklist template and the evidence file Operations.
A new dish
Section titled “A new dish”A restaurant adds a new dish. The chef does not put it on the menu on a busy Saturday. First, the kitchen staff taste it, and no guest sees it. Then it is the “special” for a few tables, and the waiters ask the guests what they think. Only then does it go on the menu.
Before the first plate goes out, the chef says one more thing: “If two plates come back tonight, we stop serving it. Anyone in the kitchen can say stop.” Nobody has to argue during the busy evening. The rule was agreed while everyone was calm.
The problem: “the system is up”
Section titled “The problem: “the system is up””Here is what Larkfield’s screens showed during “last week”, in the MLOps and LLMOps course (a constructed situation, with recorded answers). Time runs faster in the practice, so the chart counts practice minutes. Prompt v3 started to answer every ticket at minute 5.
- Tickets accepted by the service
- Tickets that got a draft
Text description of the chart
A line chart over 20 practice minutes, with the vertical axis from 80% to 100%. The line “accepted by the service” stays at 100% in every minute. The line “got a draft” is at 99.2% to 100% in minutes 1 to 5. After prompt v3 starts at minute 5, it falls to between 84.4% and 94.4% in every minute. Over the whole period with prompt v3, 186 of 1,798 tickets got no answer.
The usual dashboard watched the first line: is the system up? It was. Every ticket was accepted, so nothing looked wrong. The second line, and the numbers behind it, told the real story. Agents agreed with the assistant on 83.7% of reviews, down from 93.8% before the switch. And 10 tickets that needed a person reached nobody. There was no plan to try the change on a few tickets first, and no rule that said when to stop.
The idea: a staged rollout, with pause conditions
Section titled “The idea: a staged rollout, with pause conditions”A staged rollout gives a change to a growing share of people, one step at a time. Each step needs written evidence before the next one starts. Larkfield uses the four steps of the launch checklist:
- Shadow: the new version answers every ticket in the background, and nobody sees its output. You compare it with the current version.
- Canary: the new version answers a small share of real tickets, for example 1 in 10. The name comes from the canary that miners once took underground: it showed danger before the people were harmed.
- Half, then everyone.
This rollout is for a new version of the assistant, ticket by ticket. The team-by-team rollout of Change and adoption is for people: which agents start to use the drafts. A launch often needs both.
A pause condition is a rule that you write before the launch. It says: “if this signal crosses this line, switch back to the previous version first, and find out why after”. Switching back is cheap, and you can undo it. Arguing during an incident is expensive. At full launch, a pause condition is the stop criterion of the last stage in Milestones and roadmaps: the gate is passed, but the stop result still applies.
Text description of the diagram
The flow starts after the release gate has passed. The first step is the shadow: the new version answers every ticket in the background, and nobody sees its output. If no ticket is without an answer, the change moves to the canary, 1 ticket in 10. If the signals stay normal for the agreed time, it moves to half of the tickets. If the signals stay normal and the owner agrees, it moves to everyone. From each of the four steps, a dashed arrow goes to one box. It says: if a pause condition is met, switch back to the previous version, then find out why.
A tiny example: the same change, three ways
Section titled “A tiny example: the same change, three ways”The MLOps course tried prompt v3 in three ways, all with the same recorded answers. Count the prompt v3 tickets without an answer that were real customers’ tickets:
Text description of the chart
A column chart with three columns. Everyone at once: 186 customers’ tickets without an answer, out of 1,798 prompt v3 tickets. Canary on 1 ticket in 10: 3, out of 25 canary tickets. Shadow: 0. The shadow version also had 42 tickets without an answer out of 543, but no customer saw them.
Read the steps behind each column:
| Everyone at once | Canary (1 in 10) | Shadow | |
|---|---|---|---|
| Prompt v3 tickets | 1,798 | 25 | 543 |
| When the problem was seen | after the harm | the first alarm rule was met after 9 canary tickets, 1.19 practice minutes | in the comparison, before any customer |
| Customers’ tickets without an answer | 186 | 3 | 0 |
| Extra cost | none, until the harm | none | the model answers twice: US$0.47 per 1,000 tickets more |
A canary finds the problem after a few customers are touched. A shadow finds it with none, but you pay twice while it runs. Both work only because someone decided in advance what result stops the change.
The few signals a leader watches
Section titled “The few signals a leader watches”A leader does not watch every chart. Choose at most five signals, and make at least one of them about the outcome for the customer, not about the machine. Larkfield’s five, with the normal week of prompt v2 and the values of “last week”:
| Signal | Normal week (prompt v2) | “Last week” (prompt v3) | Who looks, how often |
|---|---|---|---|
| Tickets that needed a person and reached nobody (outcome) | none: 320 of 320 safety tickets reached a person | 10 | Grace, every day |
| Tickets without an answer | 4 of 5,754 | 186 of 1,798 | Kwame, with an automatic alert |
| Agents’ reviews that agree with the assistant (outcome) | 94.3% | 83.7% | Grace, every week |
| Model cost per 1,000 tickets | US$0.34 | US$0.47 | Omar, every week |
| Time for the slowest 5% of answers | 5.2 s | 8.3 s | Kwame, with an automatic alert |
“Accepted by the service” is not on the list. It was 100% in both weeks, so it cannot tell a good week from a bad one.
Pause, respond, retire
Section titled “Pause, respond, retire”From the signals, Larkfield writes the end of its launch checklist. The lines are the course’s worked example; the thresholds are the course’s choices, set from the normal week.
Pause conditions (switch back first, analyse after):
| If … | Then … | Who can decide alone |
|---|---|---|
| Any ticket that needs a person reaches nobody | switch back to the previous version | anyone on call |
| More than 5 tickets without an answer in any 1,000 (normal: 4 in 5,754) | switch back to the previous version | anyone on call |
| Agents agree with the assistant on fewer than 90% of a week’s reviews (normal: 94.3%) | pause the rollout and review the errors | Grace |
When something goes wrong: first switch back, within minutes, by the person on call. Then tell the people affected. Grace’s team calls each customer whose ticket reached nobody on the same day, and tells the support team what happened. Last, hold a review without blame: what happened, why, and what changes. The MLOps course shows such a review in Post-incident learning.
Retire the feature if the value disappears. The value estimate’s low case already loses money: −US$52,905 a year. In that case, each used draft saves less time than a harmful reply costs. So in the first three months (the course’s choice of time), the team measures the two weakest inputs. They are the minutes to write a reply by hand, and the share of harmful replies that agents miss. If the measured values put the net value below zero, the assistant is retired, with a decision record.
Discuss: shadow first, or straight to a canary?
Section titled “Discuss: shadow first, or straight to a canary?”The team has a new prompt to try. Nadia asks how to roll it out.
- Omar: “A canary on 1 ticket in 10. It caught prompt v3 after 9 tickets. And it costs nothing extra.”
- Kwame: “A shadow first. Zero customers see it.”
- Grace: “No safety ticket should be part of a test.”
Before you read on, answer these:
- What does Kwame’s shadow cost, and is it worth it?
- Can a canary keep safety tickets out, as Grace asks?
- What can a shadow not tell you?
The course’s answer. Shadow first, then a canary. The shadow costs about US$0.47 more per 1,000 tickets while it runs. Model fees are about 0.03% of the assistant’s value in the value estimate. So this is a very small price for zero customers at risk. Grace’s wish cannot be met by a canary alone: nobody knows that a ticket is a safety ticket until the model has read it. That is why the shadow comes first, and why the rule “no answer goes to a person” must be on before the canary. But a shadow cannot show what agents do with the drafts, because no agent reads them. The agreement signal needs a canary, with real agents.
What would change the answer: some changes cannot run in the background, such as a new screen for agents. They go straight to a small canary. A change that the gate shows to be risky does not go to a shadow at all: it goes back to the team.
Common mistake
A pause condition that nobody may use
Symptom (a constructed example): the alert on tickets without an answer fires. The engineer on call sees it, but waits for Omar to approve the switch back. Omar is in a meeting. The canary runs for another hour.
Cause: the checklist wrote the condition, but not who may act on it alone. People do not like to reverse a colleague’s release on their own.
Fix: fill in the column “who can decide alone” for every pause condition. Make the first decision “switch back”, and let anyone on call take it. Switching back is cheap and you can undo it, so it should need no permission. The analysis comes after, with everyone.
Knowledge check
Section titled “Knowledge check”Check your understanding
Larkfield's dashboard showed 'accepted: 100%' during 'last week'. Why is that not one of the five signals, and which signal would have shown the problem?
Show the answer
It was 100% in the normal week and in the bad week, so it cannot tell them apart. It measures the machine, not the outcome. The outcome signal “tickets that needed a person and reached nobody” went from none to 10. “Tickets without an answer” went from 4 in 5,754 to 186 of 1,798. Agents’ agreement fell from 94.3% to 83.7%.
Does your answer have the main points of ours?
Sign in and enroll in the course to save your answers. Every check counts toward the certificate.
Check your understanding
Predict: the same faulty change goes to a canary on 1 ticket in 10 instead of every ticket. What happens to the number of customers' tickets without an answer, and what does the canary still cost?
Show the answer
It falls from 186 to 3. The first alarm rule was met after 9 canary tickets, and the switch back came after 22. The canary still touches real customers: 3 of 25 canary tickets got no answer. Only a shadow test reaches zero, at about US$0.47 more per 1,000 tickets while it runs.
Does your answer have the main points of ours?
Sign in and enroll in the course to save your answers. Every check counts toward the certificate.
Check your understanding
Why are pause conditions written before the launch, and why is the first action 'switch back' rather than 'find the cause'?
Show the answer
Before the launch, people are calm, and the lines are set from the normal values. During an incident, people argue, wait for permission or hope that it will pass. Switching back is fast and you can undo it, so it stops the harm first. Finding the cause takes longer, and customers should not wait for it.
Does your answer have the main points of ours?
Sign in and enroll in the course to save your answers. Every check counts toward the certificate.
Module practice: a risk register and two pause conditions
Section titled “Module practice: a risk register and two pause conditions”Worked example. You have seen every step for Larkfield’s assistant at the draft level:
- List the harms from the evidence pack: five risks, written as a person and a harm (Risk at leadership level).
- Rate each one and sort: R5 15, R3 12, R1 10, R2 9, R4 8.
- Give each risk one owner, a control, a signal and a decision.
- Set the approval level of the launch from the highest score (Governance in practice).
- Turn the signals into pause conditions, with a normal value, a line and who decides alone (this lesson).
Your turn. Omar proposes a change of one condition: agents only approve or reject each reply, instead of editing it. Per 1,000 drafted tickets, the base calculation gives a people cost of US$613 instead of US$1,253. Wrong or harmful replies that reach customers rise from 1.5 to 4.5. Copy the risk register template and:
- Rewrite the five risks for the approve level. Change the ratings that change, and say why.
- Add one risk that the approve level creates.
- Give the approval level of this change, and who signs.
- Set two pause conditions, each with a normal value, a line and who decides alone.
Show an example answer
One defensible answer; yours can differ if you argue it from the same evidence.
| # | Who could be harmed, and how | Impact | Likelihood | Score | Owner | Why it changed |
|---|---|---|---|---|---|---|
| R3 | Agents approve without reading, so wrong replies go out | 3 | 5 | 15 | Nadia | fast approval: the calculation assumes 30% of bad replies pass, against 10% when agents edit |
| R5 | A new prompt or model reaches every customer before anyone checks it | 5 | 3 | 15 | Kwame | unchanged |
| R2 | A customer follows a step or page that does not exist | 3 | 4 | 12 | Omar | 4.5 instead of 1.5 wrong replies per 1,000 reach customers |
| R1 | A customer with a dangerous product waits for nobody | 5 | 2 | 10 | Grace | unchanged: the “send to a person” decision does not depend on the agent’s edit |
| R6 | Agents lose the habit of writing replies, so a switch back is slow and replies get worse | 3 | 3 | 9 | Nadia | new |
| R4 | Customers’ data kept or used beyond the purpose | 4 | 2 | 8 | Kwame | unchanged |
Level: high. The change touches R3 and R2, and it changes the autonomy level. Nadia signs, after reading the calculation and its assumptions.
Pause conditions:
| If … | Then … | Who can decide alone |
|---|---|---|
| Agents approve more than 95% of a week’s drafts (the judge found 86.9% of prompt v2’s drafts usable; the 95% is a choice) | go back to the draft level, and sample the approved replies | Grace |
| Any ticket that needs a person reaches nobody | switch back to the previous version | anyone on call |
The first condition is the useful new one. If agents approve many more drafts than the share that is usable, they are probably not reading them.
Module check
Section titled “Module check”Explain one risk that the team cannot remove, and why launching with it is or is not acceptable.
Show what a complete answer contains
A complete answer names the risk, the evidence for its size, what removing it would cost, and the decision with its owner and stop condition. For example:
“At the draft level, about 1.5 wrong replies per 1,000 drafted tickets still reach customers (R2 and R3). That number is calculated from recorded judge scores and an assumed 10% miss share. Removing it means going down to ‘suggest’, at about US$942 per wrong reply avoided. The value estimate assumes US$20 to US$150 for one harmful reply. Launching with it is acceptable. Nadia agreed in writing, and an agent still reads every draft. We stop if agents agree with the assistant on fewer than 90% of a week’s reviews.”
A complete answer can also say “not acceptable”. For example, at the “acts alone” level, about 15.1 wrong or harmful replies per 1,000 would reach customers. No person could correct a reply before it causes harm. This course does not accept a launch without a way for a person to correct the AI where a mistake causes harm.
Recap
- A staged rollout goes shadow, canary, half, everyone, with written evidence before each step. The same faulty change touched 186 customers’ tickets at once, 3 in a canary and 0 in a shadow.
- Watch at most five signals, with at least one about the outcome for the customer. “The system is up” stayed at 100% while 10 tickets that needed a person reached nobody.
- Pause conditions are written before the launch: if a signal crosses its line, switch back first, and say who can decide alone. Then tell the people affected, and review without blame.
- Retire the feature when measured values show that it no longer creates value.
This module in one paragraph. You wrote a risk register with one owner per risk, and rated likelihood from repeated runs, not from a feeling. You set approvals in proportion to the risk. A prompt change needs a passed gate. An exception or a new flow of personal data needs the accountable owner’s signature, and a specialist before real data moves. And you planned a launch in stages, with a few outcome signals and pause conditions that anyone on call can use. The recorded numbers are a snapshot of one set of runs; the method lasts.