Appendices

#Appendix A — The Field Guide

One page per idea: what to ask, and what to watch for. Photocopy it, pin it up, take it into meetings.

#Model — Every good regulator must be a model of the system (Chapter 2)

Ask: What does this governing layer believe about the work? What does it pay attention to? When did that picture last change, and what has changed in the work since?

Warning signs: a dashboard that has been green for months while the work changed underneath it; processes nobody can explain the purpose of; a regulator that reacts only after the error, never to its cause.

#Legibility — To govern it, you simplify it; what you leave out, you destroy (Chapter 1)

Ask: What does this layer make visible? What does it make invisible? Where are the backchannels, workarounds and shadow spreadsheets?

Warning signs: a measure being optimised more than the thing it measures; important work that appears on no plan; standardisation that removed local variation nobody had examined.

#Remainder — Automation takes the easy part and leaves the hard part (Chapter 10)

Ask: What is left for people once this is automated? When did they last do the automated work by hand? Could they take over tomorrow?

Warning signs: reviews getting faster and approving more; nobody able to explain what the automation actually does; a system that never fails loudly; junior staff who have only ever supervised.

#Stop — Who may halt the work, and what happens to them (Chapter 12)

Ask: Who can stop this, how fast, at what cost to themselves, and what happens to them afterwards? Who learns from it?

Warning signs: problems reported through slow, costly channels; stops used only by senior staff; people who raised concerns being questioned rather than thanked.

#Jump — Every new layer must itself be governed (Chapter 3)

Ask: What layers have we added recently? Who governs each one? Can any of them change the checks that govern them?

Warning signs: output growing faster than anyone’s understanding of it; a new layer run with habits designed for the one below; a self-improving system that can reach its own instruments.

#And from Stafford Beer (Chapter 4)

Ask: Who does each of the five jobs — the work, coordination, today, the future, identity? Which job has no owner?

#Appendix B — Myth vs Record

Every claim in this book that turned out, on checking the primary source, to differ from the version that circulates.

#Appendix C — The Regulator’s Rules

The rules from the end of each chapter, collected word for word. Sixty-odd sentences; if you keep only one page of this book, keep this one.

1. The Forest That Died

1. Every governing layer sees a simplified picture. Know what yours leaves out.
2. What the governing layer cannot see, it will eventually manage out of existence.
3. Protect the backchannel. It is often the load-bearing wall.
4. Never mistake the standard tree for the forest.

2. Every Good Regulator

1. A dashboard is a model of the work, not the work.
2. A regulator that isn’t a model of the system is carrying complexity that buys nothing.
3. Regulate the cause, not the error, wherever you can.
4. A system that changes needs a model that changes at the same speed.

3. The Jump

1. Every jump creates a new layer that must be governed.
2. Automate a level only as far as you can cheaply and reliably check it.
3. A layer that can edit its own instruments will learn to.
4. In a factory with an unpredictable machine, the factory is only as good as its sensors.

4. The Viable System

1. Every viable organisation does five jobs: work, coordination, today, the future, and identity.
2. Use the model to find the missing job, not to redraw the org chart.
3. Only variety can absorb variety. A small centre must either reduce what reaches it or amplify what it can handle.
4. Send the worst news around the hierarchy, not through it.
5. When you install a new metasystem, switch the old one off.

5. Compliant and Fatal

1. Every measure is a model. Every model can be optimised instead of the thing it models.
2. Never let the governed be the only source of evidence that they meet the standard.
3. Don’t rank people on results the system produces.
4. Track trends; distrust targets.
5. If one number decides rewards, that number will stop meaning anything.

6. The Fee for Bug Reports

1. A governing system must measure its effect on the work, not just its own activity.
2. Any cost to reporting a problem reduces the reports, not the problems.
3. A shadow system is a map of where the official one is wrong.
4. An alert that is usually wrong teaches people to ignore the one that is right.
5. Fund the watcher, or it will go blind first.

7. The Presumption

1. No governing system should be presumed correct in a way that removes the means to challenge it.
2. The people a system can harm must have access to the evidence about it.
3. When many people independently report the same kind of error, the reports are data about the system, not about the people.

8. Running Broken

