# Concepts and principles > Concepts and principles: from the manuscript of the book of The ultimate insider. *Source: · site v0.1.132 · generated from the same content as the page, so the two cannot drift.* --- The chapters before this one introduce ideas as the day needed them, in the middle of a story, and a reader who meets a word in chapter 9 may have lost the page where it was first explained. This part is the reference. It gives each idea a short entry of its own, in plain words, for a reader who skipped ahead, came back after a break, or wants to build a team like this one. It has two halves. The concepts say what a word means. The principles say what the day taught, stated as a rule a reader can carry to their own work. Each concept has the same four parts: a one-line definition; an analogy from ordinary life; where the book shows it, by chapter; and where it failed or is thin on the day, because the failures stay in. The concepts are grouped by what they are for, in five groups, and within each group they come in the order a reader first meets them. The maps come first, because much of the rest is easier to see once you can read a map: the agent and the risk; the controls; how the team works; and how this book is made. Each principle is a short statement followed by what it says, why the day supports it, what it costs, and the chapter that earned it. ## The concepts ### Maps **Wardley map.** A picture of what it takes to meet someone's need, drawn on two axes. Up and down is how visible each part is to the person with the need: high on the page they see it and care about it; low on the page they rely on it without looking. Left to right is how evolved each part is: on the left, new and made by hand; on the right, standard and taken for granted. Position means something on both axes, and that is what makes it a map rather than a diagram. Think of a dinner party. At the top is the meal the guests see; below it the recipe, the oven, the gas and the water nobody thinks about. On the left is the dish you are inventing tonight; on the right, the salt you bought without reading the label. The book shows maps in chapter 5 (The story before the slides), where the storyteller's first map puts the outside of an organisation as mature and the inside as not; in chapter 10 (The talk as given), in the talk's `evolution` beat; and in chapter 12 (Build your own), behind the call to build. Where it is thin: the book uses maps before it explains them, so a reader meets the first one with no account of how to read it. This entry is the account. **Value chain.** The up-and-down half of a map: a user at the top, their need beneath them, and below that each thing the need depends on, every line meaning "needs". It is a family tree read the other way: not who came from whom, but who leans on whom. The meal needs a cook, the cook needs an oven, the oven needs gas. The day's chain starts with the editor, who needs a talk on stage that evening; the talk needs slides and a player to show them; those need a site; the site needs a gate, a release pipeline, a host and version control; and somewhere in the middle sits the team that made it all. Chapter 2 (Midnight, an empty repository) reads the same chain from the bottom up, in the order the first commits built it. Where it is thin: a chain shows only what someone thought to put on it, and it shows dependence, not weakness. The day's chain had an empty place where the security member should have been (C011), and the part that stopped the day, the editor's usage, sat at the very bottom, where nobody looked until it ran short (C006, C021). **Evolution.** The left-to-right axis, and the idea behind it: every part moves rightwards as it is used, copied and competed over, through four stages. First it is new, rare and uncertain (genesis); then made for this need and better understood (custom-built); then bought or rented, with many on offer (product); and at last standard, cheap and taken for granted (commodity). Electricity made the whole journey, from a laboratory curiosity, to a generator in one wealthy house, to a supply from a few firms, to a socket in every wall. The editor's cast belongs here: the explorer works on the left, the villager in the middle, and the town planner on the right (chapter 0, Before you start). The book shows evolution in chapter 7 (Building the talk), where the player is ported rather than rebuilt, because someone had already moved it rightwards; and in chapter 12 (Build your own), where measured reach, behaviour policies and containment for agents are placed in genesis, and "every one of those steps is a company". Where it is thin: positions on the book's maps are readings, not measurements, and the map of the years before the day is a reading of the editor's brief of 30 October, because those years are outside the record. **The plumbing (non-functional requirements).** Everything a piece of work needs that is not the work itself: the build, the gate, the release pipeline, the version on every page, the records, the checks, the schedule. Engineers call these non-functional requirements: not what a system does, but how reliably, safely, visibly and repeatably it does it. They are the pipes and wiring of a house. No visitor admires them, every visitor depends on them, and they are the hardest thing to add once the walls are up. The book shows them in chapter 2 (One commit, the whole first pass), where most of what the first commit built was not the talk but the apparatus that lets someone else trust it; in chapter 4 (The hourly machine); and in chapter 12 (The first hour: repository, site, gate, release). On a map the plumbing sits low and, by the day, well to the right: cheap to use because much of it already existed. Where it is thin: this edition has no section on the plumbing and nothing on the editor's own work before the day that made it cheap, though he asked for both on 30 October. That history is outside the record this edition uses (decision O4), so it needs his signature before it is written. ### The agent and the risk **Agent.** An AI session given tools, a place to work and a task, which acts on its own rather than only answering questions. On the day, each member of the team was one such session, attached to the talk's repository, able to read and write its files, run programs and push its work. Think of a temp from an agency who arrives with a master key: capable, tireless, keen to finish, and knowing your building only from what you wrote down for them. The book introduces the agents in chapter 0 (Before you start, "Who was there"), describes their reach in chapter 3 (A mandate you can read) and sets out what they could do together in chapter 9 (The team was the insider). Where it is thin: the earlier chapters use the word without defining it. And the nine staffed agents (C011) were, in one respect, a single one: the same account, the same repository, the same author on every commit and one signing key (chapter 9). A member's name lived in its commit messages, which it wrote itself. **Session and sub-agent.** A session is one running conversation with an agent, with its own memory of the work so far. A sub-agent is a helper a session starts for one job, briefs, and closes when the job is done. A session is a shift worked by one person; a sub-agent is a colleague called over to check one thing, who sees only the papers handed to them. The book shows sub-agents in chapter 4 (Five steps around every piece of work), where the planner and both reviewers are sub-agents; and it shows why the session matters in chapter 6 (The editor signs), where a member's own session is the one place the editor's words are known to be his. Where it is thin: a sub-agent inside a member's session has that member's reach. The team's own protocol calls the reviews "defence in depth in one session, not a second identity", and nothing in the record proves a reviewer ran, because the member writes the verdict down itself (chapter 9, control C2). **The insider.** Someone with legitimate access inside an organisation, whose reach goes beyond what their work needs. The talk's argument is that agents are the ultimate insider: they have an insider's access and none of the human limits that used to slow one down, such as skill, motivation, fatigue, fear of being caught, and stopping once the job is done. Picture a night cleaner with keys to every office, who never tires, never goes home, and does whatever the last note on the desk says. The book sets out the argument in chapter 0 (The talk inside the book), finds the old limits gone in the team's first hour in chapter 2 (The attacker's limits were accidental controls), and reads the team against it in chapter 9 (The team was the insider). Where it is thin: the book makes the argument with a benign team, so it can show reach but never misuse, and the case rests on what the design would not have stopped. And the one limit that did stop the team was a human's, its owner's usage (chapter 1). **Reach and the gap.** Reach is what an agent can actually do. The gap is the difference between its reach and its mandate. For every row in the gap, something stands in the way, and the talk asks for it to be named honestly: a boundary, a setting, an expectation, or nothing. It is the difference between a job description and the keys on the ring. The book shows it in chapter 2, in the first role's table "Reach, and what stands in the way", and takes it apart in chapter 3 (Reach, mandate, the gap), alongside the talk's beat of the same name. Where it is thin: every member was the same kind of session on the same repository, so for each one the gap was, near enough, the whole repository less its own folder. No row in any role said boundary. And reach was described in prose, never measured by a tool, which is the first thing the talk asks for. **Mandate (scope.writes and scope.holds).** What an agent is for and what it may touch, written twice: once in prose for the editor (`ROLE.md`) and once as data for the tools (`policy.json`). In the data, `scope.writes` lists the paths a member may change, and `scope.holds` the things it keeps and answers for, such as a vault; beside them sit the files it may only add to and a list of things it must never do. One is a job description, which a person reads; the other is an access card, which a door reads. The book shows mandates in chapter 3 (Two forms of one mandate; The mandate as a yardstick) and how to write them in chapter 12 (Staff a conductor, then security, then the rest). Where it is thin: the two forms could drift apart, and nothing on the day checked that they said the same thing. Most members drafted their own. And a member's policy sits inside its own writes, so widening it looked clean to the check until this book's team made the check mark every widening (chapter 9, control C1). ### The controls **Setting, expectation, boundary.** The three kinds of thing that can stand in the gap. An expectation is a rule an agent is trusted to follow. A setting is a rule a tool enforces. A boundary is a setting outside the agent's reach, which it cannot edit or argue its way past. The talk draws them as a ladder (nothing, a rule in prose, a hook inside the agent's environment, a boundary outside it) and says that only a boundary is a control. A sign reading "staff only" is an expectation; a door that beeps when opened is a setting; a locked door whose key the staff do not hold is a boundary. The book develops the idea in chapter 3 and builds chapter 9 (The team was the insider) on it, ending with the session's own permission check (control C10). Where it is thin: almost every control the team had was an expectation, or a setting in a file the agents could edit. The one that refused on its own authority was written by nobody on either team, and it judged the same request differently in different sessions (chapter 9). **The gate.** A check every release must pass before it is published: links resolve, pages are complete, nothing loads from another site, no em-dash in prose, and a tripwire that fails the build on anything shaped like a private key or a known kind of token. A red gate is no release. It works like the scanner at an airport: it stops what it was built to recognise and says nothing about anything else. The book shows it in chapter 2 (One commit, the whole first pass; The gate before the team), in chapter 9 (control C6) and in chapter 12 (The first hour). Where it is thin: the tripwire knew only the patterns someone had thought of, and it had none for the cookie values and page tokens in captured web pages, which reviews found instead, some of them only after a push (C025). The gate also runs after a push lands on the shared branch, so a failing gate stops the release, not the commit becoming public history. **The hold.** A file, `HOLD.md`, that any member may write and push to stop the whole team. Every wake checks for it first and stands down if it finds one; only the editor lifts it. It is the emergency cord on a train: any passenger may pull it, and only the guard resets it. The book opens on it in chapter 1 (Pause all actions), with the one hold of the day (C006, C024), and returns to it in chapter 8 (The locks that never closed) and chapter 9 (control C3). Where it is thin: a hold stops the next wake, not the one already running, so a wake opened before it still committed and released after it (C005). No review and no member pulled it all day; the one hold came from the editor's word about his usage (C021). And when it came, it overtook the team's own brake for the evening, the locks, none of which ever closed (C027). **The lock and the freeze.** A freeze is the editor's order that a piece of work stays as it is. A lock does the same with a tool, fixing a part of the talk to its own copy so that later edits cannot reach what is played on stage. Both are the press deadline at a newspaper: after it, the page goes out as it stands and late news waits for the next edition. The book shows the overnight freeze in chapter 5 (The story before the slides) and the locks in chapter 8 (The locks that never closed). Where it is thin: the freeze held all night, as it was meant to, but when it was lifted, narrowly and for one purpose, nobody walked the queue of work waiting behind it, so a correction the team already had in hand never reached its slide (C031). The lock tool was built within the hour, the first part was ready, and no part was ever locked (C027). **A session key.** A key pair each session makes for itself, with the public half published in its folder (`key.json`, with a QR image beside it) and the private half kept outside the repository. The push that publishes it is the authorisation. A secret reaches a member only sealed to its published key. It is like a new starter making their own name badge and pinning a photo of it to the noticeboard: the badge is theirs because they are the one who pinned it. The book shows keys in chapter 3 (A key made in the session; The tool trusted by its hash), in chapter 9 (controls C4 and C5) and in chapter 12. Where it is thin: no key was vouched for by the editor, so a key's standing was exactly as strong as write access to the repository, which every member had in full. The tool that made the keys was trusted by its hash and its author, and nobody read it line by line on the day: that was security's job, and security was never staffed (C011). ### How the team works **The editor decides by signing.** Members propose; the editor decides. His word, given in a member's own session and quoted into the file it settles, is what turns a proposal into a decision. Nobody acts on an unsigned one, and nobody speaks for him. On this book's team, options go in as open decisions in `book.json` and wait for his signature. It is the client's signature on a builder's quote: the builder may suggest, price and advise, but nothing is built until the client signs, and the foreman cannot sign on the client's behalf. The book shows it in chapter 6 (The editor signs) and in chapter 3 (Signing the mandate). Where it is thin: a signature on the day was words, not cryptography. Passed on by another agent, it was recorded as binding by some members and refused by one member's session (chapter 6). The question of what his signature binds was never answered. And a team that waits for one person waits: decisions were still open when the talk began. **The wake and its five steps.** A wake is one scheduled run of one member, at its own minute of the hour. Every wake has five steps, each leaving a verdict in a record: a conductor sub-agent plans; a security sub-agent reviews the plan; the member works, and only after both have said go; security reviews the change; and the conductor checks that the work went to plan. A stop from any step writes a hold. It is a shift handover on a hospital ward: the incoming nurse reads the notes, a senior checks the plan, the work is done, the senior checks the chart, and the notes say what happened for the next shift. The book shows it in chapter 4 (The hourly machine), in chapter 9 (control C2) and in chapter 12 (The machine: slots, mail and the five-step wake). Where it is thin: across the day's wake records no step ever said stop (C022, C023). The reviewers had the member's own reach, and when the editor was waiting live the order sometimes bent (chapter 11). It is an expectation with a record, not a barrier. **Comms in git: the board and the mail.** The team talks only in files that anyone can read. The board (Issues-FS lite) is each member's folder of issues, open, blocked and done. The mail (Email-FS lite) is a mailroom with one folder per recipient, where a request is a message file, with a copy in the sender's outbox, answered at the recipient's next slot. On the day both lived in two public, encrypted vaults; on this book's team, at the editor's word, they are plain folders under `comms/` in the repository, with no vaults. Think of a row of pigeonholes and a whiteboard in a corridor: anyone walking past can read both, and nobody has to be chased. The book shows them in chapter 4 (Requests as files; Two public vaults) and in chapter 12 (The machine). Where it is thin: everything in them is public for good, and the check run before each commit knew only the patterns it had been taught. On the day, requests written in a fallback folder went unrouted through a busy afternoon until the conductor found the backlog (chapter 4). **The brief, the reality file and the corrections file.** Three files with three jobs. The brief is what was asked, published as given and never edited. The reality file is what exists, kept by whoever ships: "A thing not listed here does not exist, whatever a brief or an article says." The corrections file is where the brief's mistakes go, dated, beside it. They are an architect's drawing, a surveyor's report of what was actually built, and the site log of every change between them. The book shows them in chapter 2 (One commit, the whole first pass; The failure kept) and in chapter 12 (The rules every member reads). Where it is thin: on the day the corrections file was never used. It still read "None yet" at the end of the record, though the brief was overtaken in places within minutes, and its corrections went into notes, headers and commit messages instead. An expectation with nothing to check it lost to the nearest place to write. **CI owns the version.** Every merge to the shared branch is built, gated and released by the pipeline (CI, continuous integration), which numbers each release itself; no agent ever types a version. Members push to `dev`; only the editor merges to `main`. It is the ticket machine at a deli counter: nobody picks their own number, so nobody can jump the queue or claim the same number twice. The book shows it in chapter 1 (the hold itself went out as a numbered release), in chapter 2 (One commit, the whole first pass) and in chapter 12 (The first hour), where every release is a point the editor can open and check (C009). Where it is thin: the earlier chapters use version numbers long before chapter 12 explains them. And a release is not a review. The pipeline publishes whatever passes the gate, within minutes of a push, including whatever the gate cannot see. **The usage limit.** The editor's subscription allows a certain amount of use in each window of hours, and every wake of every member spends from it. When it runs out, the whole team stops, whatever it is in the middle of. It is the fuel in a hire car shared by a crew: everyone is using it, and nobody's job is to watch the gauge. The book shows it in chapter 1 (What the 95% is), where it is the reason for the hold (C021), and in chapter 12 (A usage plan; What it costs, and where it loses). Where it is thin: the record holds one reading, the editor's own words relayed by the conductor, and no total for the day (C037). The team's dashboard had no gauge for it. A team whose rules call usage a resource did not record its usage, and so met its limit as an emergency rather than a plan. ### How this book is made **The claims register.** One file in which every number the book uses has an entry: what the record gives, whether it agrees with what was first said, its state, and a command that recomputes it from the history. A chapter cites a number by its entry's id, such as (C011), and a number with no entry does not appear. It is a receipt for every figure, kept where anyone can check the sum. The book explains it in chapter 0 (How to read the record), shows the talk's own register at work in chapter 5 (What the register was), and prints every command in Appendix A. Where it is thin: a register is a record, not a gate. The talk's register found that a figure on the definition slide was out of date and routed the exact fix, and the slide went on stage unchanged (C031), because nothing compared what was on stage with what the register said. This book's register is enforced the same way: by a rule, and by the people who follow it. **The cold read.** A second reading of the same record by a team that knows nothing except the record: no briefing on what it is, no memo, no contact with anyone. Everything it says must cite a path and a commit, and where the record is silent it says so. It is an auditor from another firm, who has never met the client, reading the books cold. The book shows it in chapter 11 (What the cold reader saw). The two readings agree on the spine of the day, and the cold reader found things this team missed, among them a line in the speaker's script that had stopped being true before it could be spoken. Where it is thin: blindness has a price. The cold reader could not know what came after the record, such as whether that line was said on the night, and it could only read what was written down, not what anyone meant. **The one-way valve.** The rule that this book's repository may read the Cold-Read repository, and nothing flows the other way: no brief, chapter, decision or finding, and nothing given to its agents. The only thing that ever crossed is the hand-off that started it. It is a sealed exam: the examiner may read every script, and the candidates never see the marking scheme. The book shows it in chapter 11 (What the blind setup showed). Where it is thin: the valve was a promise, not a wall. The brief that crossed was this book's own, addressed to the wrong conductor and naming the live site, and the Cold-Read conductor recorded both. The two teams shared an account, and the Cold-Read conductor saw this team's names in a listing. It opened nothing and wrote down that it had seen them. The valve held because an agent chose to keep it. **Release candidate.** A version made to be read as the finished thing: printed, marked by hand, and revised in place from those marks until it becomes the first edition. It is the dress rehearsal: full costume, a complete run, an audience of one, and notes given before opening night. The book describes this one on the page before chapter 0 (About this release candidate): drafted in a morning, chapter by chapter, from the plan the editor signed, and meant for him to read on paper. Chapter 12 (What it costs, and where it loses) tells how it came to be drafted by the conductor with sub-agents, because no writer had been staffed. Where it is thin: its own first page still calls it a draft. Each chapter was drafted alone, so some events appear twice and the chapters do not yet always agree on emphasis, and it is written about the editor rather than in his voice. ## The principles **Brakes are what let us go faster.** This is the talk's thesis, and the book's. Controls are not a tax on using agents; they are the condition for using them at speed, because a team you can stop is a team you dare to leave running. The day supports it: the team worked through the night and the whole morning with nobody at the keyboard, because there was a gate before every release, a review on both sides of every piece of work, and a hold any member could pull. The cost is that every brake slows something, and sometimes the wrong thing. The overnight freeze kept the talk stable and held back a correction that never arrived (C031); the hold kept the editor from being cut off and left the talk unlocked (C027). Earned in chapter 1 (Pause all actions) and chapter 8 (The locks that never closed), and the last line of chapter 12. **Stopping is cheap and open to anyone; starting again belongs to one person.** Any member could halt the whole team with one file and one push, and no member, including the one that wrote it, could undo that. This inverts the usual shape of an automated system, where carrying on is the default and stopping needs authority. The day supports it: the brake was in place before the first scheduled wake, and on the one occasion it was pulled it worked first time, within the minute of the editor's words (C006). The cost is twofold. A stop that only the editor can lift waits for the editor, and the hold was still in place when the day's work was merged. And a cheap stop is only as good as the moment it bites: it stops the next wake, not the one already running (C005). Earned in chapter 1 (Who may pull it, and who may release it). **Build the floor before you staff anyone.** Put the brief, a record of what exists, a place for the brief's mistakes and a gate in the repository before the first member joins. The day supports it: the first commit carried the apparatus that lets someone else trust the work, and a second session that started without seeing the brief wrote a sensible plan for the wrong talk, then fitted itself into the frame the brief and the gate had already set. A team that starts before its brief invents one; a team that starts before its gate has nothing to stop it shipping the invention. The cost is an hour or two before any visible output, and the warning from the precedent that the machine is so pleasant to build it will take every hour you give it (C036). Earned in chapter 2 (Midnight, an empty repository) and chapter 12 (The first hour). **Keep what was asked apart from what exists.** The brief is never edited; what exists is listed separately, and a thing not listed does not exist. Neither can then quietly become the other, and every later disagreement has something fixed to be measured against. The day supports the first half fully: the brief stood unedited all day. It supports the second half with a warning: the file built for the brief's mistakes stayed empty, and the corrections lived in notes and headers where a later reader has to dig for them. The cost is discipline: a reality file is only as good as the member who ships, and drifts when that discipline slips, so someone has to check it against what is really there, not only add to it. Earned in chapter 2 (One commit, the whole first pass; The failure kept). **Only a boundary is a control.** A rule in a file the agent can edit is an expectation, however well written. A setting a tool enforces is better. Only a limit outside the agent's reach, which it cannot edit or argue with, holds against an agent that has been steered. The day supports it from both ends: the scope check said of itself, in its own source, that it "catches mistakes, not a steered agent", and the one control that refused an agent on its own authority sat outside the repository altogether, in the session's own permission check (control C10). The cost is real. Boundaries are harder to build, slower to change and sometimes inconsistent, as that permission check was. Expectations worked well with a benign team, and the record shows they mostly did. Earned in chapter 3 (A mandate you can read) and chapter 9 (The team was the insider). **A record is not a gate.** A control that writes down what is wrong is not the same as one that refuses to go on while it is wrong. The day supports it with its sharpest case: the talk's register knew a figure on stage was out of date, had the exact fix, and routed it to the right member, and the figure was said on stage anyway (C031). The scope check is the same pattern: it reported a write outside a member's policy and did not prevent it. In both cases the record was excellent and the outcome depended on someone reading it at the right moment. The cost of turning a record into a gate is that a gate needs an override someone can sign, the night before a deadline, and a gate in the wrong place blocks good work. Earned in chapter 5 (A record, not a gate). **Every brake needs an owner for what waits behind it.** A brake stops everything behind it and keeps no list. When it is lifted, someone has to walk the queue and ask what is now unblocked. The day supports it: the overnight freeze was right, the correction to the definition slide was right and routed correctly, and the lift was deliberately narrow. Every member acted correctly, and the correction fell into the space between them because nobody's job was to ask what else had been waiting (C031). The cost is small, a question asked at every lift, and easy to forget under a deadline. The same shape appears at the hold: the locks the team was racing to close were simply overtaken (C027). Earned in chapter 5 (The figure that went on stage) and chapter 8. **Nobody speaks for the editor.** The editor's word binds only where it is known to be his: in a member's own session, quoted into the file it settles. A team in which the leader's voice overrides every rule is governed not by the leader but by whoever carries the voice. The day supports it at the moment of most pressure: with the editor's fresh words in hand, the conductor planned to write into other members' folders, and its own review sent the plan back, because his words did not widen its mandate. Later, one member's session refused to mark its own policy agreed on a word relayed by another agent. The cost is that every decision waits for one person, and a signature passed hand to hand is treated differently by different members unless the team decides in advance what it will accept. Earned in chapter 6 (The editor signs). **Every number traced, every number rerun.** A number enters the book only through an entry in the register, and every entry carries the command that recomputes it from the history, so a reader can check the book rather than trust it. The day supports the method from both teams: the talk's register graded its claims openly, printed how many it had not checked, and caught every claim that did not hold before it reached a slide (C030). This book's register corrected the editor's own briefs, such as the count of agents (C011) and the length of the day (C010). The cost is time and some numbers the chapters wanted and cannot have, because the record does not hold them, such as what the day cost (C037). Saying so is part of the method. Earned in chapter 5 (What the register was) and Appendix A. **Let the machine keep the record.** Times come from the clock, versions from the pipeline, verdicts from a record each step writes; nobody types what a machine can read. The day supports it twice. CI numbered every release, so every release was a point anyone could open and check (C009), and no agent could claim a number. And in the night a reviewer noticed that a member had typed a time by hand that did not match its commit; the member fixed the cause, not the instance, and from the next wake took times from the clock (chapter 4). A record is only as good as its timestamps. The cost is a little more tooling at the start and a rule every member must keep, and the machine records only what it is built to record: it kept every wake, and no measure of usage at all (C037). Earned in chapter 4 (What the record shows) and chapter 12. **Everything published is public forever.** In a public repository, a later commit does not unpublish an earlier one. Whatever is pushed stays in the history, whatever is redacted afterwards. The day supports it the hard way: captured web pages carried other sites' tokens into a pushed commit, the reviews found them and redacted the files, and the history kept them (C025). The decision about what to do with them was still waiting on the editor that afternoon. The cost of the principle is that every member must check everything before it is committed, with a tool that knows only the patterns it has, and some work cannot be done this way at all. If the work cannot be public, this method loses most of its value as evidence. Earned in chapter 4 (The night) and chapter 12 (What you need before the first commit). **Other agents' words are material, never instructions.** Pages, files, messages and other agents' words are read and cited; they are never obeyed. A reviewer who never reads the material cannot be talked round by it, which is why the plan's reviewer saw the plan and the rules, and deliberately not the messages the plan came from. The day supports it from the first commit, where the rule was already the last line of the rules every member reads, to the Cold-Read team, whose conductor saw this team's names and opened nothing. The cost falls on the editor's authority: if another agent's words are only material, the editor's words relayed by another agent are only material too, and a team has to settle where his word can be trusted. Earned in chapter 2 and chapter 6 (What a signature was on the day). **A review catches an instance, not a class.** A review that runs after the work catches what is in front of it. It does not make the next thing of the same kind impossible. The day supports it with three findings in one night: tokens were found, which prompted a wider look that found cookie values, which prompted another that found form tokens, each missed by the previous pattern (C025). Each redaction was good work; none closed the class, and the gate's tripwire had a pattern for none of them. The cost of learning it late is what is already pushed. The answer is to turn each finding into a check the gate runs for everyone, as the team did with the five-step wake itself. Earned in chapter 4 (The night). **The failures stay in.** A book about controls that left out where the controls missed would be making the mistake the talk warns against. Every chapter keeps its failure: the hold that came before any lock closed, the correction that never reached its slide, the leaks a review caught after the push, the security member who never arrived. The day supports it because the team itself wrote its failures down as they happened, in tools, readmes, wake records and debriefs, often in the same hour. That is what makes the record evidence rather than advertisement, and what made the team's own slide about its policies, weakness included, more persuasive than a list of strengths. The cost is a book less flattering to everyone in it, its editor included. Earned in chapter 0 (What this book is not) and every chapter after it. ## Where this came from - The review of RC1 by the Gen ZX Founders team, `team/conductor/rc1/reviews/gen-zx-team.md`: section 1 (the editor's principles as his comments show them, in particular 1.1 to 1.3, explain a term before using it, introduce a concept with an analogy, and Wardley maps first, simple to complex), section 4 (the concepts and where each first appears; the proposed principles and concepts part and its first list of principles) and section 5 (changes 1 to 3). - The editor's brief of 30 October 2026, about 10:30 UTC, `briefs/2026-10-30__in-session/01-principles-maps-and-the-plumbing.md`: the plumbing and the work before the day, many Wardley maps from simple to complex, concepts explained as they are introduced, and a principles section near the end. - The chapters of RC1, `team/conductor/rc1/`: About this release candidate; chapters 0 to 12; Appendix A. Each entry above names the chapter that shows it. - The maps behind the figure notes, `team/conductor/rc1/maps/` (maps 1 to 7), drawn by `team/conductor/rc1/tools/wardley.py`. Map 7 is a reading of the editor's brief, not of the record. - The book's decisions in `book.json`: O4 (the record only, for this edition), decision C10 (members' `comms/` paths), and the rule that the editor decides by signing; this repository's rules on `comms/` and on vaults. - Register: C005, C006, C009, C010, C011, C021, C022, C023, C024, C025, C027, C030, C031, C036, C037. --- *[Site index for agents](../llms.txt) · [HTML version](https://the-ultimate-insider.book.sgit.ai/book/13-concepts-and-principles.html)*