Days 91–180 — Prove, Prepare, Decide: อะไรสมควรได้ขยายDays 91–180 — Prove, Prepare, Decide: What Earns the Right to Scale

🤔 The dashboard says plenty of people are using it — so what are the workarounds your staff quietly build telling you instead?

The previous post — #18 The First 90 Days — ended at the point where the organisation has everything it needs on paper: an executive accountable for value and for risk, one to three target decisions chosen and baselined, a redesigned workflow, a full set of assessments, and one minimum viable system that has already passed its offline tests. The one thing still missing is the only thing that really matters — evidence that it works for real people doing real work.

The second half of the 180 days is how you go and get that evidence, and Chapter 12's one-line answer is prove one complete learning loop before launching a large portfolio, and let evidence decide what earns the right to scale.^[1] Before going further, let me pin down the boundary the playbook declares for itself in the chapter's very first paragraph: no law and no standard prescribes this 180-day sequence. It is the author's own synthesis, joining AI-as-a-Core to lifecycle risk management, continual improvement, workflow redesign, evaluation gates and workforce participation — while legal obligations apply throughout the project, independently of this calendar.^[1] Read it as a cadence that has been shown to work, not as a schedule anyone imposed on you.

1. Logins Are Not Adoption, and Usage Is Not Value

Chapter 12 gives five operating principles, and the third is the one I most often watch organisations walk straight into during months four to six — the stretch where the system has just been opened to people and everyone would like a flattering number to report.

💡 My view: this chapter's principle 3 is written very tersely — "Instrument outcomes before scaling usage — login is not adoption and usage is not value", which the playbook's Thai companion renders as "measure Outcome before increasing Usage; login is not Adoption and usage is not Value"^[1] — and the sentence is more expensive than it looks, because it implies that if you cannot yet measure outcomes, adding users teaches you nothing new. It only makes you wrong at a larger scale.

I want to separate these four rungs cleanly, because the first three get used interchangeably in meeting rooms until nobody knows what is being discussed.

Login is evidence that an account exists and somebody opened it. It is the easiest thing to measure, which is why it is reported most often, and all it can tell you is that the door is open. An organisation announcing its user count in month one, after emailing everyone to log in at least once, is reporting the effectiveness of that email, not of the system.

Usage is evidence that people came back and pressed the buttons again. One rung better, but still silent on whether the work actually moved. High usage can arise from two opposite causes — the system is so useful that people return to it, or the system answers so badly that people have to ask three times. Both plot the same curve, and the two curves look identical.

Adoption is evidence that the intended group genuinely changed how it works, rather than opening one more screen beside the old ones. This is the first rung that becomes significantly harder to measure, because it requires knowing how the work used to be done and where the new way differs — which is precisely the information the system's dashboard has no way of holding.

Value is evidence that the organisation's outcomes improved against a baseline declared in advance, and improved without pushing the burden somewhere else. This is the only rung a board genuinely cares about, and the only one that cannot be measured at all if no baseline was prepared back in the first 90 days.

The other four of the five operating principles

The remaining principles govern the second half of the 180 days from different angles, and I quote them all because the five work as a set rather than one at a time.^[1]

Principle 1: one learning loop before a large portfolio — depth before breadth. This is the entire reason these 180 days talk about one to three decisions rather than twenty. One learning loop closed properly teaches an organisation more than ten pilots that never close a single loop.

Principle 2: business and risk ownership cannot be delegated to the AI team — accountability follows the decision. This is the principle most politely violated, because nobody ever announces that ownership has moved. It happens quietly, at the moment the question "why did this case come out this way?" is passed to the technical team instead of the process owner. Accountability here means that the person who answers to the customer and to the regulator has to be the same person who holds the authority to stop.

Principle 4: build reusable capability from proven need — avoid platform speculation. This is the heart of the whole days 121–150 window, and I expand it in section 3

Principle 5: stop weak initiatives visibly and without stigma — portfolio discipline frees capacity for value. This is the heart of days 151–180, and the principle that needs culture more than tooling. I come back to it in section 4

