The Five Phases, and AI as a Copilot

This is Unit Three of The M-CaReM-AI Method, on the five phases, and AI as a copilot. Unit Two named material cause and showed how often it goes unwritten. This unit sets out the method that writes it down: five phases, each answering one question and producing one document, with AI working inside each. Carry one question through this unit: if AI can draft every document the method uses, what is left for people to do? The answer arrives with the method's one-line table of AI by phase. By the end you will be able to name the five phases and what each produces. To state the method's rules for AI. To fit the phases into a real project and existing practices. And to apply the five questions to a system and a change.

Six entries on the five phases as five questions, each with the document it produces.

Questions you keep asking.

MCM 051 Lenses, Not Gates

The method's five phases are five questions you keep asking, not gates you pass once. In the book's example, a mentor writes them up: what are the things, what are we doing to them, where is each kept, does it match reality, and what happens when it changes? Real projects move back and forth.

Phase one.

MCM 052 Phase One: What Is It Made Of?

Phase one, material context mapping, names the nouns before the verbs. A team collects candidate things, lists them in an Object Inventory, sketches three to six zones with labelled arrows, and marks three to seven core things. AI can suggest candidates, but never decides what your world contains.

Phase two.

MCM 053 Phase Two: What Are We Doing to It?

Phase two replaces vague requirement sentences with Material Requirement Cards, which always name the thing, the change and the fields. For each core thing, a team writes cards for creating, reading, updating, archiving, generating and logging. The method calls AI here a fast junior analyst.

Phase three.

MCM 054 Phase Three: One Place per Thing

Phase three gathers everything about each core thing into an Object Pack, a short living specification organized around the thing. When someone asks what a Case is, the team points to the Case Pack. AI may draft and update a Pack, but never change a definition silently.

Phase four.

MCM 055 Phase Four: Does It Match Reality?

Phase four, material validation, puts each Pack in front of the people who live with the thing, one thing at a time: frontline users, supervisors, compliance staff and engineers together. The method is firm that validation is human work; AI's role there is clerical.

Phase five.

MCM 056 Phase Five: What Else Must Change?

Phase five builds a traceability matrix for each high-risk thing, linking it to the policies, cards, data, screens, tests and procedures that depend on it. When a rule changes, the team follows the matrix to everything that must be revisited. Matrices are for high-risk things only.

Five entries on AI inside the method: its place among the causes, its principles, its failure modes and its controls.

Where AI sits among the causes.

MCM 057 AI as an Efficient Cause

In the method's terms, AI is an efficient cause: a powerful agent of change that must stay grounded in material and final cause. A tool drafts cards quickly, which is motion, but only the team's definitions and purposes say whether the cards describe the right things.

Three principles from Course One.

MCM 058 Three Copilot Principles

The method sets three principles for AI: it proposes and people decide; it works from context, not scratch; and its output is marked as a draft. Generative AI at Work taught all three. The method adds that AI may never quietly change an approved Pack or card.

What to watch for.

MCM 059 Three Failure Modes

The method names three AI failure modes: invented fields, rules confident but wrong, and definitions that drift over time. The defences are checking against real policy and data, involving experts for high-risk things, and controlling approved documents. Drift is the quietest, because each change looks small.

Controlled documents.

MCM 060 Controlled Documents

The method treats approved Packs and cards as controlled documents: AI may propose changes, but never approve or deploy one. A suggested change arrives as a tracked proposal for the thing's owner. The risk this guards against is the small edit nobody reviewed.

Recording AI's part.

MCM 061 Recording AI's Part

For high-risk things, the method adds a record of where AI drafted or revised a Pack, card or matrix entry, so a reviewer can see that a section was AI-drafted and then corrected. Without that record, nobody can tell later how a definition evolved. Governed tools are covered in Course One.

Seven entries on fitting the phases and AI into a real project and the practices a team already uses. The opening question is answered here.

What the method leaves in place.

MCM 062 Not a Replacement

