Phase Three: Building Object Packs (part one of two)

This is Unit Six of The M-CaReM-AI Method, part one, on phase three: building Object Packs. Unit Five wrote cards: one behavior on one thing at a time. Cards pile up fast, and scattered cards recreate the chaos. This unit gathers everything about each thing into one place. Carry one question through this lecture: when a team already has cards, a map and a data model, what does a Pack add? The answer arrives with the book's ten steps, at the card index. By the end you will be able to explain what a Pack is for. To name its sections. To choose its level by what a mistake would cost. And to own, version and build one.

Four entries on the problem a Pack solves, and what a Pack is, and is not.

Four answers to one question.

MCM 126 Four Answers to One Question

The method's Pack chapter opens with an analyst asking what an Eligibility Determination is, and getting four answers: an old wiki paragraph, a six-field diagram, a table nobody can explain, and a senior caseworker's spoken answer, the best of the four. When she retires, the best answer leaves with her.

What a Pack is.

MCM 127 One Place per Thing

An Object Pack is a compact, living mini-specification: one place where a person or a tool can see what a thing is, how it behaves, where it is used and what is undecided. People ask what a Case is, not what a section number says.

Packs and AI.

MCM 128 The Right Size for a Prompt

The method calls a Pack the right size for a prompt: big enough to mean something, small enough to give a tool with a request, such as asking for test cases anchored on one thing. That is the method's own claim, also met in Course One.

A short manual.

MCM 129 A Short Manual, Not a Treatise

The mental model is a short manual for one thing, the kind you would hand a new teammate: purpose, fields, states, behaviors, where it appears, its rules, and what is unsettled. It is not a treatise, a schema or a screen specification; it bridges them.

Seven entries on the Pack's sections in three groups, and on Bronze, Silver and Gold.

Identity sections.

MCM 130 The Identity Sections

A Pack opens with three identity sections: the header, with name, type and zones; the purpose; and the definitions, with one to three agreed sentences, synonyms, and what is in and out of scope. Scope notes prevent quiet arguments about what counts.

Behavior sections.

MCM 131 The Behavior Sections

Four sections describe behavior: key properties with their meanings and rules, the lifecycle of states and transitions, the card index listing every card on the thing, and relationships. The card index makes gaps visible.

Use and governance sections.

MCM 132 The Use and Governance Sections

Five sections cover use and governance: where the thing appears, constraints and obligations, open questions, examples, and the steward with version and date. Constraints tie it to policy and law; open questions keep uncertainty visible. No Pack is ever done.

The lightest level.

MCM 133 Bronze

A Bronze Pack is for simple, low-risk, mostly technical things such as a notification preference. It holds a header, a sentence or two of purpose, a short definition, a field list and a small card index. Course One introduced the levels; this course covers what each contains.

The default level.

MCM 134 Silver

A Silver Pack is the standard level and the default for most core things. It adds key properties with meanings, a basic lifecycle, the full card index, relationships, and open questions and risks. Depth beyond Silver has to earn its cost.

The deepest level.

MCM 135 Gold

A Gold Pack is for audit-critical or legally sensitive things, and things central to money, safety or rights. It adds transition rules, legal and policy references, usage across screens and reports, detailed examples, and a link to the traceability matrix. Match the depth to what a mistake would cost.

Two rules about levels.

MCM 136 A Seed and a Floor

The method's two rules: a Bronze Pack is a seed, and Bronze is a floor, not a ceiling. A setting that turns out to stop payments grows to Silver or Gold. The book also warns against making everything Gold.

Three entries on who owns a Pack, how it is versioned, and what goes wrong.

The steward.

MCM 137 The Object Steward

The method names an Object Steward for each core thing, often a product owner or senior analyst, who approves changes to its Pack and keeps it true, working with policy and legal staff. Packs work only if someone owns them; an unowned Pack drifts.

Versions and logs.

MCM 138 Versions and Change Logs

Every Pack carries a version, a date and a short change log, and lives in one canonical place. For high-risk things, the method treats each Pack update as a small change request, reviewed with the right people.

Five pitfalls.

MCM 139 Five Pack Pitfalls

The book names five Pack pitfalls: monster Packs, screen detail inside the Pack, drift, AI designing things without review, and Packs too technical for business readers. Most come from treating the Pack as a dumping ground.

Four entries that build the Incident Report's Pack in the book's ten steps. The opening question is answered here.

Steps one to three.

MCM 140 Building a Pack: Header to Properties

The book's first three steps come mostly from earlier phases. The header and definition come from the inventory: a record of a safety event, kept so it can be investigated, tracked and reported, with synonyms and scope. The purpose is written in simple language. The properties are consolidated from the cards into groups, each with a meaning and its rules. List only properties that matter for decisions, reports and audits; the full schema belongs in a data dictionary.

Step four, the lifecycle.

MCM 141 Building a Pack: Lifecycle

Step four extracts states and transitions. The Incident Report's states run new, submitted, under review, closed and archived, with a return from under review to submitted when more information is needed. Each transition notes who may trigger it, what must be complete first, and what happens after. The book observes that writing the lifecycle often reveals cards nobody wrote, which go back to phase two.

Steps five to seven.

MCM 142 Building a Pack: Index, Links, Usage

Steps five to seven gather the card index, grouped by change type, the relationships in plain language, and usage across screens, interfaces and reports. That answers this lecture's question: a Pack adds the one place where cards, links and uses meet, so gaps like a missing archive card show up, and everyone who depends on the thing knows they are affected when it changes.

Steps eight to ten.

MCM 143 Building a Pack: Obligations, Questions, Examples

The last steps tie the Pack to policy, record what is undecided, and add an example. Obligations say which policies require the thing, how long it is kept, and who may see it. Open questions include whether a near miss is its own thing, and whether reporters may edit after submitting. An example shows a nurse reporting a fall. The questions need a home, not answers yet; examples help testers, newcomers and AI tools.

Look at what you can now do. You can explain what an Object Pack is: one place per thing, sized for a prompt, a short manual rather than a treatise. You can name its sections in three groups: identity, behavior, and use and governance. You can choose Bronze, Silver or Gold by what a mistake would cost, remembering the seed and the floor. And you can name a steward, keep a change log, and build a Pack in the book's ten steps. Part two uses AI to draft and maintain Packs, and builds the library's.