Notice that not one of the five mentions models, accuracy or architecture. All five are about sequence, ownership and decision discipline — things executives control directly and usually do not.

2. Days 91–120 PROVE — Release Narrowly, Compare Against Baseline, Rehearse the Kill Path

The playbook writes the prove window as a single, very dense paragraph. Let me quote it whole first and unpack it clause by clause afterwards.^[1]

"Days 91 to 120 release narrowly and learn from reality. Use canary or limited-group release with support. Compare with baseline or control. Monitor outcome, quality, critical errors, overrides, complaints, subgroup effects, cost, reviewer load, and environmental use. Rehearse the kill path. Interview users and operators because workarounds expose defects dashboards miss. Stop cases that lack value or cannot be controlled."

Six instructions in one paragraph, ordered by the sequence you actually have to run them in, not by importance.

What releasing narrowly means, and how narrow is narrow enough

Canary means letting a small share of the workload run through the new system while the majority still runs the old way. A "limited group" means choosing users who know they are part of a trial and who can be contacted back. Both work, but the words readers skip most often are with support — releasing narrowly without anyone available to take those users' calls is not an experiment. It is handing a small group the burden that would otherwise have fallen on a large one.

"How narrow is narrow enough" has no universal answer, but it does have a usable test: narrow enough that the worst case still leaves damage you can remedy inside a single day, and wide enough to meet edge cases within four weeks. If you open so narrowly that four weeks pass without a single hard case, you are not running an experiment — you are postponing the learning with a plausible-sounding reason.

The second move is compare with baseline or control — and the "or" is doing real work. A baseline is the value of the old process, recorded before you started. A control is the volume that keeps running the old way, in parallel, over the same period. The latter is far stronger, because it holds seasonality and every other simultaneous change constant. If you can choose, keep the old path running alongside for a while. The cost of running two paths is lower than the cost of arguing for six months about whether the improvement came from the new system or from the season.

Nine things to monitor at once

The playbook's list has nine items, and its intent is that they be read together, not cherry-picked for the flattering ones. I have added a Scorecard column so you can see which column of the board scorecard in section 5 each one eventually lands in — that mapping is mine, not the playbook's.

Number 4 is the one I want captured in the most detail, not because it measures people but because the reasons behind an override are the best design data this window will ever produce. An operator correcting the system's output is telling you what the system misunderstood, in the most direct language available. Record the override rate as a percentage and nothing else, and you gain one metric while losing the most valuable information of the whole month.

The kill path is something you rehearse, not something you write

The playbook says "rehearse the kill path", not "have a kill path", and that difference is the difference between a document and a capability. Almost every organisation has a page in the plan describing how the system would be shut down. Very few have ever pressed the button for real, during business hours, with somebody holding a stopwatch.

This is the one point in the window with direct backing from a published standards-body document. NIST publishes Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1), and its MANAGE function names the post-deployment actions explicitly: monitoring after deployment, appeal and override channels, decommissioning, incident response, recovery and change management (MANAGE 4.1), together with regular monitoring and incident post-mortems (MANAGE 4.2).^[2] As of 5 September 2026, NIST AI 600-1 (dated 26 July 2024) is still the current Generative AI Profile, while NIST states on its own page that AI RMF 1.0 is itself being revised.^[2]

The scope needs stating here too. The NIST document is a voluntary framework and says of itself that organisations must select and tailor its actions to their use case and risk tolerance.^[2] It does not prescribe a release percentage, a review window in hours, or a 180-day sequence of this shape — the single thing it establishes is that post-release monitoring and a path back are expectations already written down in a public document, not this book author's private anxiety.

CX-REFUND-01 — a canary that did every step right and still broke

The playbook carries one worked example through the whole book: the refund assistant of Luma Commerce Thailand, case code CX-REFUND-01 (a fictional case from the playbook). Every number that follows is an illustrative value the playbook itself labels "illustrative result and decision"; none of them may be reused as a threshold or a target for a real system.^[1] I quote it because the shape of the story is exactly right, not because of the numbers.