1. Complex systems are always partly broken. Design as if they are.
2. Look for the combination, not the root cause.
3. Treat what your own systems generate as carefully as input from strangers.
4. Loosen the coupling: build kill switches before you need them.
5. Past success is not evidence of safety.

9. The Model You Copied

1. A governing model is a model of one organisation at one moment.
2. Copy principles, not org charts.
3. Copy the practice underneath, not the tool on top.
4. Adapt, don’t adopt — and keep adapting.
5. The part that made it work is usually the part you can’t see.

10. The Ironies of Automation

1. The most reliable automation needs the most practised humans.
2. If a person must check the machine, the machine must work at a pace that person can follow.
3. Automation should fail obviously — never quietly compensate until it is too late.
4. Nobody can watch a quiet screen for long. Design as if they are not watching.

11. Specify or Explain

1. Tell the machine what must be true — and why.
2. Write down your assumptions; they are the first thing to be lost.
3. Keep some checks where the checked cannot reach them.
4. Invite disagreement, or you will never learn your model is wrong.
5. When a mistake recurs, fix the controls, not just the output.

12. Who May Stop the Line

1. A signal asks for permission. A stop takes responsibility.
2. Pre-agree the stop, so nobody has to win an argument in the middle of a crisis.
3. Whoever may stop the line decides what the line really produces.
4. If raising a problem costs the person who raises it, you will hear about fewer problems — not have fewer.
5. A cord nobody feels safe to pull is a decoration.

13. Grow It, Don’t Design It

1. Grow governing layers from small ones that work.
2. Registration is not adoption. Shipped is not adopted.
3. Make the supported path the easiest path, and let people leave it — leaving is feedback.
4. Retire the old generation, or the new one will never win.
5. Budget for maintaining the path, not just paving it.
6. Before adding a mandate, look for a higher rung.

14. The Organisation’s Operating System

1. Removing managers does not remove the jobs managers did. Give each job an owner.
2. Where there is no formal hierarchy, look for the informal one.
3. Good intentions fade. Mechanisms, with owners, persist.
4. Every system that affects people needs a person who is accountable for it.
5. When governing the work becomes the work, stop and count.

15. Your Own Operating System

1. Judge your system by the work it produces, not by what it contains.
2. Keep the active system small and fresh; keep the archive cold.
3. Capturing a thought is not having one.
4. When you become the administrator, stop and prune.
5. Decide which part of the thinking you will never hand to a machine.

#Appendix D — Glossary

Accountability sink — Dan Davies’ term for a structure or process that absorbs decisions so that no identifiable person is responsible for them.

Algedonic signal — Stafford Beer’s term for an alarm that bypasses the normal chain of reporting and reaches the top directly.

Andon cord — On Toyota production lines, a cord any worker may pull to stop the line when they see a problem.

Compound engineering — A practice, named by the software company Every, in which each piece of agent-assisted work ends by feeding what was learned back into the agents’ instructions, checks and tools, so the next piece is easier (ch. 13).

Constraint — In Eliyahu Goldratt’s theory, the one step that limits what a whole system can produce; improving anything else is an illusion, and when the constraint is relieved it moves (ch. 3).

Dark factory — A software factory in which agents turn specifications into shipped code without any human reading the code (ch. 3, 10).

Error budget — A pre-agreed allowance of unreliability; when it is used up, new releases stop until reliability recovers.

Feedback — Information flowing back from the work to whatever governs it.

Gall’s law — John Gall’s rule of thumb that a complex system that works has always evolved from a simple system that worked (ch. 13).

Golden path / paved road — The supported, recommended way of doing a common engineering task on an internal platform.

Goodhart’s law — The tendency of a measure to stop measuring well once it becomes a target.

Harness — Everything in an AI agent system except the model itself: tools, instructions, checks and memory.

Holdout scenarios — Tests of what software must do, kept where the AI agents writing the software cannot see them, so that the agents cannot learn to game them (ch. 11).

Intent specification — Nancy Leveson’s form of specification that records the reasons behind a design alongside its requirements, level by level.

Jidoka — The Toyota principle of machines (and people) that stop when something is wrong.

Jump — This book’s word for a metasystem transition: a new level that controls and multiplies the level below.

Latent failure — A flaw already present in a system, too small to cause trouble on its own, waiting for a change, load or coincidence to activate it (ch. 8).

