The 90-Day Pilot

This is Unit Two of Leading AI at Work, on the book's ninety-day pilot. Unit One ended with a choice of path. This unit takes the second path, a single-project pilot, and turns it into a plan with four stages, named roles and honest measures. Carry one question through this lecture: what should a pilot leave behind after ninety days? The answer arrives with the claims team's plan at the end. By the end you will be able to plan the four stages and their deliverables. To assign the roles and choose a minimum viable adoption. And to answer the common objections, with a return scenario you can defend.

Twelve entries on what a pilot aims for, and the four stages that get it there.

The pilot's guiding rule.

LAI 026 A Few Things Defined Well

The M-CaReM-AI method, by J. R. Carver, gives a ninety-day plan for piloting the method on one initiative. Its guiding rule is to aim for a few things defined well and used for real, not many things defined on paper. A pilot that models everything proves only that modeling takes time.

What should be left behind.

LAI 027 What a Pilot Delivers

The book lists what a pilot should leave: three to five well-defined Gold things for one critical workflow, Silver Packs for supporting things, a small set of cards, part of a matrix around one Gold thing, and AI patterns the team trusts. Each is something the team will keep using.

Where to pilot.

LAI 028 Not Already on Fire

The book's advice is a system with moderate to high risk, some supportive stakeholders, and nothing already on fire. A benefits workflow under steady pressure qualifies; one in the middle of a failed launch does not, because a crisis leaves no time to learn and its failure would be blamed on the method.

Days one to fifteen.

LAI 029 Days One to Fifteen: Scope and Seed

The first fifteen days choose the scope and seed the model. Pick the system using the book's test, and name the stakeholders, including anyone working on AI. Run a short phase one: nouns, inventory, a rough map. Pick three to seven core things and three to five candidate Gold things. Let an AI tool draft the inventory, propose zones and summarize the map, with a person checking each result. Some candidates will move off the Gold list later, and that is the pilot working.

The first deliverables.

LAI 030 Deliverables by Day Fifteen

By day fifteen the book expects a simple Object Inventory, a one-page map of zones and things, and a short list of core and candidate Gold things. None needs to be finished; each needs to be good enough for the next stage to start from.

Days sixteen to forty.

LAI 031 Days Sixteen to Forty: First Packs and Cards

Days sixteen to forty write and validate the first Packs and cards for one to three core things. Draft a Silver Pack, or a Gold Pack for a Gold thing, with purpose, sensitivity and main risks. Write a few cards: create or update, read, and generate or log where relevant. Run an object review session per thing with frontline and policy or compliance staff, record what they surface, and update the Packs. AI drafts cards and examples; people check every result.

The deliverable that is not a document.

LAI 032 Deliverables by Day Forty

By day forty, the book expects validated Packs for a few core things and useful cards for the key behaviors. It adds a third deliverable: stakeholders who recognize their world in the model. Without that recognition, the Packs are only the analyst's opinion, however well written.

Days forty-one to sixty.

LAI 033 Days Forty-One to Sixty: Tracing Gold Things

This stage adds traceability for one or two things that are legally sensitive, financially significant, or critical to safety or trust. Build a matrix for each, with rows for policies, cards, data, screens, reports, tests and procedures. Use AI and search to find references, then validate the matrix with architecture, testing, and policy and operations staff. Walk the current system against it to find gaps and drift, and try AI patterns that cross-check the documents.

The sixty-day deliverables.

LAI 034 Deliverables by Day Sixty

By day sixty the book expects one or two matrices the team can use straight away in change discussions, and a playbook: notes on how the team built them, so the next is faster. Skipping the playbook means the second Gold thing costs as much as the first.

Days sixty-one to ninety.

LAI 035 Days Sixty-One to Ninety: Use It and Measure

The last thirty days shift from building to using. Write or update cards for real changes, update Packs, and use the matrices for impact analysis. Track where the method avoided confusion or rework, where stakeholders said a view helped, and where AI output improved because it was given definitions. Collect before-and-after signals, run a structured retrospective, and decide whether to extend. The method does not replace the project framework or governance; it gives them a clearer anchor.

Three signals worth collecting.

LAI 036 Before-and-After Signals

The book names three signals a pilot can collect, even informally: requirement defects caught before build, production problems traced to misunderstood things, and how long new team members take to get up to speed. Without a before, there is no after, so note the starting point early.

Ending with a story.

LAI 037 The Story You Tell at the End

The pilot ends with a short story told to whoever decides what happens next: how we mapped our world into things, how we expressed behavior as cards, a Pack and a matrix we rely on, and concrete examples. That story is the bridge to continuing quietly or to scaling up.