Before release, the system passed a release gate whose results were recorded by track. The utility track returned 94.6% weighted success with priority case slices at or above 89.1%. The semantic and security track returned 96.8% support with 1.7% false accepts. The operations track returned a p95 of 3.4 seconds and a rollback drill of 11 minutes.^[1]

The recorded decision was to approve manifest rc4 at 5% exposure, moving to 25% only after a 48-hour review, with four stop conditions — a prohibited effect, a severe policy escape, a missing trace, or reviewer overload — rolling back to prod2, with N. Kanya as review owner.^[1]

Notice that this decision has everything a good decision needs: an exposure level as a number, a promotion condition expressed as time, stop conditions expressed as events rather than feelings, a rollback destination with a real version name, and one person's name rather than a committee's. This is what doing it right looks like.

And it still broke.

At 25% rollout, a customer received a 60-day eligibility statement drawn from an obsolete promotion page that was still on the allow-list. The model proposed a THB 2,400 refund on day 45 — the execution guard blocked the payment, but the output rail had already released the wrong explanation. The stop condition fired, rc4 was rolled back, and every promotion case was routed back to people.^[1]

What happened next is what makes this an example of PROVE done correctly. The reconstructable trace confirmed that no financial effect had occurred, and identified the causes: corpus 2026-09-01 with a stale passage still in it, plus a support scorer that falsely accepted that passage, plus the payload that was released. The event was classified as a severe semantic policy escape together with a near miss, with the structural execution invariant holding throughout.^[1]

The diagnosis pointed at two boundaries that had been designed incompletely — the allow-list checked the "identity" of a source but not its "effective date", and the support scorer tested textual entailment but not policy currency. The knowledge owner therefore withdrew the page, required every page to carry owner, effective-date and expiry metadata, and added conflict detection, while the CX Quality team added time-validity checking and a customer-correction process.^[1]

The failed case was then turned into regression case CXGS-241; related hidden, adaptive, bilingual and duplicate-state cases all passed; an independent policy review approved a new manifest, rc5, and restored at 5% with a 24-hour review cycle — note that the review cycle shortened from 48 hours to 24, because uncertainty had just gone up, not down. Finally the contract, the manifest schema, the source-publishing workflow and the runbook were all updated, the same freshness check was applied to the returns and warranty products as well, and the incident could close only once the customer had been remedied, a seven-day recurrence monitor had run, and a signed evidence review existed.^[1]

The playbook governs its incident-learning loop — which I walked end to end in #15 — with one rule I would like taped beside the monitor.^[1]

"Preserve the failed case before changing it. Do not reduce a system incident to 'the model hallucinated.' Ask which boundary admitted, trusted, authorized, released, or failed to observe the behavior."

And its counterpart on the release-gate side, which is the best sentence I have read for keeping a team honest with itself during the prove window.^[1]

"Never average away a failed structural invariant or severe slice. A clean fixed suite does not establish adaptive robustness. Exceptions must name residual risk, approver, expiry and compensating control." — no average may be used to bury a failed structural invariant or a severe case slice; a fixed test suite that passes cleanly proves nothing about robustness under adaptive testing; and every exception must name its residual risk, its approver, its expiry date and its compensating control.

Interview people, because workarounds expose defects dashboards miss

The fifth move of this window is the one most often cut from the plan when the schedule tightens, and the one with the highest return per hour invested. The playbook gives the reason plainly: "interview users and operators because workarounds expose defects dashboards miss" — talk to the users and the operators, because the workarounds they invent for themselves expose defects the dashboard cannot see.^[1]

The mechanism is simple. A dashboard measures what the system does, but a workaround is what people do outside the system to keep the work moving, so by definition it can never appear on any chart. When two members of staff copy the system's output into a private file, fix it there and then pass it on, the dashboard will report full usage across every case and good downstream quality. Both are true, and together they conceal the third truth — that the system produces output nobody can use as delivered.

