Failure reveals where to look. Where to look, not what caused it.
You finish Movement II with a page of observations, and the temptation is already forming. One row on that page looks thin, and before the ink is dry you are drafting a program to fix it. Hold on. What Chapters 10 through 14 gave you is not five formal grades. It is five bounded observations, each one a single inspection of one workflow or, for direction, one recorded decision. That is enough to point somewhere. It is not enough to launch anything, and the whole discipline of this chapter is the distance between those two claims.
Start with what the framework does and does not tell you, because the boundary matters before the reveal. These five questions inspect whether your company's work can be inherited: whether direction decides, whether the number holds one meaning, whether the process survives absence, whether people can carry a change, whether the deployment can be operated and checked by someone other than its builder. That is inheritability, and it is worth knowing. It is also not correctness. A workflow can pass every one of these and still be aimed at the wrong objective, and no row on your page will tell you so. The framework reveals where knowledge is trapped. It does not, on its own, certify that the trapped knowledge was right.
The instinct that produced the program is the one to disarm. Somewhere in the last decade the maturity score won, and companies learned to measure themselves on a rising line: level two this year, level three next, a chart that climbs. The trouble is what the climb can conceal. A maturity score can rise on the strength of a better description while the operating artifact underneath it stays exactly where it was. You can move from level two to level three by writing a cleaner account of what you already do. An operating artifact is harder to move that way. Either the refusal ledger has an entry with a clause attached, or it does not. Either the number's three definitions match, or they sit on the page disagreeing. A score rewards how well the work is presented; an artifact shows what can be handed to someone else. This chapter cares about the second, and it promises you a smaller, harder thing than a maturity level: one evidenced constraint, one next artifact, one authorized owner, and one date.
Assemble the page properly. Lay the five questions in a column and give each row more than a verdict, because a verdict is where overreach begins. Each row carries the full schema: the question, the evidence state, the artifact you actually collected, what you observed in it, how confident you are, the rival explanation you have not ruled out, the next artifact that would raise your confidence, the authorized owner role who would produce it, and the date. A row that says Vision, weak is a slogan. A row that names its state, artifact, observation, confidence, unresolved rival explanation, and the next artifact that would settle it, owned by a role on a date, is a finding you can act on without embarrassing yourself. Two of your rows may not carry an ordinary state at all. No reading means the authorized evidence could not support one. No deployment means no relevant AI touches this workflow. A confirmed missing artifact is different again: not No reading, but a finding, because you established that the artifact should exist and does not. Write each one down plainly. None of the three is a zero, and a company that grades a No reading as a failure is inventing a weakness so it has something to fix.
Now discipline the title of this chapter, because it can be misread as a promise. Failure reveals where to look. Where to look, not what caused it. A thin row is an investigation target. It is not automatically the cause of anything, and four honest possibilities stand between the row and that conclusion. The conditions may interact, so a data problem and a process problem produce one symptom that belongs to neither alone. The weak-looking condition may be an effect rather than a cause, downstream of something you did not inspect. The real driver may sit outside the framework entirely, in capital, regulation, timing, or a market that moved. Or the evidence may simply be missing, in which case the honest output is collection, not diagnosis. The lowest row on your page earned your attention. It did not earn your budget.
An illustrative filled page looks like this, and you should read it as a demonstration of the method, not an assessment of any company. I will run it on the disputed-renewal workflow this book has carried. The states are constructed only to demonstrate the selection rule. They report no real company, number, or customer outcome.
Label it plainly: Illustrative Company Card, not a company assessment. A customer disputes a service renewal, says they tried to cancel, and asks for a refund, and the request moves through support, an approval owner, and billing. Every row carries the same fields: condition, state, evidence artifact, observation, confidence, rival explanation, next artifact, owner role, and date.
Vision. State: Works in this schematic. Condition: whether direction can decide the exception. Evidence artifact: one authorization or refusal record for the exception boundary. Observation: whether that boundary is written, so support may draft and retrieve policy but may not decide the fairness exception itself. Confidence: as supported by the single record. Rival explanation: a written boundary may reflect legal review, not working direction. Next artifact: a second recorded decision against the same clause, owned by [authorized role] on [date].
Data. State: Works in this schematic. Condition: whether the number holds one meaning. Evidence artifact: the definition and lineage record for cancellation attempted and refund approved. Observation: whether those phrases carry consistent definitions across support, billing, and the system of record. Confidence: as supported by the definitions collected. Rival explanation: an apparent match may conceal a difference in how each function applies the definition. Next artifact: reconciled written definitions from each function, owned by [authorized role] on [date].
Process. State: Wobbles in this schematic. Condition: whether the flow survives absence. Evidence artifact: the two-sided support-to-approval-to-billing handoff record. Observation: it surfaces an exception that lives in no document. Confidence: low, because one unrecorded exception has been seen once and requires confirmation before it is treated as a pattern. Rival explanation: the exception may be rare or already scheduled for documentation. Next artifact: a confirming second run of the handoff, owned by [authorized role] on [date].
Human Experience. State: Works in this schematic. Condition: whether people can carry and correct a change. Evidence artifact: one announced change to the refund or escalation rule, followed through modification, escalation, and operating arrival. Observation: the objection, decision, and landing chain can be evidenced end to end. Confidence: as supported by the records found. Rival explanation: one complete chain may be exceptional rather than representative. Next artifact: the decision record for a second modification or escalation, owned by [authorized role] on [date].
AI. State: Works in this schematic. Condition: whether the deployment can be operated and checked by someone other than its builder. Evidence artifact: the boundary record between what a deployment may retrieve or draft and what it may not decide. Observation: the boundary is written and a qualified operator other than the builder can confirm a run. Confidence: as supported by the verification evidence. Rival explanation: one confirmed run may conceal weak coverage of less common cases. Next artifact: one post-handover run containing a documented exception and confirmed by an independent reviewer, owned by [authorized role] on [date].
The whole page refuses a great deal, and the refusals are the point. It assigns no grade, claims no cause, reports no customer outcome, and invents no metric. From all of it, the schematic selects exactly one move: a second, confirming run of the Process handoff, owned by [authorized process owner role] on [date]. One concern, seen once, gets looked at again before anyone spends on it. No company-wide diagnosis follows, no program, no personnel consequence, and no result I made up to make the method look decisive.
That single confirming run is the entire ethic of this chapter, and it sets up the reveal the book has been withholding.
There are two cards, not one. The page you just filled in is the Company Card, and its question is whether the organization can inherit its work: can another person or system restart, check, and improve what currently runs. The second card is the Blank Collar Card, and it asks a different question of a different subject. What repeatable work did I make inheritable, and what responsibility did I grow into afterward.
The organization must inherit the work. The person must outgrow it.
That sentence is the whole relationship between the two cards, and the cards diverge exactly where it does. The Company Card wants the work to become inheritable, because an organization is stronger when its knowledge does not walk out the door in one person's head. The Blank Collar Card wants the same transfer to happen, and then asks the person to do the thing the company cannot do for them: take responsibility for the problem the inherited system cannot yet settle.
I will only show you the face of the personal card here, because Chapter 18 owns it in full and I am not going to teach it badly in a paragraph. Its face carries four fields: the transferred work, the responsibility assumed, the evidence of growth, and the next problem owned. Behind those four fields, Chapter 18 will ask you for five specific pieces of evidence, because a field you cannot evidence is a claim. Read the fields in order and the logic is plain. You made something repeatable and handed it off. You took on something the handoff exposed. You can point to how that changed what you do. And you have named the next problem the procedure cannot answer. The two cards belong to the same Blank Collar framework, but they run on different evidence and answer different questions, and only the Company Card uses the organizational inspection procedure you just practiced. What the personal card must never reward is the opposite move, the one that feels safe and functions as a slow countdown: making yourself hard to replace by keeping the work trapped. That is the hoarder's card, and it is not this one.
This is the line that governs Monday, now that the reveal is done.
A confirmed concern names a constraint to investigate. The dependency order names Monday.
The dependency order is a practical heuristic, and I want it stated as one, because I have seen it hardened into law and used to justify sequencing that did not fit the case. As a rule of thumb: direction work may proceed in parallel with the rest. Human Experience can constrain whether people are able to supply what they know safely, and where it does, the readings that depend on their candor wait until that is cleared. Process should be observed before it is automated. Data feeding a workflow should be repaired before that workflow is automated, because automation can carry an unresolved error into more places before it is noticed. And a verified deployment defect, in permissions, routing, evaluation, fallback, transfer, cost, or oversight, can be acted on directly, because those are managerial choices with names attached. Treat the order as a heuristic that yields to the evidence and the case in front of you.
Two rules sit above the heuristic and override it. The first is confirmation: one specimen can expose a concern and cannot support consequential spending, so a single thin row gets a second run, like the schematic's, before it gets a budget. The second is the stop gate, and it comes before prioritization, not after. If your inspection turned up verified harm, illegality, a safety risk, or a protected-employee impact, you contain it and route it through the authorized review process now. A framework score must never be used to make harm look handled, and a finding of that kind is not a row to prioritize against the others. It is a stop.
That leaves the five programs this chapter exists to refuse, because they are where good evidence goes to die. A weak Vision row becomes a new vision statement. A weak Data row becomes a data-lake program. A thin Process row becomes a documentation initiative. A quiet Human Experience row becomes a listening exercise. A confirmed AI deployment defect becomes an AI-improvement plan. Refuse all five together, for one shared reason: each can convert a specific finding into a standing workstream, and a standing workstream can preserve visible activity while the artifact you inspected stays exactly as you found it. That is Chapter 7's immune system wearing a project charter.
Replace the workstream with something you can hold in one hand.
One named artifact, one named owner, one date.
Named owner means a named authorized role, not a person you drafted into a story. The artifact is the specific thing that would raise your confidence in the one constrained finding: a second handoff run, a reconciled definition, a traced second decision. The owner is the role with the authority to produce it. The date is when. That is the entire next move, and it is deliberately too small to hide in.
Make it reciprocal, because the transfer this chapter keeps asking for has a person on the other end of it. When the knowledge in someone's head becomes the artifact on your page, that person supplied the thing that makes your company more inheritable, and the exchange cannot be extraction. Credit for the definition they clarified, safety in having surfaced the exception they were quietly handling, and a credible path toward the responsibility the newly legible work opens up. A company that takes the knowledge and forgets the person teaches everyone watching to hold the next exception a little tighter.
You leave this chapter with two things unfinished, and that is correct. The Company Card leaves you with one constrained investigation, owned and dated, and nothing larger. The Blank Collar Card leaves the human question open, because it is not answerable by an inspection: it is answerable only by what you do next with the room a transfer creates, and that is Chapter 18's work, not this page's.
There is one more distinction the next chapter has to draw, and this page has been setting it up all along. Everything you inspected assumed the old workflow, with AI inserted into it: the same handoffs, the same roles, a machine drafting where a person used to draft. That is substitution, and it is the smaller of the two moves available to you. The larger move is to redesign the work itself, to ask which handoffs should exist at all, where responsibility should sit once a machine carries the routine, and what the human role becomes when the repeatable part is inherited. Substitution changes a step. Redesign changes the work. Chapter 16 is about the difference, and why so many companies pay for the first while believing they bought the second.