Legibility — James C. Scott’s term for making something simple enough to be seen, counted and governed from outside.

Mechanism — In Amazon’s usage, a complete process — a tool, its adoption, and inspection of the results — as opposed to a good intention (ch. 14).

Metasystem — The layer that governs, coordinates or builds other systems; in Beer’s model, Systems 2 to 5.

Metasystem transition — Valentin Turchin’s term for many copies of a system coming under the control of a new level.

Metis — Scott’s term, from Greek, for practical, local, hard-to-articulate knowledge learned by doing.

Model — A regulator’s internal picture of the system it governs.

Normal accident — Charles Perrow’s term for an accident that is an inherent property of a complex, tightly coupled system.

Process model — Leveson’s term for a controller’s model of the process it controls.

Regulator — Anything that acts to keep a system within acceptable bounds: a thermostat, a pilot, a manager, a dashboard, an AI pipeline.

Remainder — This book’s word for the work left to humans once the easy part has been automated.

Requisite variety — Ross Ashby’s law: only variety can absorb variety; a regulator must be able to respond in as many ways as the system can go wrong.

Reward hacking — A system satisfying the letter of its goal rather than its intent — the thermostat next to the lamp, with a machine-learning budget (interlude after ch. 2).

Second brain — A personal system for capturing and organising notes, links and ideas outside your head (ch. 15).

Shadow system — An unofficial tool or record people build because they do not trust the official system.

Single-threaded leader — At Amazon, one person whose whole job is a single initiative, with the authority to run it (ch. 14).

Stop — This book’s word for the authority to halt the work.

Tight coupling — A property of systems in which effects spread quickly between parts, with little slack.

Viable system model — Stafford Beer’s model of the five functions every surviving organisation performs.

#Appendix E — Worked answers to “Your Turn”

These are sketches of good answers, not the only ones.

Chapter 1 — every task linked to a ticket, 98% of time accounted for. The number shows legibility, not work. Likely hidden changes: (1) illegible work — backchannel help, mentoring, quiet fixes — has either stopped, because it cannot be ticketed, or is being squeezed into vague catch-all tickets; (2) people are splitting and labelling work to fit the ticket system rather than the other way round. To find out, compare the ticket record against a week of self-reported “untracked work” (Chapter 1’s Try This), and watch for slowing onboarding and rising incident recovery times, which often depend on backchannels.

Chapter 2 — five green metrics while AI tripled change volume. The dashboard is a stale model: it was fitted to a slower, human-paced system (Conant and Ashby’s fourth comment), and its thresholds may no longer mean what they did. It may also be measuring the error rather than the cause. Better: add measures of the new constraint — review load per reviewer, time changes spend waiting for review, rate of changes later reverted — and re-baseline the old metrics against the new volume.

Chapter 3 — AI reviewer approves 99%, defects rising. Explanation one: the reviewer shares the writer’s blind spots (same training, same model of “good”), so it approves exactly the mistakes the writer makes. Explanation two: the writer has learned, in effect, what the reviewer accepts — optimising against a visible check. To tell them apart, add an independent check the writer cannot see (held-out scenarios, or periodic human review of a random sample) and compare what it catches with what the AI reviewer passed.

Chapter 4 — a 40-person startup’s overloaded all-hands. Split the work into small, largely autonomous teams (System 1), give coordination a clear home (a short weekly coordination meeting of team delegates — System 2), name who allocates resources today (System 3) and who looks outward and ahead (System 4), and keep a small forum for purpose and identity (System 5). The mistake to avoid is Suma’s: running the old all-hands with its old powers alongside the new structure. Switch it off, or turn it explicitly into something else.

Chapter 5 — support tickets closed twice as fast, reopenings doubled. Goodhart’s law: time-to-close became a target, so tickets are being closed before problems are solved. Measure outcomes as well as activity — customer-confirmed resolution, reopen rate, and satisfaction — so gaming one shows up in another, and have someone independent sample closed tickets.

Chapter 6 — security alerts ignored as “mostly false positives.” This is ALIS’s alert fatigue: an alert that is usually wrong trains people to ignore the ones that are right, creating risk that a real vulnerability is dismissed. Fixes: measure and publish each alert rule’s false-positive rate and tune or remove the worst; make it cheap to mark an alert as wrong and feed that back to whoever owns the rules; and treat teams’ workarounds as data about where the rules fail.

