The Operating Model

This is Unit Five of Leading AI at Work, on the operating model. Unit Four closed on a micro-playbook for any domain. This unit asks what keeps that work alive after the people who started it move on. Carry one question through this lecture: why does good method work fade? The answer arrives with a claims team rebuilt at the end. By the end you will be able to assign the operating model's hats. To run its four rituals, including the AI feature gate. And to measure the method, spot its failure modes, and scale it.

Eight entries on why good work fades, and the responsibilities that keep it going.

Good work, fading.

LAI 101 The Pack Nobody Opened

The M-CaReM-AI method, by J. R. Carver, opens this chapter with a claims team whose champion moves on. Fields creep in unrecorded, and a vendor's AI pre-fills outcomes nobody checks against the matrix. The method had not failed; it had never become how the team worked.

What keeps a method alive.

LAI 102 Four Things an Operating Model Needs

The book says a method outlives its starters only with four things: clear ownership of each Pack, simple routines for updating them, agreed rules for which domains need Gold treatment, and documents people can find. Together they make it how things are done here.

Responsibilities, worn part-time.

LAI 103 Hats, Not Job Titles

The operating model needs no new job titles, only a few named responsibilities people wear part-time. A senior analyst might be steward for the Case and the Determination alongside her job. Unnamed responsibilities fall to whoever cares, until they leave.

Meaning, and readability.

LAI 104 The Steward and the Pack Editor

The Object Steward, taught in The M-CaReM-AI Method, lesson one hundred thirty-seven, owns a thing's definition, one per Gold thing. The Pack Editor keeps Packs readable and consistently named, and acts when one is reported stale. These are different jobs, though one person may hold both.

Guarding the web.

LAI 105 The Matrix Custodian

The matrix custodian, often an architect, testing lead or controls specialist, keeps matrices existing and roughly accurate for Gold things, and checks that change and AI reviews consult them. The custodian does not make every change; the role guards the traceability web from collapse.

The AI hat.

LAI 106 The AI Safety Lead

Where AI use is meaningful, the book names an AI Safety Lead. The lead makes sure every AI initiative names the things it touches, the Packs that inform it, and the matrices it must update. The first concern is that AI never quietly redefines a Gold thing.

Where that lead sits.

LAI 107 Alongside, Not Above

The book places the AI Safety Lead alongside each area's owners, not above them, on one condition: real authority and time. Added on top of a full job, it says, the role becomes a name on a chart rather than a check on the work.

An optional forum.

LAI 108 The Domain Council

The optional Domain Council gathers stewards, architects, testers, AI leads and policy leads for one domain. It resolves naming conflicts, approves Gold definition changes, prioritizes Pack upgrades, and reviews AI proposals touching Gold things. The book calls it the guardian of the shared vocabulary.

Eight entries on the four light rituals, the AI gate at their center, and how they fit into delivery.

Ritual one.

LAI 109 Ritual One: Object Reviews

The first ritual reviews each Gold thing, and important Silver ones, every six to twelve months, led by its steward. Are the definitions still accurate? Have fields or states crept in outside the Pack? Do recurring problems point to gaps? Have AI features been added that the Pack or matrix should reflect? Record the outcome, usually minor updates, and set the next date. A review with no next date is a one-off; the cadence makes it a ritual.

Ritual two: one question.

LAI 110 Ritual Two: One Question in Change Control

The second ritual adds one question to existing change reviews: which things are materially affected, and have we checked their matrices? It applies to changes that touch a Gold thing, alter decision logic, or change AI behavior, which get a brief walk through the matrix rows, as The M-CaReM-AI Method, lesson one hundred ninety-six, teaches. The custodian owns asking it. It is one question, not one committee.

Ritual three: the gate.

LAI 111 Ritual Three: The AI Feature Gate

The third ritual is a gate every AI feature proposal passes before build. It names its primary and secondary things, references their Packs and matrices, states what the model reads, states what it writes or influences, and states how outputs are reviewed, by whom, and before what. The AI Safety Lead checks that AI is not redefining a Gold thing and that the suggest-or-decide line is clear. A proposal that cannot fill the items shows where the team's understanding runs out.

The method's view of the gate.

LAI 112 The One Step for AI Governance

The method's own judgment, not a regulation, is that the gate is the one step to take if a team does nothing else for AI governance. Its value is timing: the questions come before the feature exists, when changing an answer is cheap. After launch they cost a redesign.

Where suggesting ends.

LAI 113 Drawing the Suggest-or-Decide Boundary

The book gives a way to draw the suggest-or-decide line. List every AI output, including pre-filled fields. For each, ask what happens if nobody looks. Anything that would then change a decision, record, status or customer message is on the system-decides side, and goes behind human approval, unless an error would be minor and automation is agreed in writing. That nobody-looks question is the test.

Lines move.

LAI 114 Boundaries Drift

