Phase Five: Tracing What Depends on What (part one of two)

This is Unit Eight of The M-CaReM-AI Method, part one, on phase five: tracing what depends on what. Unit Seven confirmed each thing with the people who live with it. Things still change: laws, policies and priorities move. This unit maps everything that hangs off a high-risk thing, so a change does not break what nobody remembered. Carry one question through this lecture: when one rule changes, how does a team avoid fixing only the parts it remembers? The answer arrives with the book's policy-change scenario. By the end you will be able to explain material traceability. To describe a matrix and which things deserve one. To use AI on matrices safely. And to build a matrix and use it for a change.

Four entries on what hangs off a thing, and why tracing documents falls short.

One rule, eleven surprises.

MCM 176 One Rule, Eleven Surprises

The method's traceability chapter opens with a benefits agency updating one income rule on time. In the book's example, eleven surprises follow: old limits in letters, a report counting the old way, a stale job aid, tests passing on the old rule. The danger is the parts you forget are connected.

The question phase five answers.

MCM 177 What Hangs Off a Thing

Phase five asks how a team knows what else must change when something changes. Hanging off any important thing are policies, cards, data, interfaces, screens, reports, tests, documentation and training. Material traceability traces outward from a thing to all of it.

Tracing as most teams know it.

MCM 178 Document-Centric Traceability

Most organizations trace requirement numbers to design documents to test cases, often in a spreadsheet kept for audits. A row like that says nothing about which reports read the same field. The method calls this document-centric: it cannot show how a change to one thing cascades.

Proving versus deciding.

MCM 179 Proving Versus Deciding

Traditional tracing helps prove something afterward, but rarely helps decide safely in the moment. Systems engineering guidance states the same purpose: traceability assesses the impact of changes. The method's addition is where tracing starts: from the thing, not the document.

Three entries on the traceability matrix and which things deserve one.

Which things get a matrix.

MCM 180 One Matrix per High-Risk Thing

The method's main tool is the Material Traceability Matrix, one per high-value or high-risk thing. Most teams build them for Gold things, perhaps a few Silver ones, and none for low-risk things. The book warns that tracing everything means drowning.

The rows.

MCM 181 The Rows of a Matrix

A matrix has rows for policies and rules, cards, data and integration, screens, reports, testing, operations, and AI and automation. Each row lists the items that depend on the thing, such as the policy that defines it or the test suite that checks it.

A living map.

MCM 182 One Thing, Several Perspectives

The book sums a matrix up as one thing seen from several perspectives: everything you would check if that thing changed. As reports and tests are added, the rows change while the matrix stays centered on the thing. A matrix never updated describes a system that no longer exists.

Five entries on AI's role in tracing, how matrices fit any team, and what goes wrong.

AI as a scout.

MCM 183 AI as Impact Scout

The method uses AI to draft matrices and suggest which entries a change may affect. Given a matrix and a change request, a tool lists the cards, fields, reports and tests it expects to need attention. The book is firm: that is where impact analysis starts, never where it ends.

Fabricated links.

MCM 184 Fabricated Links

AI can confidently link items that do not depend on the thing, such as every document mentioning eligible, including other programs. The book's rule is to tag AI-suggested links until a person confirms them, because a fabricated link is worse than a missing one: it looks checked.

Matrices in any team.

MCM 185 Matrices in Any Delivery Method

Matrices fit agile, traditional and hybrid teams. An agile team adds a definition-of-done line to update the Pack and matrix for any story touching a Gold thing; a change board requires requests to cite matrices. In large organizations, they become the shared document across teams.

Five pitfalls.

MCM 186 Five Traceability Pitfalls

The book names five pitfalls: tracing everything, static compliance documents, matrices too technical to read, AI-fabricated links, and overcomplicated formats. Put policy and procedure rows at the top in plain words. A matrix touched only before audits will not help with real change.

When nothing is triggered.

MCM 187 When Nothing Is Triggered

The book's sharpest test of a matrix: if changing an important thing triggers nothing in any row, either the change is truly isolated or, more often, the matrix is incomplete. An empty impact list for a core thing is a reason to look harder, not to relax.

Six entries that build the Determination's matrix and use it for two changes. The opening question is answered here.

Starting from the Pack.

MCM 188 Building a Matrix: Pack and Rows

The book's first steps build on work already done. Start from the thing's Pack, which holds its definition, lifecycle, card index, relationships and policy references. Choose the rows, dropping any that do not apply and adding others such as external partners. Record the thing, the owner and the date, and keep the matrix beside the Pack. Starting from the Pack keeps the matrix centered on the thing; a matrix started from a document list becomes another document map.

Policies and cards.

MCM 189 Building a Matrix: Policies and Cards

The next rows a team can fill itself. Policies and rules come from manuals, legal references and guidelines; for the Determination, the book lists an illustrative eligibility manual, statute and appeals rule. Link to the canonical sources rather than quoting laws. Copy the cards from the Pack's index, optionally with priority and risk. The policy row is the one auditors read first, and the one technical tracing most often leaves out.

The rows that need other people.

MCM 190 Building a Matrix: Data to AI

The remaining rows need other people. Ask data staff which tables, interfaces and downstream jobs use the thing. List the screens where it is created, edited and viewed. List the reports. Ask testers which suites cover it. Ask operations and training staff which procedures and courses refer to it. List any AI models or prompts that use it. Each row has an owner who knows what the analyst does not; building the matrix is a series of short conversations.

The finished draft.

MCM 191 The Determination Matrix

The book's assembled matrix for the Eligibility Determination, all names illustrative, has policy rows for the manual, statute and appeals rule; its cards; tables, an interface and a warehouse table; a decision screen and an audit view; outcome and appeal reports; notice and regression tests; standard and appeals procedures and training; and a justification prompt and a risk-scoring model. The book's standard for a first matrix is useful, not perfect.

A policy change.

MCM 192 Scenario: a Policy Change

The book's first scenario: a law changes eligibility rules. Identify the affected things, the Determination certainly, perhaps the Case Snapshot, Income Record and Notice. Open the Determination's matrix. Run an impact workshop row by row: which cards, tables, screens, reports, tests and procedures assume the old rule? Then produce a change plan. That answers this lecture's question: without the matrix, a team tests where it remembers the logic lives; with it, the team follows a map that lists the parts it would have forgotten.

A new field.

MCM 193 Scenario: a New Field

The book's second scenario adds a language preference to a Customer Account. Open its matrix and scan for the communication cards, customer tables, interfaces, edit screens, demographic reports and personalizing AI prompts. Decide where the field belongs, where it must appear, which reports include it, and which tests change. Then update the Pack and the matrix. The matrix does not make the design decisions; it makes sure nothing is forgotten while you make them.

Look at what you can now do. You can explain material traceability: tracing outward from a thing to everything that depends on it, to decide safely, not only to prove afterward. You can describe a matrix's rows, and give one only to high-risk things. You can use AI as an impact scout, tag its links until confirmed, and look harder when nothing is triggered. And you can build a matrix from a Pack and use it for a policy change and a new field. Part two covers AI scenarios, the checklists and the library.