Chapter 8 — removing the last manual approval “because it never catches anything.” Against: eight months of success is exactly Columbia’s “reliance on past success”; the step may be catching things silently, or may be the defence that stops the rare combination Cook describes; removing it tightens coupling. For: an approval that is never exercised may be a rubber stamp — a false sense of safety that trains people to approve without looking (Chapter 10). To decide: audit what the step has actually examined; run a period where it is replaced by a stronger independent check (sampling, held-out tests, a kill switch) and compare.

Chapter 9 — a copied developer portal at 15% adoption. The organisation has copied the tool without the practice underneath — consistent ownership data, conventions, and a platform run as a product. A mandate would raise registration, not genuine use, and would hide the feedback. Instead: find out why the 85% don’t use it (Mannapur’s test), build the missing practice first, make the portal the easiest path for one real workflow, and grow from there.

Chapter 10 — reviews getting faster and approving more. Good explanations: the agent has genuinely improved, or the reviewer has learned where it is reliable. Worrying ones: vigilance decrement and trust built on past success (the reviewer has stopped really looking), or the reviewer’s own skill has faded so they no longer see the problems. To tell them apart: periodically seed known defects into the review stream, or re-review a random sample independently, and see whether the reviewer’s catch rate has changed.

Chapter 11 — code passes tests but is hard to change. The specifications describe what the code must do but not why or for whom, and nothing checks maintainability. Guides: add intent and constraints — who will maintain the code, which parts are expected to change, preferred structures. Sensors: add checks for maintainability (complexity thresholds, review of a sample by senior engineers for changeability), kept where the agent cannot game them.

Chapter 12 — only senior staff ever block deployments. Reassuring: seniors see the most risky changes, and juniors rarely need to block. Worrying: junior engineers do not feel safe pulling the cord. To tell them apart without asking directly: look at incident reviews for cases where a junior engineer noticed the problem beforehand; look at chat history around risky releases for concerns raised but not acted on; or pre-agree automatic stops that anyone’s observation can trigger and see whether their use changes.

Chapter 13 — an 18-month platform at 5% weekly use, mandate proposed. Don’t mandate. For six months: embed platform engineers with two or three product teams; pick one painful workflow and make the platform genuinely the easiest way to do it; set an adoption measure based on activity and time-to-value, not registration; open the roadmap to users; retire any competing older tools. This moves up Meadows’ ladder from rules to information flows and goals.

Chapter 14 — replacing managers company-wide next month. Risks: the managers’ jobs (onboarding, mentoring, resource allocation, looking ahead) stop being done; a hidden hierarchy forms around the founders; the old structure lingers alongside the new. Before rollout: list every function the managers performed and assign each an explicit owner or mechanism — and pilot in one part of the company first.

Chapter 15 — an “almost perfect” knowledge system, less writing. The system has become the work: its owner is now its administrator. Plan: freeze the current system as a cold archive (nothing deleted); start a small, fresh active system — one list, refreshed daily; judge it for a month by writing produced; pull things from the archive only when a piece of writing needs them.

#Appendix F — Further reading

Free and open-access sources are marked ★.

The ideas - ★ Roger C. Conant and W. Ross Ashby, “Every Good Regulator of a System Must Be a Model of That System” (1970). - ★ W. Ross Ashby, An Introduction to Cybernetics (1956), on the Internet Archive. - ★ Nancy G. Leveson, Engineering a Safer World (MIT Press, 2011), open access. - ★ Lisanne Bainbridge, “Ironies of Automation” (1983). - ★ Richard I. Cook, “How Complex Systems Fail” (2000). - James C. Scott, Seeing Like a State (1998). - Stafford Beer, Brain of the Firm and The Heart of Enterprise. - Charles Perrow, Normal Accidents (1984). - Sidney Dekker, Drift into Failure (2011). - Donella Meadows, Thinking in Systems (2008) and ★ “Leverage Points” (1997). - John Gall, Systemantics (1975). - W. Edwards Deming, Out of the Crisis (1982). - Valentin Turchin, The Phenomenon of Science — ★ via Principia Cybernetica. - Dan Davies, The Unaccountability Machine (2024).