The book warns that the boundary drifts as features grow. A suggestion that becomes the default, pre-filled and rarely changed, has quietly crossed to the system-decides side. One check at launch is not enough; it belongs in the object reviews.

Ritual four.

LAI 115 Ritual Four: Definition-of-Done Lines

The fourth ritual adds lines to the definition of done for stories that change a core thing's meaning or behavior: Pack updated if needed, cards created or updated, matrix updated if Gold. They are checked when the story is accepted, not as a separate approval. Applied to every story, they become boxes ticked unread.

Built into delivery.

LAI 116 Weaving the Method Into Delivery

The book's aim is the method inside the delivery a team already runs. Discovery builds the inventory, map and early Packs. Refinement tags stories with their things and logs Pack updates. Design brings Packs and Gold matrices into reviews. Implementation uses cards for acceptance criteria and Pack examples as test data. After release, Gold matrices are re-checked. Testing leads map cards to test suites, so when something changes they look tests up instead of guessing.

Nine entries on measurement, failure and scale, ending with a claims team rebuilt. The opening question is answered here.

The first two metrics.

LAI 117 Metrics: Clarity and Rework

The book's first metrics are time to clarity, how long a newcomer takes to understand the core things, and rework from misunderstood things, defects whose root cause was a misread thing. The goal for rework is a noticeable fall, not zero.

Two more.

LAI 118 Metrics: Rewrites and Matrix Use

It adds the AI rewrite ratio, how much of a draft people must rewrite, and matrix use: whether a change used the matrix, and whether it revealed items otherwise missed. The book's line: you do not need dashboards; you need honest trends.

Acting on overrides.

LAI 119 Acting on Overrides

The last metric is how often people overrule the AI, building on the log taught in Generative AI at Work, lesson one hundred forty-four. Record each output as accepted, edited or rejected, with a short reason: wrong fact, rule, tone, or missing information. Look for patterns. Fix tone in prompts, facts in grounding, and wrong rules that passed review in reviewer training. NIST suggests such data may be worth collecting; the book adds that a team that never overrides deserves a closer look.

Where the documents live.

LAI 120 Where Everything Lives

The book gives the documents obvious homes: an object library, a matrix repository, backlog tags, and a prompt library. Packs are findable by thing name, matrices link from their Packs, and each prompt template has an owner and a last-tested date. Consistency matters more than tools.

Four ways it fails.

LAI 121 Four Failure Modes

The book names four failure modes. Shelfware is documents nobody opens. A fortress is a gatekeeper enforcing the method rigidly. A stale Pack drifts from the code. AI without anchors changes decisions unchecked. Each has a recovery.

Recovering from each.

LAI 122 Recovering From a Failure Mode

For shelfware, shorten documents toward sharp Silver Packs and ask for them in key meetings. For a fortress, return to the core questions, loosen non-essential rules, and concentrate on Gold things. For a stale Pack, assign a steward, refit it against schema, screens and policy, and add it to the review cadence. For AI without anchors, name each feature's things, update their Packs, and introduce the gate. Champions most often cause the fortress themselves; the recovery is to ask less, in fewer places.

Scaling up.

LAI 123 From Local Craft to a Center of Excellence

The book describes four stages of scale: local craft, shared patterns, domain libraries, and a center of excellence, perhaps three to five people giving part of their time to train, maintain templates and connect the method to AI governance. Each stage starts with written success stories, not a mandate.

Now, or later?

LAI 124 Evaluating a Change: Now or Later

The Toolbox's change checklist adds a decision to the walk The M-CaReM-AI Method teaches. Identify affected things and which are Gold. Open each Pack and ask what changes. Highlight the touched matrix rows, and list what must be revisited, from policies to prompts. Mark must-change items, those touching legal duties, safety or critical functions, and should-change ones, and record delays as known debt. Plan the work as stories. One focused session is enough, and recording debt keeps a deferral from becoming a forgotten gap.

The claims team, rebuilt.

LAI 125 An Operating Model for a Claims Team

A worked example, constructed for this course, rebuilds the claims team from the book's opening scene. Grace becomes steward for the Claim Decision and the Payment, Owen edits the Packs, the test lead is matrix custodian, and the architect becomes AI Safety Lead with two days a month. The Claim Decision gets a six-month review with its next date set, change meetings add the question, AI proposals pass the gate, and stories carry the done lines. In month two, the same vendor pre-fill returns. At the gate, the boundary test shows the pre-fill would become the decision, so it is accepted only as a suggestion beside the decision, with every response logged. That answers this lecture's question: good work fades without routines, and here a routine asked the question at the right time.

Look at what you can now do. You can assign the hats, steward, Pack Editor, matrix custodian and AI Safety Lead, and give that lead real authority and time. You can run the four rituals: object reviews with a next date, one question in change control, the AI feature gate with its nobody-looks test, and done lines for stories that change a thing. And you can measure with honest trends, recover from the four failure modes, and scale on success stories. Unit Six turns to governing AI with NIST.