Why the Method Exists

This is Unit One of The M-CaReM-AI Method, on why the method exists. This course teaches the M-CaReM-AI method, by J. R. Carver, at a practitioner's depth: the five phases and the documents each one produces. It follows Generative AI at Work, and points back to that course instead of repeating it. Carry one question through this unit: if AI can now write requirements in seconds, why do systems still end up misunderstood? The answer arrives with a six-question diagnostic near the end. By the end you will be able to explain why fast text can leave a system less understood. To describe material cause and why features sit on things. To recognize how teams leave things undefined. And to run the diagnostic and turn its answers into work.

Five entries on what fast, generated text does to understanding, and where the expensive failures really sit.

The warning the method opens with.

MCM 001 Fifty Stories Before Lunch

The method opens with a warning: AI makes words cheap, but not understanding. In the book's example, one pasted paragraph yields fifty user stories, and by the next morning nobody can say what the system actually is. More text is not more clarity, and the tool cannot tell the difference.

Three problems that follow fast generation.

MCM 002 Three Problems With Fast Text

The method names three problems: volume without structure, plausible nonsense, and contradictions at scale, such as two documents using case for different ideas. Plausible nonsense is confabulation, taught in Generative AI at Work. One slow bottleneck has been traded for fast confusion.

The criteria everyone already knows.

MCM 003 The Familiar Criteria

The book lists the familiar criteria for good requirements: complete, consistent, unambiguous, verifiable, traceable and feasible. Published lists vary between guides, and all of them judge sentences, while the costliest failures sit underneath the sentences.

What sits underneath the sentences.

MCM 004 Material Problems, Not Wording Problems

The method's diagnosis is that the most expensive failures are disagreements about what the system is made of, dressed up as wording problems. One customer can exist as three unrelated records while every requirement about customers reads well. With AI, a material problem hides easily inside eloquent text.

What a model does with a vague domain.

MCM 005 Vague Domains, Invented Worlds

Given a vague description, a language model fills the gaps with general patterns, so it invents a domain that is typical rather than yours, perhaps treating an action as a task when yours is a signed decision. The less clear you are about your things, the more it quietly invents.

Six entries on material cause, why features sit on things, and what the method offers in return.

The idea the whole method rests on.

MCM 006 Material Cause, in One Line

Material cause is Aristotle's term for what something is made of; in a system, it means the records, documents, decisions and logs inside it. The method's pivot is to make material cause explicit and agree it in writing, because today it is everywhere and nowhere.

Why the things come first.

MCM 007 Features Are Things You Do to Things

In the method's view, every feature is something done to a thing. Creating a new incident is a screen that creates an Incident Report. You can list every feature and still not understand a system whose things are undefined.

What AI needs from you.

MCM 008 The Constraint AI Needs

Material cause gives AI a frame: these are the things, stay inside them, use these templates. A team teaches the tool its domain, then asks it to draft. The method says this makes you more precise, not the tool smarter, so the tool has something worth amplifying.

The method in five phases.

MCM 009 The Five Phases, Named

The method has five phases: context mapping, requirement cards, Object Packs, validation, and traceability. Each produces a working document, from a map of things to a traceability matrix. AI takes part in every phase, always inside frames people set.

When the method is worth it.

MCM 010 When It Matters

The book is plain that the method is overkill for a brochure site or a one-off form. It is designed for health care, public benefits, finance and safety work, where decisions rest on data and policy. The test is whether a mistake would reach a person.

The one reflex to keep.

MCM 011 The One Reflex

The method's one reflex is a question to ask whenever anyone proposes a requirement: which thing is this about, and what is that thing made of? In a planning meeting it can reveal that nobody has defined the record a feature changes. It works only if it is asked out loud, every time.

Seven entries on the habits and patterns that leave a system's things undefined, and what AI does to them.

The comfortable default.

MCM 012 Feature-First Thinking

Most projects start by asking which features they need, and skip what the system is made of. An incident system can list a form, a dashboard and reports without ever defining the Incident Report. The book calls this incomplete rather than wrong: fine at small scale, painful at larger scale.

When words do not match things.

MCM 013 Hidden Domain Fracture

Hidden domain fracture is groups using one word for different things. To sales a customer is the company that signs; to support, the person using the product; to billing, an account. A requirement to reopen a case assumes everyone agrees what a case is. They do not.

