brick · v1 · 2026-08-03
Readiness is not authorization
A thing being finished is not permission to send it
What collapses when a system treats completed work as its own release approval, and the posture that keeps the last step a human one. The canonical treatment of the readiness-authorization split.
A package passes every gate. The archives regenerate byte for byte from the named source, the visual proof renders from the generated files rather than from retained references, the unpacked contents scan clean, and the last check goes green. Everything the process was built to establish has been established. The obvious next step is to send it, and the obvious next step is the mistake.
One of our own quality-gate rulings closes its packaging section with a single sentence that does more work than the checklist above it. Artifact readiness must remain separate from authorization to send. It is easy to read that as procedural fussiness, one more sign-off in a document already full of them. It is the opposite. It is the line that keeps a verification system from becoming a dispatch system without anyone having decided to build one.
The mechanism is that readiness is a property of the artifact while authorization is a decision about a relationship, so a pipeline deriving the second from the first has converted finishing into consent and removed the moment at which a person could have declined.
The strongest form of the separation is not a confirmation step. Our authoring runtime states its default posture as a list of absences, no telemetry, no external network egress, no runtime mutation, and no browser apply endpoint, and it describes its support bundles as dry runs with no send path. Not a send behind a prompt, not a send requiring a flag. No send path. A confirmation dialog is a behavioral guard sitting in front of a capability that exists, and it fails the way every behavioral guard fails, one distracted operator at a time. A missing send path has no failure rate because there is nothing there to fail, which is the argument this corpus makes about safety generally, arriving here at the last step of a build.
The most instructive place this collapsed is not in software delivery at all. At eight in the morning on 13 January 2018, an employee at the Hawaii Emergency Management Agency working through a routine drill selected an alert and transmitted it, and every phone in the state received a warning of an inbound ballistic missile with the instruction that this was not a drill. It took thirty-eight minutes for a correction to reach the public. The subsequent federal investigation found no rogue actor and no software defect. It found that the live template and the drill template were offered from the same menu, and that no second person was required to authorize a live alert before it went out. The system had one question where it needed two. Is the message ready, and separately, does this go to a million people. Among the corrective actions adopted afterwards was the obvious one, which is that a live alert now requires a second person to authorize it.
That is the agency line drawn in an ordinary workflow. A system that sends when its work is finished has stopped being a tool that prepares something and started being an actor that acts on the world, and the transition happens quietly, without a design decision, simply because the last green check was adjacent to the button. Our corpus has the companion case on the permission side, where a consent recorded once is treated as standing clearance for flows nobody examined. This is the same collapse in the other direction, where completion is treated as clearance for a send nobody chose.
Keeping the two apart costs almost nothing and buys back the only thing worth having at that point in the process, which is a person looking at a finished artifact and deciding, on purpose, that this is the moment and that is the recipient. The build can be as automatic as anyone wants. The sentence that begins here is yours to write.