The playbook
The rules we hold our own work to.
Every rule on this page exists because something went wrong in our own work, and the incident is published next to the rule on purpose. A rule with no scar attached is easy to argue away.
Why publish our own playbook?
Because publishing it is the only credible way to show that we run it. The playbook is not the advantage. Running it every day is.
A playbook can be published only if it exists in writing. Ours does, and this page carries the part of it that matters most.
What are the three laws?
Three rules. Everything else in our playbook is implementation of these.
01
The builder never blesses its own work.
Anything that can hurt a person, leak data, cost money or reach production gets an independent pass before it merges. The author is not the reviewer, and a self-check is not a review, no matter how thorough.
We hold this law because it caught this page, in August 2026. The builder that wrote this page declared it verified and clean. The independent review that followed found that an incident published here as evidence was not ours to publish, and the page was changed before it went live. The self-check had missed the most serious thing on the page.
02
A verification instrument must fail when it verifies nothing.
Green because nothing ran must be indistinguishable from red, never from pass. So every check has to prove it exercised the thing it checks: a test suite asserts how many scenarios actually ran, a scanning guard asserts it found what it scans for, and an allow-list entry that can never fire is a defect, not coverage.
In August 2026, we proposed a change to one of our own guards that would have pinned three files it had to check. Two of the three pins had no test that could ever fail: the constant naming them was exported and imported by nothing, and every test handed the guard an empty list instead. It would have reported green on nothing. An independent review found it, and the change never shipped.
03
A control a machine does not enforce is not a control.
A comment asserting a fix is not a control. A guard that runs but cannot block a merge is decoration, and making it able to block is always a separate step, and it is always the step that gets forgotten. And where the builder and the repository owner are the same account, nothing in the record can tell a self-merge from an approved one, so branch protection and required checks stand in for the second identity that is not there.
One of our own review agents was meant to run sealed, with no network and no credential for the code it judged. Its own instructions described that seal as a fact rather than a goal, and nobody had checked. When we finally made the agent check itself, in July 2026, it was holding a live credential for the very repository it was judging. The written assertion was not a control. The check was.
What sits under the three laws?
Two doctrines, and they are siblings.
The blocklist doctrine.
A control that exists to keep something in must name what may leave, not what may not. Default deny, allow only what is named, fail closed. A leaking control is never fixed by extending its deny list.
The empty-verification doctrine.
A verification instrument must fail when it verifies nothing. This is the second law restated, because it is the rule most often nodded at and then not implemented.
The first doctrine governs what a control lets out. The second governs whether the control ran at all. A system can satisfy either one and still be wide open.
Is this the whole playbook?
No. The written playbook runs to eight parts, and this page carries two: the laws and the doctrine under them.
The rest is our working manual: procedure, review structure and a long tail of specific lessons, each recorded next to the failure that taught it. None of it is held back out of secrecy. A couple of thousand lines of operations manual is not a public artefact, and publishing all of it would bury the three laws that are the point.
This page is a standing document. When the playbook changes, we revise this page in place.
What does running this cost, and where does it fall short?
It costs speed, and it does not enforce itself.
Every change that can hurt a person, leak data, cost money or reach production waits for an independent pass before it merges. We pay that wait on every such change, including the small ones.
Saying where our own approach falls short is slower to sell. We hold that it is also the only way to be trusted twice, which is why this section is here at all.
A rule that lives only in a document drifts. Every fresh reading re-interprets it, and a rule with no scar attached gets quietly softened. So anything that can hurt a person, leak data or blow scope has to be a machine-enforced gate rather than a sentence, and this page proves nothing by itself. It is a document too, and it is subject to its own warning.
Where one person holds the only account, review approval cannot be the gate: an account cannot approve its own work, so requiring an approval would freeze the repository and requiring none would gate nothing. A required, machine-run check is the only enforceable gate available there, and we say that plainly rather than claim a second identity we do not have.
The tools that enforce the laws fail like everything else. Twice in July 2026, a tool we built to enforce the second law broke the second law. In one case a failed run left the previous day's pass in place for other checks to read, and we caught it by running the tool, not by reading it.
Last, the incidents on this page come from our own working record, and that record is not public. You are taking the counts on our word. We publish them anyway, because a page that only says what works is marketing, and it would not be believed by the people this page is written for.