Four entries on who does what in a pilot, and on the smallest adoption that still delivers.

Dividing the work.

LAI 038 Who Does What in a Pilot

The book divides pilot work among roles. Analysts lead Packs and cards; architects align definitions with systems; testers derive tests from cards; AI and analytics teams connect models and reports to Gold things through the matrix; and governance bodies approve changes to Gold things. Every role touches the same documents.

Who owns purpose.

LAI 039 Who Owns a Gold Thing's Purpose

Product owners and business or clinical leaders own each Gold thing's purpose and risk profile. The analyst writes the Pack for an Eligibility Determination, but a program leader decides what it is for and how much risk it may carry. When the analyst decides purpose too, a requirements choice quietly becomes a policy choice.

The minimum that works.

LAI 040 The Minimum Viable Adoption

The book's minimum viable adoption takes four steps. Identify the Gold things in each high-stakes domain. Create Gold Packs for those things first. Write cards only for behaviors that change a Gold thing. Build matrix entries first for the Gold things most exposed to regulation or audit. Then extend over time. The order puts the first effort where a mistake costs most, which is also where the first success is most visible.

The smallest version.

LAI 041 The Smallest Version That Helps

The book's Toolbox names the smallest version that still helps: an inventory and map; for one core thing, a Silver Pack and three to five cards; a basic matrix for it; and one or two prompt patterns used with that Pack. Even this slice changes how a team talks about requirements and AI.

Eight entries on resistance, the book's honest return scenario, and a full pilot plan. The opening question is answered here.

What resistance is for.

LAI 042 Resistance Shrinks Scope

The book's rule is to use resistance to reduce scope, not to abandon the approach. Start with one Gold thing and one thin slice of matrix around a single high-risk change, focused on problems that already caused pain: audit findings, misunderstood rules, confusing fields.

"More work."

LAI 043 "This Looks Like More Work"

To "this looks like more work," the book answers that much of it reorganizes effort teams already spend on explaining things, fixing misreadings and analyzing changes. The method puts that effort into reusable structures, AI drafts much of them, and for high-risk things, time up front is cheaper than production fixes.

"We're agile."

LAI 044 "We're Agile"

To "we're agile, we don't do big models," the book answers that the method is thing-centric, not document-centric. Stories reference cards, cards live in Packs, and Packs evolve in small steps. Nobody asks for a long specification, only enough clarity to stop repeating the same misunderstandings every sprint.

"Too messy."

LAI 045 "Our Domain Is Too Messy"

To "our domain is too messy to model," the book answers that messiness is exactly why a shared vocabulary of things is needed. Without one, people use different words for the same thing. Packs and cards are refined in iterations, and nobody captures every edge case at once.

"We have models already."

LAI 046 "We Already Have Models"

To "we already have data models, diagrams and process maps," the book answers that the method connects them. Things bridge data models and process maps; Packs reference tables and workflows; matrices tie policy, data, process, screens and tests together. Existing models are raw material.

"The vendor won't support it."

LAI 047 "Our Vendor Won't Support It"

Where a vendor platform fixes the data model, the book says to document how the vendor's fields map to your Gold things. The mapping is imperfect, and the gaps are the point: they become visible in governance discussions, instead of surfacing first in an audit.

An honest return scenario.

LAI 048 A Conservative Return Scenario

The book's return scenario uses assumptions it labels illustrative, for teams to replace with their own data. Rework at twenty percent of effort; half of it from requirement issues, so about ten percent; a thirty to fifty percent reduction in that slice; roughly three to five percent of team capacity recovered. The book promises no precise improvement. The point is that requirement-driven rework is a measurable slice, which the pilot's own numbers confirm or correct.

A full plan for claims.

LAI 049 A Pilot Plan for Claims

A worked example, constructed for this course, plans a pilot for an insurer's property claims. Grace names the stakeholders, builds an inventory and map, and picks two Gold candidates, the Claim Decision and the Payment, noting that a third of recent change requests needed rework. She writes a Gold Pack and four cards; reviews change the definition twice. A matrix finds an outdated reason code, and a real change catches a forgotten letter template. That answers this lecture's question: a pilot should leave a few things defined well and used for real, with a before and an after.

Look at what you can now do. You can plan the four stages of a ninety-day pilot, from scope and seed to use and measure, and say what each delivers. You can assign the roles, keep purpose with leaders, and choose a minimum viable adoption that starts with Gold things. And you can answer the common objections and present a return scenario built on assumptions you then replace with your own numbers. Unit Three turns to introducing an AI feature safely.