Phase Two: Writing Material Requirement Cards (part one of two)

This is Unit Five of The M-CaReM-AI Method, part one, on phase two: writing Material Requirement Cards. Unit Four named the things in a world and drew them on a map. This unit describes what is done to them, one card at a time. Carry one question through this lecture: why does a requirement that everyone signed still produce three different systems? The answer arrives with a first set of cards for an Eligibility Determination. By the end you will be able to explain why a card replaces a sentence. To name a card's sections. To size cards correctly. And to read a worked card and draft a first set for a thing.

Three entries on why a requirement sentence fails, and what a card does instead.

A requirement everyone signed.

MCM 101 All Relevant Information

The method's cards chapter opens with a requirement everyone signed: managers shall see all relevant information about an incident. In the book's example, launch day brings three complaints: no harm level, no follow-up actions, and a nurse seeing a patient's full name. A requirement that names no thing, fields or rules means something different to every reader.

What a card says.

MCM 102 From Sentences to Cards

A Material Requirement Card wraps a requirement in a fixed structure: which thing, what change, which fields and rules, and why it matters. Submit an incident becomes a card naming the Incident Report, a create change, its fields and its rules. The sentence says something should exist; the card says what, and how.

The book's comparison.

MCM 103 Atoms and a Molecule

The book compares loose requirement sentences to atoms, and a card to a molecule that binds them. Designers, testers, policy staff and AI tools can all work from one card, because its parts are always in the same places.

Four entries on a card's anatomy: what it must always contain, and what it may.

Three sections never dropped.

MCM 104 Three Required Sections

The method lets cards be simplified or extended, but three sections are never dropped: the material focus, naming the primary thing and related things; the change type; and the material properties, the fields involved. A card missing any of the three cannot say what changes.

The header and the statement.

MCM 105 Header and Business Statement

Every card has a header with an identifier and an action title, such as Create Incident Report, and a short business statement saying why it exists and who cares if it fails. The method asks for plain language, so policy owners recognize their own world.

Constraints and rules.

MCM 106 Constraints and Rules

The constraints section holds validation, business rules, timing rules and permissions: for an incident report, a time that cannot be in the future, harm level required when a patient was involved, and a twenty-four hour window. A tester should be able to write test cases straight from it.

The optional sections.

MCM 107 The Optional Sections

The Second Edition's card adds five optional sections: preconditions and triggers, outcomes, location and technology, traceability, and examples. Outcomes say what is true afterward; traceability links the card to its policy, Pack and matrix. The book calls examples optional but powerful.

Seven entries on how big a card should be, the change types, what goes wrong, and why cards matter.

One behavior per card.

MCM 108 One Behavior per Card

The sizing rule is one coherent change to things per card. Create Incident Report is good scope; manage incidents is poor scope. If a card describes several screens, stages or changes at different times, it is more than one card.

One primary thing.

MCM 109 One Primary Thing per Card

Every card has one primary thing; others may appear as related. Linking a Case to an Appeal Case becomes two cards in the book, one from each thing's side. If you cannot choose a primary thing, you probably have two requirements.

The change types.

MCM 110 Create, Read, Update, Delete, and Three More

The method's change types extend create, read, update and delete with archive, generate and log: retention, documents made from a thing, and audit entries. The book asks for an archive or delete card even when the answer is that deletion is forbidden.

Where AI goes wrong.

MCM 111 Where AI Goes Wrong With Cards

The method names three common AI errors in cards: invented fields, missing audit fields, and flattened concepts, such as merging the Case and the Application. A drafted Determination card often omits the policy version and snapshot. AI suggests; you decide.

Cards in any team.

MCM 112 Cards in Any Delivery Method

Cards fit agile, traditional and hybrid teams without changing how they deliver. An agile story points its acceptance criteria at a card; a traditional specification gives each card a numbered subsection under its thing. In large organizations, cards become stable reference points.

Four pitfalls.

MCM 113 Four Card Pitfalls

The book names four pitfalls: behavior without things, cards as mini-specifications, several steps on one card, and letting AI drive scope. Create the report, notify the team and start the workflow is three cards. AI output is a menu, not a mandate.

Why cards are the hinge.

MCM 114 Cards Are the Hinge

The book calls cards the hinge of the method: phase one finds things, cards express behavior on them, Packs gather them, validation checks them, and traceability anchors on them. For AI, cards are the ideal unit, because their structure is fixed.

Four entries that work cards through: the book's example card, change-type slicing, and a first set. The opening question is answered here.

The book's worked card, first half.

MCM 115 A Worked Card: Focus and Properties

The book's worked card is Create Incident Report, with illustrative details. Its business statement says staff must record safety events so quality, risk and regulatory staff can act. Its focus is the Incident Report, with the patient reference, location and type as related things. Its change is create. Its properties are grouped: reporter, event, patient and metadata. Grouping is what makes a long field list readable and tells designers where each field belongs.

The worked card, second half.

MCM 116 A Worked Card: Rules and Example

The second half of the worked card holds the rules: validation such as no future incident times and active locations; conditional rules making patient reference and harm level required when a patient was involved; permissions and timing, with harm incidents entered more than a day late flagged; the web form and its traceability links; and an example of a nurse reporting a fall. One card is not a specification, but it carries enough to guide design, tests and an AI tool.

Finding every card for a thing.

MCM 117 Thinking in Change-Type Slices

The method finds a thing's cards by slicing it through each change type. Ask what creating one means and who may. Ask how people view and search it. Ask which updates matter, each with its own card. Ask when it may be archived or deleted, even if never. Ask what is generated from it, and how changes are logged. A missing answer becomes a visible gap, such as no archive card. Without the slices, teams miss the behaviors that only matter in an audit.

A first set for a Determination.

MCM 118 A First Set for the Determination

The book writes a first set for an Eligibility Determination in four steps. List the behaviors: create, view, correct, generate the notice, log and supersede. Write business statements, such as recording each outcome so decisions are transparent. List properties, including the policy version and case snapshot. Write rules: an allowed status list, the policy version in effect on the effective date, a justified denial, and authorized roles. That answers this lecture's question: a signed sentence produces three systems because nothing in it names the thing, fields and rules; a card does, and the policy version and snapshot it names are exactly what auditors later ask for.

Look at what you can now do. You can explain why a card replaces a sentence: it names the thing, the change, the fields and the rules. You can name a card's three required sections and its optional ones. You can size cards to one behavior and one primary thing, and slice a thing through its change types. And you can read a worked card and draft a first set for a thing. Part two drafts cards with AI, checks them, and writes the library's.