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

This is Unit Eight of The M-CaReM-AI Method, part two, on using traceability matrices for AI, for every change, and on the library. Part one built the Determination's matrix and used it for a policy change and a new field. This part uses a matrix before an AI feature goes near a high-risk thing, sets the checklists for every change, and traces a real change through the library. Carry one question through this lecture: how far does a change to one important thing really reach? The answer arrives when the library walks loan periods through its matrix. By the end you will be able to use a matrix before introducing AI. To decide whether a thing needs a matrix and run the change-impact walk. And to build a matrix, trace a change and write the plan.

One entry that uses a matrix before an AI assistant touches incident reports.

Before AI drafts incident reports.

MCM 194 Scenario: AI in a High-Risk Area

The book's third scenario uses a matrix before introducing an assistant that drafts incident reports from clinicians' voice notes; Generative AI at Work practices the same case. Open the Incident Report's matrix. Identify the compliance-critical fields and the policies limiting automatic filling. Find the tests and review procedures that must grow. Then decide where AI may help, such as drafting the description, and where human review is mandatory, such as harm level and regulatory flags, and plan tests and monitoring. Traceability shows in advance which parts of a high-risk thing the tool must never decide.

Two entries with the Toolbox's checklists: when to create a matrix, and the walk for every change.

When a thing needs a matrix.

MCM 195 When to Create a Matrix

The Toolbox gives four criteria for a matrix. Does the thing affect legal compliance, safety or financial correctness? Does it appear in several systems or departments? Is it central to reports and measures? Has changing it caused surprises before? Two or three yes answers make it a Gold candidate with a matrix, whose rows and owner you then plan. The fourth question is often the most honest guide: a thing that has surprised the team before will surprise it again.

The walk for every change.

MCM 196 The Change-Impact Walk

The change-impact walk is the routine for every proposed change to a thing with a matrix. Name the things the change touches. Open each matrix. Walk the rows in order, asking the same questions: which cards, tables, interfaces, screens, reports, tests, procedures and AI tools assume the old behavior? Record each yes as a task. If no row is affected, check the matrix before believing it. The walk is deliberately repetitive: the same questions, every time, whoever is on duty.

Three constructed examples that build the library's matrix and trace one change through it. The opening question is answered here.

The library's matrix.

MCM 197 A Matrix for the Library Loan

A worked example, constructed for this course, builds a matrix for the library's Loan. Policy rows list the loan policy versions, the council's figures requirement and privacy rules. Card rows copy the Pack's index. The data row, from the systems administrator, lists the loans table, the kiosk interface, the overdue job and the council export. Screens, reports, the procedures manual, training and the members' chatbot follow, and an AI-suggested interlibrary form is removed. Building it exposed two gaps no other phase had: renewals had no tests, and the chatbot read loan rules nobody had told it about.

A change walked through.

MCM 198 Loan Periods by Item Type, Traced

A second constructed example walks a proposal, loan periods by item type, through the library's matrix. A new policy version is needed. Create Loan, Renew Loan and the overdue notice card change. The overdue job must read the item category, and the council export must still count the same way. The member's account page would show the wrong period. The monthly report needs a note. New tests are needed, and renewals finally get some. The manual, the training and the chatbot all change. That answers this lecture's question: a change to one core thing reached every row but two, while the part everyone remembered, the checkout calculation, was a small piece of it.

The change plan.

MCM 199 The Change Plan

A third constructed example turns the walk into a plan: publish the policy version, update the cards, change the overdue job and confirm the export, fix the account page, add tests, revise the manual and training, update the chatbot, and update the Pack and matrix, each with an owner. Compared with the plan, an AI tool's earlier impact list found the cards, the job and the notices, proposed one unnecessary table change, and missed the council export and the chatbot. The tool's list was a useful first draft; the matrix, walked by the people who own each row, decided what was true.

Look at what you can now do. You can use a matrix before an AI feature goes near a high-risk thing, and mark what the tool must never decide. You can decide whether a thing deserves a matrix with four questions, and run the change-impact walk on every change. And you can build a matrix with each row's owner, walk a real change through it, and write a plan that a tool's impact list can start but never finish. Unit Nine runs the whole method end to end.