What to do with the old system.

MCM 014 Legacy: Gold Mine and Scar Tissue

A legacy system is both a gold mine of real data and years of accidental complexity, like a column doing three jobs. Copying it as a sacred relic and discarding it as a toxic mess both lose. The better question is which real things hide inside it.

What AI adds to the problem.

MCM 015 AI Amplifies the Material Problem

The method's verdict is that AI does not create the material problem; it amplifies it. A generated Eligibility Determination can look complete but leave out the policy version and snapshot auditors depend on. Reviewing fluent output without agreed definitions is proofreading a language nobody agreed on.

Reading any domain for its things.

MCM 016 Reading a Domain for Its Things

The book reads domains as collections of things, in four steps. Name the domain and its work. List the records the work cannot do without: for incidents, the Incident Report, Location, Action Plan and Audit Log Entry. Take each feature and say which things it creates, reads or changes. Then mark any thing nobody can describe in a sentence or two; that mark is where understanding is missing. The reading is most useful early, before features are built around undefined things.

Four patterns you may recognize.

MCM 017 Spotting the Four Anti-Patterns

The book names four anti-patterns. The giant specification, where answering what a case is means reading four sections. The backlog swamp, where one idea goes by case, file and record. The diagram the business never accepted, which the code then drifts from. And leaving it all for design, heard as "that's a design detail". Each looks like a process problem; underneath, all four are the same material problem.

What frameworks can and cannot fix.

MCM 018 Frameworks Govern Motion, Not Meaning

Delivery frameworks improve how work moves, but do not say what a system's things are. List what yours governs, such as cadence and roles. List what it leaves open, such as what a Case is or what a Determination must preserve. Check where those answers live today, and name the thing each open question concerns. The framework stays; the method adds the missing answers underneath. A team can run flawless sprints and still move ambiguity around faster.

Four entries on diagnosing your own system, and two worked examples. The opening question is answered here.

The six-question diagnostic.

MCM 019 Running the Six-Question Diagnostic

The book's diagnostic has six questions. List your five to ten most important things. Ask whether business, technology and compliance staff would agree. For each core thing, ask whether one place says what it is for, contains, and connects to. Ask whether a newcomer could be handed one trusted document. Ask whether a change has a clear path to everything that depends on it. And ask whether your AI tools get a stable model of your things. That answers this unit's question: systems end up misunderstood because nobody agreed what they are made of, and fast text does not fix that. Answers of no show where the problem sits.

From answers to work.

MCM 020 Turning Each "No" Into a Backlog Line

The book's exercise turns uncomfortable answers into a first backlog. For every no or it depends, write one sentence saying what it would take to answer yes. Name the thing each sentence concerns. Sort them by risk, money, safety and legal obligations first. Keep the list visible, because each line becomes work in a later phase: a missing definition becomes a Pack, an untraced change a matrix. A sentence that names no thing is still a wish.

The diagnostic on a small library.

MCM 021 A Library, Diagnosed

A worked example, constructed for this course, runs the diagnostic on a public library's loans system. The team lists Member, Item, Loan, Hold, Fine and Branch, then finds the desk counting a renewal as the same loan while reporting counts it as a new one. No single place says what a Loan is. Longer laptop loans had broken the overdue notices, and the chatbot answers fine questions from a general description. The team writes four backlog lines, each naming a thing. The library had no staff or software problem; it had no agreed account of what a Loan is.

One requirement, read two ways.

MCM 022 One Requirement, Two Readings

A second constructed example shows a clear, approved requirement, members may renew a loan twice, becoming two systems. Circulation extends the existing loan; reporting counts linked loans. A member renewing a laptop is allowed a third renewal at the desk, flagged by reporting, and sent an overdue notice for a loan the desk says does not exist. The fix was not a better sentence but a definition: a Loan runs from checkout to return, and a renewal changes its due date. The sentence passed every familiar criterion and still failed, because the disagreement was about the thing.

Look at what you can now do. You can explain why fast, generated text can leave a system less understood: it makes words cheap, not understanding. You can describe material cause, and why every feature is something done to a thing. You can recognize how teams leave things undefined: feature-first thinking, hidden fracture, the four anti-patterns, and frameworks that govern motion. And you can run the six-question diagnostic and turn each no into a backlog line that names a thing. Unit Two teaches the four causes.