How to read this book

Five parts, and they compose in a particular order. Part 1 sets the frame — why code got cheap, and the two theses everything rests on. The next two parts work one thesis each: Part 2 develops the Alignment Thesis as the controls that govern a fleet — lints, gates, the agent stack, the graph that catches guardrails colliding; Part 3 develops the Modeling Thesis as the executable, drift-gated models the fleet reasons through. Part 4 puts both to work as daily practice, and Part 5 is the grounding case: DocAble end to end, the real system the claims rest on. The Theory of MAGE, the closing implications and conclusion, and the appendices follow. Figure 0.4-1 shows the whole path and the routes through it.

Read it straight through and the argument builds in order. But there are faster ways in. If you want to do this on Monday, read Part 1, then jump to Part 4 and dip back into Parts 2–3 when a technique needs its foundation. If you want to be convinced first, read Part 1, then Part 5 (watch the method survive a real production system), and come back for the how. And the appendices are a reference, not chapters: consult a pattern when you meet its failure, the way you would the Gang of Four.

Two ways to read this book

Read the book once, front to back, and you learn the method. Return to it while you build, and it works a second way.

• The first pass is sequential. Each part rests on the one before it, from the two theses through the method and into the DocAble case, then out through the back matter — the Theory of MAGE, its implications, and the conclusion — that closes the argument. Read in order and it arrives assembled.
• Every pass after that is not. Once you are standing up a governed environment of your own, the book turns into a reference you open at the page you need. The appendices carry that second mode. They reward repeated consultation, not a straight read, and most readers will reach for them long after they have set the chapters down.

The appendices are the reference interface to MAGE once you have the method. Treat them as part of the book's working surface, not as back matter tacked on behind it.

What each appendix is for

Five appendices, each with its own job. The first three form a reference triad you work in sequence; you reach for a different one depending on what you are asking.

• Appendix A — MAGE Engineering Stacks. Reusable engineering architectures: the clusters of mechanisms that travel together to stand up one capability, with the mandatory members marked off from the ones you can leave out. Reach here when the question is "How should I build this capability?"
• Appendix B — Flagship Mechanisms. The engineering judgment behind the mechanisms that carry the most weight — the failure each one kills, the shape that kills it, the alternatives it replaces, and the seam where you wire it in. Reach here when the question is "Why is this the right decision?"
• Appendix C — Mechanism Catalog. The whole vocabulary at a glance: every mechanism as a compact brick with its figure, a short summary, and its metadata, each linking on to its fuller treatment. Reach here when the question is "What is this mechanism again?"

The last two appendices stand apart from that triad, each answering a question the build sequence does not raise.

• Appendix D — Operator's Reference. The operator's dashboard: the metrics that steer the work while it is in flight and the verdicts that certify the system at maturity, each with what it counts, when to read it, and the direction that reads as healthy. Reach here when the question is "What should I watch while running the system?"
• Appendix E — How to Write a Skill. A build recipe, not a reference layer: the step-by-step for packaging a body of judgment into a skill an agent can reach for.

Working the appendices together

The three reference appendices are strongest read in sequence, from the capability you want down to the detail you need to ship it.

• Start with the capability. Appendix A names the stack that delivers it and the mechanisms that compose it.
• Study the judgment. Appendix B explains why each load-carrying mechanism takes the shape it does.
• Keep the map open while you implement. Appendix C gives the quick recognition and the jump to a deeper entry.
• Go to the online catalogue for the complete documentation when print runs out of room.

Read in that order, the appendices reinforce one another rather than repeat. Each answers a question the one before it raised.

The book and the online catalogue

The book and the online catalogue divide the work.

• The book teaches the method and the engineering judgment behind MAGE — why the mechanisms take the shapes they do, and how they compose.
• The online catalogue is the complete reference for the mechanism library — every mechanism as a full Gang-of-Four entry, with implementation guidance, examples, and the detail that does not fit in print.

Come to the book to understand the ideas. Go to the online catalogue when you need the exhaustive record of one mechanism.

Where to look

Table 0.4-1 lays the surfaces side by side — each with the job it does and the question that sends you to it, from the main text through the five appendices to the online catalogue.

The Theory of MAGE — the causal account of why the method follows from cheap code — lives in the main text, near the end just before the implications, not in the appendices. It belongs to the argument, so it reads in sequence with the chapters that earn it.