Putting the Method Into Practice

This is Unit One of Leading AI at Work, the third course in a series that began with Generative AI at Work and continued with The M-CaReM-AI Method. The first two courses taught how to use AI tools safely, and how to define the things a system is made of. This course is about leading that change in a real organization, and it starts small. Carry one question through this lecture: whose permission do you need to start working this way? The answer arrives with the last worked example. By the end you will be able to explain how the method starts with one person. To compare the three adoption paths. To fit the method into the tools you already use. And to choose a path for your own work.

Five entries on how the method can begin with one person, and the habit that drives everything else.

An analyst changes one habit.

LAI 001 One Analyst, One Monday

The M-CaReM-AI method, by J. R. Carver, says practice can start with one person working differently. In the book's example, an insurance analyst lists the things a change touches and writes three cards first, then gives his AI tool his definitions. Weeks later, his impact notes alone caught a report the change would break.

What that start teaches.

LAI 002 Nobody Has to Approve It

The book's lesson is that the method can begin with one practitioner, and nobody has to approve it first. Two months after his quiet start, the analyst's manager asks him to run a pilot, because the results showed in his work. In the book's telling, starting small is how most change begins.

The habit underneath.

LAI 003 Before What Happens, What It Happens To

The method's habit is to ask, before talking about what happens, what it happens to. Instead of starting with a new workflow for appeal cases, a team first asks what an Appeal Case is, what it is made of, and who cares if it is wrong. Most teams are trained behavior-first, so this takes practice.

Stories are not dropped.

LAI 004 Stories Inside a Stronger Frame

The method keeps stories, use cases and feature lists, and places them inside a stronger frame. Stories reference cards, cards reference things, things sit in validated Packs, and Packs sit in a traceable web of policies, data, screens, reports and tests. The frame slows the rush into vague features and keeps AI inside defined things.

Where the effort pays off.

LAI 005 When the Method Pays Off

The book says the method pays off most in high-stakes domains, where decisions rest on data and policy, rules change often, and AI is already present. The M-CaReM-AI Method, lesson ten, covers when it is overkill. Begin where a mistake would reach a person.

Nine entries on the three adoption paths, from one person's practice to a standard for a whole department.

Three levels of ambition.

LAI 006 Three Levels of Ambition

The book describes three paths, each phrased as a commitment: I will work this way; we will try this here; this is how we do requirements. Nobody, the book says, has to persuade the whole organization to change by next Monday.

The first path.

LAI 007 Path One: Individual Practice

On the first path, one analyst or product owner works this way on their next piece of work. They list the key things, sketch a small map, draft cards for the riskiest behaviors, and give AI tools definitions first. Over time, people notice the clearer work, and that is often how change starts.

Steering a meeting gently.

LAI 008 Steering a Meeting Toward Things

Individual practice includes steering conversations toward things. When someone uses a broad word such as case, ask what exactly is in a case here, and write it down. When a change is proposed, ask which records an audit would need. Give AI tools definitions first and ask for card drafts, and ask for tests per thing or per card. Keep your own notes organized by thing. The book's tone is gentle: a question asked from curiosity opens a conversation; the same question asked as a correction closes it.

The second path.

LAI 009 Path Two: A Single-Project Pilot

On the second path, someone with influence over one project proposes an experiment: try a thing-centric approach here. The conditions are no renaming, no new bureaucracy, and existing backlog, design and test processes all stay. A pilot arriving with new jargon and forms has already lost.

Three small additions.

LAI 010 Three Additions to Existing Work

The pilot adds three things to existing work: links to Packs in stories, card identifiers in acceptance criteria, and sections from the traceability matrices in change-impact notes. Each is small enough to survive a busy sprint; additions needing their own meeting tend to be dropped.

What the pilot should prove.

LAI 011 Evidence at the End of a Pilot

The book says a pilot should end with evidence from three questions. Did defects fall, especially where things were misunderstood? Was impact analysis easier when scope changed? Did AI-assisted work feel more reliable? Those results, not enthusiasm, are the argument for going further.

The third path.

LAI 012 Path Three: An Organizational Pattern

On the third path, a leader of a practice introduces the method as a lightweight standard for high-risk domains: an inventory and map, Packs for core things, cards for high-value behaviors, and matrices for things with safety, financial or legal weight. It comes with templates, training and a community of practice, not a mandate alone.