The interview method that works for me is three questions, one person at a time, twenty minutes each, with no manager in the room — "was there a moment last week when you didn't use the system even though you should have?" · "what do you have to fix in the system's output before you can actually use it?" · "if the system disappeared tomorrow, how would your work change?" The third is the hardest to answer and yields the straightest information, because it measures indispensability in the eyes of the people who use the thing, not in the eyes of the people who bought it.

The window's last move is stop cases that lack value or cannot be controlled, and that instruction sits in days 91–120 rather than 151–180 on purpose. Stopping is not reserved for decision day. If month four has already told you that this slice of cases can never be controlled, dragging it out for two more months "to complete the plan" is paying for politeness with the team's budget and time.

3. Days 121–150 PREPARE — Turn Lessons Into Shared Capability

The prepare window feels like the shortest and is in practice the most dangerous, because it is the moment the word "platform" legitimately re-enters the meeting room for the first time. The playbook puts it this way.^[1]

"Days 121 to 150 turn lessons into shared capability. Extract reusable services for model access, context, evaluation, identity, tools, traces, data products, vendor clauses, impact assessment, and training. Decide what is central and what remains in the domain. Establish intake, funding, architecture, release, monitoring, and retirement. Do not build a large platform before the first workflow reveals real requirements."

The verb is "extract", not "build" — and that difference is the whole of this window. Extracting means the material already exists, inside the first workflow you have just finished proving. This month's job is to separate what is reusable from what belongs to that one case, not to imagine what the next ten workflows might want.

Ten services worth extracting for reuse

These ten items are the components of what this series calls the AI and data factory, which I wrote up in full in #9. The third column is my proposal, not the playbook's — the playbook says only that you must "decide what is central and what remains in the domain" and then leaves each organisation to settle it.

My test for what belongs at the centre is a single question: if two business units did this differently, would that create a risk or merely an inconvenience? If the answer is risk — identity, trace, vendor clauses — make it central. If the answer is inconvenience, leave it in the domain and consolidate later, when a third team comes asking. Consolidating too early turns the central team into a bottleneck for work it does not understand.

Six things that need an owner before there is anything to reuse

The playbook names six governance mechanisms to stand up in the same window, and I read them as one lifecycle rather than six separate boxes.^[1]

• Intake — how requests for shared capability arrive, who screens them, and against what criteria. Without a formal way in, the real way in becomes personal acquaintance.
• Funding — who pays for shared capability. This is the item that kills the most programmes, because the central team is asked to build what everyone uses on a budget nobody will surrender.
• Architecture — who has the authority to say "don't connect it that way", and where that "no" can be appealed.
• Release — the shared gate every workload must pass, with an exemption right that always carries an expiry date.
• Monitoring — observability that belongs to the centre, rather than every team keeping its own dashboard with its own definition of the word "error".
• Retirement — the item that is always forgotten. Systems that cannot be decommissioned accumulate as debt that pays interest in risk, and decommissioning has to be designed alongside going live, not thought about when you want to stop.

The standard that already exists for "make it systematic, then keep improving it"

What days 121–150 are building has a name in the standards world: an AI management system. ISO/IEC 42001:2023 is the standard that addresses exactly this. ISO's public description states the scope as a document that "specifies the requirements and provides guidance for establishing, implementing, maintaining and continually improving an AI (artificial intelligence) management system within the context of an organization", and explains that the standard is built around a Plan-Do-Check-Act process while encouraging organisations to conduct AI risk assessments and define risk treatment activities at regular intervals.^[3] The standard's clause 8.4 is titled AI system impact assessment, which is a direct counterpart to the ninth reusable service in the table above.^[3] As of 5 September 2026, ISO/IEC 42001:2023 stands as Published, first edition, issued December 2023.^[3]