The method does not replace the practices teams already use; it gives them a stable reference point in the things themselves. Stories, specifications, process models and test plans all stay, each pointing to the Pack and cards for its thing. In high-stakes work, the book's reason to adopt it is managing risk, not elegance.

The phases across a project.

MCM 063 The Phases Across a Project

The book maps the phases onto project stages. Discovery leans on phase one, with a few example cards. Early design ramps up cards, begins Packs for core things, and runs the first validation sessions. Build keeps cards arriving, loops Packs and validation, and starts traceability for high-risk things. Operations returns to validation as feedback arrives, and uses traceability for every change. Every phase recurs; what changes is the weight each carries.

What to have before what.

MCM 064 What to Have Before What

The method names what should be in place before certain decisions. Have the things and the map before big scope decisions. Have the cards before serious design or testing. Have a Pack and one validation session before complex features on a thing. Have the matrix before approving a risky change. When one is missing, say so and record it as a known risk. These are guardrails, not gates; skipping one should be someone's decision.

AI's role, phase by phase.

MCM 065 AI by Phase

The book sums up AI's role in one line per phase. In mapping, AI suggests things and you confirm. In cards, AI drafts and you refine. In Packs, AI assembles and you match it to reality. In validation, AI prepares and drafts edits, and you run the sessions and decide. In traceability, AI proposes impacts and you own the call. That answers this unit's question: the tool brings speed, and people bring the material cause, the judgment and the decision. If a row ever has no human half, the method is no longer being followed.

Keeping the formats you use.

MCM 066 Stories, Specifications and Cards Together

The method keeps a team's existing formats and anchors them to things and cards. Stories keep their user's point of view and point their acceptance criteria at a card. Traditional specifications group requirements by thing. Behavior-driven scenarios take key terms from the Pack. Test plans are tagged by thing and card. Nothing asks a team to stop working the way it works; every artifact says which thing it is about.

Other methods, as the book sees them.

MCM 067 Other Methods, as the Method Sees Them

The book compares the method with established practices, and these are its own characterizations. It calls the method philosophically aligned with Domain-Driven Design, sharing a common language and adding Packs, cards, matrices and high-risk things. Process models stay, with lanes that change a high-risk thing pointing back to its Pack. Existing traceability matrices stay, anchored in things rather than features. This course makes no further claim about any other method.

The whole method in five lines.

MCM 068 The Five-Line Picture

The book closes its overview with five lines. Name the things. Say what you do to them, on cards. Put everything about each thing in one place, its Pack. Check those definitions with the people who use, govern and build the thing. Use them as anchors when change comes, through matrices. And AI is welcome in every room, but never gets the final vote on what your world is made of.

Two constructed examples that ask the five questions of the library, and of one proposed change.

The library through five questions.

MCM 069 The Library Through Five Questions

A worked example, constructed for this course, asks the library's team the five questions. The first finds a missing thing, a Lost Item Report kept in a paper binder. The second lists what is done to a Loan. The third finds it described in four places, so the Loan needs a Pack. The fourth reveals that branch staff were never asked how renewals work. The fifth recalls the broken overdue notices, and makes the Loan the first candidate for a matrix. One meeting showed where each phase starts.

One change through five lenses.

MCM 070 One Change, Five Lenses

A second constructed example takes a proposed change, pausing a Loan while a member is in hospital, through the five questions. A pause becomes a state, not a new thing. An AI tool drafts the card and invents a diagnosis field, deleted at once. The Pack gains a paused state. Branch staff point out that waiting holds must not wait forever. And the matrix shows three things that read the due date, one the AI's impact list had missed. The frames caught both of the tool's errors.

Look at what you can now do. You can name the five phases as questions: what it is made of, what we do to it, where it is kept, whether it matches reality, and what else must change. You can state the method's rules for AI: an efficient cause, three principles, three failure modes, controlled documents and a record of its part. You can fit the phases into a project and keep the formats your team already uses. And you can ask all five questions of a system and a change. Unit Four begins phase one in depth.