Phase Four: Checking Against Reality

This is Unit Seven of The M-CaReM-AI Method, on phase four: checking against reality. Unit Six built Packs, careful descriptions of each thing. A careful description can still be wrong. This unit puts each Pack in front of the people who live with the thing. Carry one question through this lecture: how do you hear the disagreement that a polite room keeps to itself? The answer arrives with four techniques for surfacing it. By the end you will be able to say what validation is. To plan a review session. To keep AI to the scribe's role. And to run a session, a walkthrough and a desk review, and record what they find.

Four entries on what material validation is, what it is not, and its three modes.

A careful Pack meets reality.

MCM 151 We Never Use That State

The method's validation chapter opens with a careful Gold Pack meeting the people who use the thing. In the book's example, a nurse never uses the new state, a risk officer asks where refused care goes, and a manager asks about reports sent back. The people who live with a thing are the only reliable test of its description.

What validation is.

MCM 152 What Validation Is

Material validation asks whether the method's descriptions match how the world works, one thing at a time, with the people who live with it. Systems engineering guidance agrees: a stakeholder requirement is checked for being justified, complete and in the users' own language. The book's example: we never say client here; we say member.

What it is not.

MCM 153 What Validation Is Not

Validation is not signing off a long specification, defending a design, or reviewing requirements line by line. Its output is updated Packs and cards, disagreements written down, and a shared sense of talking about the same things. It is reached gradually, not in one meeting.

Three modes.

MCM 154 Three Modes of Validation

The method uses three modes: object review sessions, which build alignment on one thing; scenario walkthroughs, which test the model in motion; and desk review, which catches detail and gives quieter voices room. The book expects most teams to use all three.

Three entries on planning a review session: who attends, what it aims for, and how to prepare.

Who is in the room.

MCM 155 Who Is in the Room

The method validates each thing with frontline users, supervisors, policy and compliance staff, technology and data staff, and the analyst who owns the Pack. For any high-risk thing, all four perspectives take part at least once. The right mix, not a crowd.

What a session aims for.

MCM 156 Session Goals

A sixty to ninety minute session aims for agreement, or plainly documented disagreement, on one thing's purpose, definition, key fields and lifecycle, plus a list of corrections and open questions. The target is better and shared, not perfect forever.

Preparing.

MCM 157 Preparing the One-Pager

Before a session, prepare a one-page summary of the thing. AI drafts it well from the Pack; the analyst checks it, then sends it with one request: come ready to tell us where it does not match reality. Familiarity is enough.

Five entries on what makes validation fail: silence, AI in the wrong role, distance and the common pitfalls, and one field a session settles.

Silence.

MCM 158 Silence Is Dangerous

In validation, the method treats silence as a warning, not agreement. After a quiet seventy minutes, the analyst has learned almost nothing, however much the room nodded. Use explicit prompts, call on different roles, and ask for stories; agreement has to be heard to count.

AI's role.

MCM 159 AI as Scribe, Not Judge

In validation, AI may summarize, prepare examples and draft edits, but never decide whether a description is right. A tool turns session notes into proposed changes; the steward accepts or rejects each. The book's warning: the tool thinks it looks right is not validation; it is a confabulation risk.

Validating across distance.

MCM 160 Validating Across Distance

For distributed teams, the method uses two-pass reviews, shared whiteboards and recorded walkthroughs. In a two-pass review, people rate the Pack alone, then a short call covers only the points where ratings diverged. Remote feedback is folded in like any other.

Five pitfalls.

MCM 161 Five Validation Pitfalls

The book names five pitfalls: a design meeting, sign-off asked too early, one kind of stakeholder, silence taken as approval, and AI validating instead of people. When people debate button colors, note it for design and return to what the thing is.

A field validation often settles.

MCM 162 Harm Level and Severity

Validation often settles what a field means. In the book's example, the group agrees that harm level describes the patient's outcome, while severity describes how serious the event was. Two fields that sound alike and are used interchangeably will produce reports that disagree.

Ten entries on running validation, from the session itself to the library's own review. The opening question is answered here.

Opening the session.

MCM 163 The Session: Framing and Definition

The book's seventy-five minute session opens with framing: the group is testing whether this description is accurate enough to build on, not designing the system, and disagreements are welcome. Then purpose and definition: would people explain the thing to a new colleague this way, and what is missing? Aim for that's basically right; total agreement in a first session usually means people were not listening.