Three boundaries always have to be stated together here. One — the source playbook says of itself that it relies only on ISO's public description and does not reproduce the copyrighted requirement text; I do the same in this article. Two — certification against the standard is carried out by independent certification bodies, not by ISO, and nothing in this article is advice about seeking certification. Three — ISO/IEC 42001, NIST AI 600-1 and the AI Index report are not the same kind of thing and cannot substitute for one another. The first is a certifiable management-system standard, the second is a profile of a voluntary framework, the third is a survey-based annual report. Lining all three up on one slide as "the standards we comply with" is an error I see often and one worth correcting from the start.

What I would actually take from this standard in month five is not a certification bid but the shape of Plan-Do-Check-Act together with the phrase "at regular intervals" — because that is what answers the question of why days 151–180 need a review date fixed in advance rather than a review triggered by trouble. An organisation that only reviews when something goes wrong only has information once it is too late to fix.

4. Days 151–180 DECIDE — Scale, Reshape, Hold or Stop

The last thirty days are what the whole 180 exists for. The playbook writes it like this.^[1]

"Days 151 to 180 decide what earns scale. Review evidence with executives, operators, risk functions, and worker representatives. For every initiative choose scale, reshape, hold, or stop. Confirm realized value, residual risk, workforce effect, environmental cost, and learning rate. Update policy and evaluation, close corrective actions, and select the next decisions that reuse the core. Approve the next two-quarter roadmap and capability budget."

The most important words in that paragraph are in the first line, and they are not "decide". They are the list of four groups of people who must be in the room.

Who has to be in the room

Executives are there because this decision allocates budget and headcount, and because the word "stop" has to come from someone senior enough that it will not be quietly appealed the following week.

Operators — the people doing the actual work — are there because they are the only ones in the room who know how the numbers on the slide came to exist, and what work never appears on a slide at all. If the room holds only executives and the technical team, you are reviewing a narrative, not evidence.

Risk is there because residual risk needs someone to accept it formally rather than leaving it to float, and because a decision to scale doubles the exposure to that very risk.

Worker representatives — worker voice — are there because scaling a system changes the substance of many people's work at once, and because information about reviewer load and about trust will never reach this room intact if its only route runs through the management chain of the people asking for the scale-up to be approved.

Four verdicts