The cases - ★ GAO-20-316 on the F-35’s ALIS (2020). - ★ Columbia Accident Investigation Board, Report, Volume 1 (2003). - ★ US House Transportation Committee, Final Committee Report on the 737 MAX (2020). - ★ Post Office Horizon IT Inquiry, Final Report (2025 onward). - ★ Royal Commission into the Robodebt Scheme, Report (2023). - ★ HHS Office of Inspector General on HealthCare.gov (2016). - ★ Leveson and Turner on the Therac-25 (1993). - ★ This American Life, “NUMMI” (2010, 2015), transcripts.

The practice - ★ Google, Site Reliability Engineering and companion books, sre.google. - ★ Dan Luu and contributors, “A List of Post-mortems!” (GitHub). - ★ Lorin Hochstein, “Resilience engineering papers” (GitHub). - Matthew Skelton and Manuel Pais, Team Topologies (2019; 2nd edition 2025). - Camille Fournier and Ian Nowland, Platform Engineering (2024). - Nicole Forsgren, Jez Humble and Gene Kim, Accelerate (2018). - Gene Kim and Steven J. Spear, Wiring the Winning Organization (2023). - ★ Birgitta Böckeler’s articles on martinfowler.com; ★ Sean Goedecke’s essays at seangoedecke.com; ★ Will Larson’s at lethain.com.

#Appendix G — The Haiku Wall

Every chapter of this book ends with a haiku: seventeen syllables, in lines of five, seven and five, where the last line turns the joke. They are collected here in the order they appear, one after another, so you can read the book’s argument in a few hundred syllables. Chapter 7 has none, by design.

Straight rows, perfect count.
The ledger balanced for years.
Then the forest died.
— 1. The Forest That Died

The thermostat knows
exactly how warm it is
next to the toaster.
— 2. Every Good Regulator

Every part worked well.
The legs said we had landed.
Forty metres short.
— What If? — What If Your Thermostat Lied to Itself?

We built a machine
to build the machine that builds.
Who builds the checker?
— 3. The Jump

A list for my lists.
A review of the review.
The milk has gone off.
— What If? — What If Your To-Do App Needed Its Own To-Do App?

Five systems, nested,
each one viable inside.
Who reads the future?
— 4. The Viable System

We measured the tests.
Coverage hit one hundred.
Nothing is tested.
— 5. Compliant and Fatal

Report the fault here.
A small fee applies. Please wait
a few months. Thank you.
— 6. The Fee for Bug Reports

Everything is fine.
(Eleven small things are not.)
Everything was fine.
— 8. Running Broken

We copied the chart.
Tribes, squads, chapters, guilds — the lot.
Nobody asked why.
— 9. The Model You Copied

Watch the robot work.
All day it does not fail once.
It fails. Where were you?
— 10. The Ironies of Automation

It watches me type.
Forty-eight helpful comments.
Now I wear earbuds.
— What If? — What If We Swapped Jobs: the AI Watches, the Human Types?

Tell it what you want.
Tell it why, and who will read.
Then check it. Then check.
— 11. Specify or Explain

The cord hangs right there.
Everyone knows you can pull.
No one ever has.
— 12. Who May Stop the Line

Five thousand cords pulled.
The company never runs.
Now shorten the cord.
— What If? — What If Every Employee Could Stop the Company?

We paved a fine road.
Grass grows through it by the spring.
Nobody walks there.
— 13. Grow It, Don’t Design It

No bosses at all.
Just ask whoever eats lunch
with the founder. Thanks.
— 14. The Organisation’s Operating System

My second brain grew.
I now spend all of Sunday
tending to its needs.
— 15. Your Own Operating System

The scoreboard says win.
Somebody still has to ask
what game we’re playing.
— Epilogue — Back to the Scoreboard

#A note on sources

Every factual claim in this book was drawn from a primary source, an official report, or a named, dated secondary source, and the research notes behind it are kept alongside the manuscript. Where a claim could not be confirmed from a primary source in time, the draft marks it for checking rather than stating it as fact. Claims about AI tools and results are dated, because they change quickly; the ideas beneath them change slowly. Stories shared by individuals online are paraphrased, and quoted only briefly; no person, quotation or scene in this book is invented, with the single exception of the comic strips and their three clearly fictional characters, Pat, Dee and Unit 7.