Questions at governance reviews.

LAI 013 Running Governance Checkpoints

The organizational path adds a few questions to existing governance. At a review, ask to see the Packs for the solution, ask which things have matrices, and ask how the Packs were validated with real users. Record each gap as an action with an owner and a date, and revisit those actions next time. A checkpoint that only blocks teaches people to hide gaps, so treat a weak answer as work to schedule, not a failure to punish.

Not a rival framework.

LAI 014 The Object Layer Under Any Framework

The book says the method does not replace an existing methodology. It sits underneath agile, traditional and scaled frameworks as the object layer: the definitions of things that give those frameworks a stable reference point. Presenting it as a rival invites a contest it does not need.

Six entries on fitting the method into the tools a team already owns, and on how far an organization needs to go.

No platform to buy.

LAI 015 No New Platform Needed

The book's advice is that adoption needs no new platform. Backlogs, wikis, data catalogs, test tools and prompt libraries each gain a field, page or tag for things. Buying a tool first often delays the work, when a field in an existing backlog does the job today.

Backlogs and wikis.

LAI 016 Fitting the Method Into Backlogs and Wikis

In the backlog, add a field or tag for each story's primary thing, cite card identifiers in acceptance criteria, and group items by thing for impact analysis and release planning. In the wiki, give Packs a section of their own, one page per thing, keep each matrix on or linked from its thing's page, and link diagrams and policy pages to the Packs. The book's caution: a tag on half the stories is worse than none, because the missing half looks like work that touches nothing.

Data, tests and prompts.

LAI 017 Fitting the Method Into Data, Tests and Prompts

The same approach extends further. Add a thing attribute in the data catalog, tag interfaces with their primary thing, and tag test cases with their thing and card, so a change shows exactly what to rerun. Keep a small library of prompt templates that name a thing, drawn from the prompt patterns The M-CaReM-AI Method, lesson two hundred eight, introduces. Tag new work from day one; backfill only the high-risk things.

A prompt and its Pack.

LAI 018 Prompt Plus Pack

The book's rule for the prompt library is to treat a prompt and a Pack as a pair. A request to draft screen copy goes to the tool together with the thing's key properties and constraints. The book's claim is that results are clearer, safer and easier to validate.

Five levels.

LAI 019 Five Levels of Maturity

The book describes five levels of maturity: ad hoc things, local Packs, a cross-team vocabulary, material traceability, and AI-informed, thing-anchored work. At level one, case, file and record mean roughly the same; at level four, change control always checks the matrices. You do not finish the method; you grow into it.

How far is far enough.

LAI 020 Level Three or Four Is Enough

The book says an organization need not reach level five everywhere. Level three or four in the critical domains is already a major step. A benefits agency might reach traceability for eligibility while its room booking stays at local Packs. Aiming high everywhere spends effort where risk is low.

Two entries that apply the paths to your own work. The opening question is answered here.

Choosing your path.

LAI 021 Choosing Your Adoption Path

Choosing a path depends on your influence and the risk in front of you. Name the work you control: your own tasks, one project, or a practice. Name the riskiest thing in it. If you control only your tasks, start individual practice tomorrow; if you shape a project, propose a pilot with the three additions and agree its evidence; if you lead a practice, set the standard for high-risk domains only. Decide what maturity would count as success. The paths are not a ladder; the path follows the evidence.

One analyst's first month.

LAI 022 An Analyst Starts Alone

A worked example, constructed for this course, follows Amira, an analyst at a city housing office. Nobody asks her to change. She lists the things a rent-assistance renewal touches and picks the Assistance Award, whose mistakes reach families. She asks gently what exactly is in a case, and the team finds the word had two meanings. She writes three cards, gives the approved AI tool her definition first, and deletes a field it invented. A month later, a colleague asks why her notes caught a report that would have counted renewals twice. That answers this lecture's question: nobody's permission was needed; each move was one of the book's, and the difference showed up in the work.

Look at what you can now do. You can explain how the method starts with one person, and name the habit underneath: ask what a change happens to. You can compare the three paths, and say what a pilot adds and what an organizational standard asks at its checkpoints. You can fit the method into the tools you already use, keep prompts paired with Packs, and judge how far an organization needs to mature. And you can choose a path for your own work. Unit Two turns the pilot path into a ninety-day plan.