The playbook gives four verdicts and no criteria for any of them — so the "choose it when" column below is my own proposal from reading the whole chapter, not the playbook's text. I keep the playbook's own four words, which its Thai companion also leaves in English (post #1 phrased leadership question Q8 as: what earns the right to scale, what should be reshaped, held or stopped).

The bottom-right cell is the hardest in the whole table, and it is the reason principle 5 had to be written as a principle instead of being left to common sense.

💡 My view: in principle 5, quoted in section 1, the word "visibly" works much harder than the word "stop". Plenty of organisations already stop projects — but they stop them quietly, letting the budget run out on its own, with no announcement and no recorded lesson. The result is that the whole organisation learns the wrong lesson: it learns "never propose anything that might fail" instead of "evidence is what decides". A stop that is announced with its reasons and punishes nobody is the only thing that makes people brave enough to propose the harder thing next round.

Five things to confirm before the gavel

Before any verdict, the playbook names five things that must be confirmed,^[1] and I have paired each with the question worth asking alongside it.

• Realized value — value that has already happened, not value expected. The question: if the system were removed today, which number gets worse, and by how much?
• Residual risk — the risk that remains after every mitigation. The question: what is the worst event that can still occur, who has accepted that risk, and have they accepted it in writing?
• Workforce effect — the effect on people. The question: who is working harder, who is working less, and what is that second group going to do next?
• Environmental cost — the environmental cost. The question: does the added volume from scaling move this number linearly, or worse than linearly?
• Learning rate — the rate of learning. The question: from finding a problem to having a new test that prevents it, how many days did it take over the past three months, and is that number shrinking or growing?

The last item is the one I weight most heavily when choosing between Scale and Hold, because it is the only one of the five that predicts the future. The other four say what has already happened, but the learning rate says how fast the next round will be fixed — and an organisation that scales while its learning rate is still slow is scaling the benefit and the debt at the same rate.

Close the corrective actions, then approve the next two quarters

The last three tasks of this window are usually done carelessly, because everybody is tired by now. The first is to update policy and evaluation — the lessons of the past four months have to become sentences in the policy and cases in the test suite, not a lessons-learned slide. The simple test: if a lesson has changed no file in the system, that lesson has not yet been learned.

The second is to close the corrective actions completely. The remediation items still open from incidents during the prove window have to be closed with evidence, not deferred into the next cycle with the status "in progress" — because that status can survive as long as the organisation does.

The third is to select the next decisions that reuse the core and then approve the next two-quarter roadmap and capability budget. The clause "that reuse the core" is what makes the second cycle materially cheaper than the first. If the next decision you pick uses not one of the services you just extracted, you are starting cycle one again rather than entering cycle two.

The playbook's working session for this chapter is called The 180 day commitment room and has seven steps — define the strategic outcome and the nonnegotiable boundaries · rank candidate decisions by value, frequency, data, feedback and risk · select one to three and record baselines · map owners, affected groups, obligations and human authority · assign the six phases' gates, evidence and stop conditions · allocate people, protected time and capability funding · then record 30-day commitments and the first executive review date.^[1] The session is first used on day zero, but my proposal is to run it again on day 180 — this time every step has real data to fill it, and what comes out is a two-quarter roadmap built from evidence rather than from ambition.

5. The Six-Column Board Scorecard, and the Day-180 Review Table

Everything in the four preceding sections converges on a single page, and that page is the six-column board scorecard the playbook lays out on page 4 — before Chapter 1 even begins. It sits there because it is the shape of the answer the whole book is trying to make answerable.

These six columns are not categories for organising slides. They are six directions one system can move in simultaneously, and six directions that can be traded off against one another — which is the entire reason they must be read together.

The six columns and the indicators of each

The playbook governs this table with a paragraph I consider the single most important one in the book for an executive.^[1]

"No single composite score should replace this view. A faster process with rising severe errors is not progress. A safe system that produces no outcome value is not transformation. A productive workflow that exhausts reviewers is not sustainable." — no one composite score should stand in for this view; a process that got faster while severe errors rose is not progress; a safe system that produces no outcome value is not transformation; and a workflow with high output that exhausts its reviewers is not sustainable.

The playbook's Thai companion closes the same passage with one shorter and blunter line: a single composite score must not hide the trade-off^[1] — and this is why I ask you not to build a composite index out of these six columns, however many times you are asked for one. A single score genuinely does make meetings faster, but it makes them faster by deleting the information the meeting exists to weigh.

The day-180 review table

The table below is this article's own worksheet, not a form the playbook prints — I assembled it from the page-4 board scorecard plus the days 151–180 paragraph on page 52, so that it can go straight onto a meeting agenda without a further layer of translation. The one rule is that every cell must be filled with evidence or with a name, never with an adjective, and never with a target that has not been measured.

I recommend printing this table landscape, one sheet per initiative, and laying the sheets side by side on the table. Seeing three of them next to each other makes the day's most important question surface by itself — if we have capacity for two, which one do we drop? — which is a question a meeting run agenda-item by agenda-item will never ask.

6. Sixteen Metrics, and the Failure Patterns of the Second Half

The playbook closes Chapter 12 with a list of sixteen metrics for the whole 180 days, under the heading instruction "use a balanced view".^[1] The first four — inventory coverage, initiatives with business and risk owners, baseline and evaluation-plan coverage, and time to classification — are metrics of the first 90 days, which I covered in #18. The table below therefore holds the remaining twelve, which belong squarely to the second half.

Number 7 is the one to handle most carefully when benchmarking against outside figures. Stanford HAI's The 2026 AI Index Report economy chapter puts organizational AI use at 88 percent of surveyed organizations in at least one business function in 2025, up from 78 percent in 2024.^[4] The figure comes from McKinsey & Company's annual State of AI survey, as the AI Index names its own source, and it is self-reported data that the report itself labels as directional rather than comprehensive — the report prints no sample size in this chapter, so all I can write is "surveyed organizations", never "organizations" in general.^[4]

The same report also states that in 2025, AI agent use at scale was still in the single digits across nearly all business functions, and that in many functions a majority of respondents reported no use at all.^[4] The words to read precisely are "at scale" — the number describes scaling, not experimentation, which is far higher. As of 5 September 2026 both of these figures still appear on the AI Index 2026 economy chapter page as I accessed it that day, and the report states no publication month on any page I opened, so I cite the year and the access date only.^[4]

The playbook summarises this gap itself on page 4, in a sentence I consider the justification for the entire 180 days: access to the technology has spread faster than the organisational ability to delegate authority, control effects, measure outcomes and learn.^[1] The 88 percent figure is therefore not evidence that value has been realized. It is evidence only that the door is open — which brings us right back to section 1.

Failure patterns

The playbook names ten failure patterns for the 180 days.^[1] The first six are failures of the first 90 days (beginning with a platform purchase · collecting hundreds of ideas · choosing only low-value demos · assigning everything to IT · postponing legal, security or workforce work · omitting a baseline) and I wrote about them in #18. The remaining four belong squarely to the second half, and I have added a way to detect each one.

• Confusing logins with adoption — reporting user counts instead of reporting whether the people who should use it genuinely changed how they work. How to detect it: ask the team to split the user number into two groups — the intended group this workflow was designed for, and everyone else. If they cannot split it, there is no definition of the intended group, and the number being reported means nothing.
• Scaling before feedback — raising exposure because the usage numbers look good, without a single complete cycle of outcome data. How to detect it: ask which piece of evidence the most recent expansion followed. If the answer is a date in the plan rather than the name of a report or a test suite, you have found it.
• Refusing to stop weak cases — keeping an initiative the evidence does not support, because it was already announced, or because someone's name is attached to it. How to detect it: count how many AI initiatives were formally terminated with a recorded rationale in the past two years. If the answer is zero, that is not evidence of good selection.
• Building a platform so large that no decision improves in six months — the most expensive failure, and the best-looking one along the way. How to detect it: ask one question — "which of the organisation's repeated decisions measurably improved in the last six months?" If the answer is a list of capabilities delivered rather than a list of decisions improved, the factory was built before there was a product.

These four share one structure — every one of them substitutes a proxy for evidence. Logins for adoption · usage numbers for outcomes · commitment for proof · capabilities delivered for decisions improved. If you remember one thing from this section, I would like it to be that, because it lets you spot the fifth and sixth patterns nobody has named yet, on your own.

7. The Road Ahead — Start Narrow, Learn Fast, Scale Deep

If the 180 days had to compress into three phrases, the playbook has already done it on page 5: start narrow, learn fast, scale deep^[1] — and I want to point out that the third word is "deep", not "wide". The scaling this chapter describes is taking the same core to the next decision that can reuse the same pieces, not opening twenty new projects at once because the first one looked good.

What I notice about organisations that get this second half right is not that they have better technology. It is that they let themselves see bad news early. The PROVE window is designed to manufacture bad news while it is still cheap; PREPARE turns that bad news into something reusable; and DECIDE makes bad news actually affect how resources are allocated. Organisations that skip the first window meet the same bad news eventually — just at a far higher price.

If you want to start this week without waiting for day 91, I recommend these four steps, because all four can be done without buying anything.

1. Time one kill path on a system already in use, and record the four intervals — this is the single fastest piece of evidence to obtain and the one that most changes the conversation in the meeting room.
2. Interview three operators, twenty minutes each, using the three questions in section 2, then set the workarounds you hear against the system's dashboard. The gap between the two is next month's real work plan.
3. Write the stop conditions for your largest initiative as observable events rather than feelings, and have the accountable executive sign them alongside a review date.
4. Fill in the day-180 review table from section 5 with the data you have today, then count the cells you cannot fill — that number of blanks is the real distance left to travel, and it is usually shorter than feared.

And when the 180 days are up, the remaining questions stop being operational ones. They become the question of whether the leadership team can answer the fundamentals of this whole subject with evidence — which is the subject of the final post.