The fields.

MCM 164 The Session: Fields

The longest part walks the key properties. Ask which fields people always care about, which they never use, what goes into notes for lack of a structured place, and whether each required field is truly required. Capture additions, removals and renames, and settle meanings such as harm level versus severity. Watch for compliance items. Leave data types out; this step is about meaning.

Lifecycle, cards and the close.

MCM 165 The Session: Lifecycle and Cards

The rest covers the lifecycle, a quick card check, and the close. Ask which states are never used, which are missing, and which transitions happen in practice, marking likely new cards. Read two or three key cards and ask whether each happens as written. Close by stating the Pack changes, listing open questions with owners, and promising an updated Pack. One thing, one session, one updated Pack.

Testing a model in motion.

MCM 166 Scenario Walkthroughs

A scenario walkthrough tests whether a model holds up in a real situation. Choose a real path, such as an application becoming a case, a determination, a notice and an appeal. At each step, say which thing is touched and whether its states and fields suffice. Ask where you would capture a detail, and which thing shows the truth now. When something does not fit, record what is missing. The book recommends walkthroughs especially for Gold things.

Review in their own time.

MCM 167 Desk Review

Desk review lets busy or careful reviewers, especially policy and legal staff, validate a Pack in their own time. Send it with a short guide and three questions: what is wrong or missing, which fields compliance requires, and which states or transitions policy forbids. Accept comments in any form, apply them, and bring major conflicts back to a short joint session. A tool can show where reviewers disagree, but not which of them is right.

Four techniques for disagreement.

MCM 168 Four Ways to Surface Disagreement

The book gives four techniques. Red, yellow, green: everyone rates each section, and the time goes to yellows and reds. Teach the new hire: would the Pack explain the thing to someone shadowing you? Where would you put this: present a messy detail, such as a patient refusing care, and ask which thing and field it belongs in. Failure stories: where would a past problem live in the Pack? That answers this lecture's question: a polite room hides disagreement, so each technique asks for a specific, concrete answer that cannot be nodded through.

The checklist.

MCM 169 The Validation Checklist

The book's checklist confirms a thing is validated well enough to build on. Frontline and compliance staff each took part. Non-technical stakeholders accepted the definition. Properties were reviewed and the lifecycle adjusted to real work. Key cards were checked, walkthroughs found no major gaps, the open questions are current, and AI-generated material was checked. Most should be yes; a no on the first is the one that should stop the team.

The library's review.

MCM 170 Reviewing the Library Loan Pack

A worked example, constructed for this course, runs a review of the library's Silver Loan Pack. The analyst first removes a sentence the AI tool added to the one-pager, claiming loans could transfer between members. In the session, a librarian shows that using a reference item inside the building is not a Loan. The systems administrator and finance officer add a returning branch field for the council figures. Nobody can say what happens when an item is lost, so that stays open. Four people found what no document, analyst or tool had seen.

Recording the outcomes.

MCM 171 Three Corrections and a Parked Disagreement

A second constructed example records the outcomes: in-library use becomes its own Bronze thing, the Loan gains a returning branch field, and a lost state is added. The disagreement over lost loans, close at once or wait ninety days, is not settled by the analyst. Both positions go into the open questions with an owner and a date. The old system had answered that question silently and inconsistently; writing both sides down turned an argument into a decision someone will make.

From notes to changes.

MCM 172 From Notes to Pack Changes

A third constructed example has an AI tool turn the notes into proposed Pack changes. Four match the notes. A fifth, letting a lost loan become active again, is the finance officer's position, not a decision, so the steward rejects it. A sixth quietly rewrites the definition, and is rejected. The two-way check finds nothing unlogged, and version one point one is approved. The tool saved time, but also tried to settle the parked disagreement and change the definition; treating every proposal as a proposal caught both.

Look at what you can now do. You can say what material validation is: a conversation with the people who live with a thing, in their language, one thing at a time. You can plan a session: the right mix, clear goals and a one-page summary. You can keep AI a scribe, treat silence as a warning, and avoid the five pitfalls. And you can run a session, a walkthrough and a desk review, surface disagreement with four techniques, and record what you find. Unit Eight traces what depends on what.