Where: the specification for Kai Composer, decision two: “Humans always approve the last step before anything deploys or reaches a customer. Non-negotiable, not a toggle.”
Symptom: none. No bug, no outage, nothing crashed. This entry breaks the diary’s own stated rule, “a running log of real failures”, and we log it anyway, honestly labelled. The reason it happened rhymes with every other entry: a decision that was correct at the moment it was written stopped being correct a few hours later, and almost went unrecorded for the same reason the others did. The version that got written down first is the version people build on top of.
What actually happened
The spec for Kai Composer, the orchestrator that directs Kaizou’s AI workforce, fixed its human-approval boundary at a single hard line, identical for every customer: autonomy stops the moment a pull request opens, full stop. The reasoning borrowed directly from Data Guard, where “hold, never soften into a knob” is exactly right. Data Guard decides whether sensitive data leaves a customer’s boundary at all, a one-shot leak-or-no-leak call that should never be negotiable.
Composer’s boundary isn’t that shape. It is a position on a ladder: dispatch, pull request, merge to dev, merge to staging, production. The correct stopping point on a ladder is a function of how much a given customer has come to trust the thing climbing it, which is not, and has no reason to be, the same number on day one as a year in. The analogy felt right because both sentences use the word “boundary.” That was the whole basis for treating them the same.
What surfaced it was mundane. In the same session, four AI workers were being run by hand on this exact repository: one human deciding which worker had the most relevant context for each new piece of work, watching for a pull request stuck on red CI, and relaying status back and forth in chat because there was no other channel. Replacing that chat relay with one self-updating file per worker turned the habit into a visible pattern. Context-matching and gate-awareness are both things an orchestrator should eventually do for itself, which is precisely what Composer is.
Once that was obvious, so was the question one level under it. If a human orchestrator naturally extends more trust to a worker with a long track record than to a brand-new one, why had Composer’s spec given every customer, on day one, the exact same amount of rope?
What changed
The boundary is now a per-client configurable setting: conservative by default for every new customer, extendable only by a customer admin, never lowered automatically. One position on the ladder did not move. Production, and anything that reaches a real customer, still requires the same human approval it always did. That part of the original sentence was right. It was the word “non-negotiable” applied to everything before it that wasn’t.
The lesson
Not every boundary that should be firm should be fixed. Some things need to never move at all: Data Guard’s egress boundary, and Composer’s own production-deploy step, both unchanged by this entry. Others need to be firm by default and earnable: configurable only upward, only by an accountable human, never below the safe default for a customer who hasn’t asked. Treating the two the same is an easy mistake to make precisely because the instinct that makes the first kind correct feels identical to the instinct that makes the second kind wrong.
We run this way today. Read how the org works in How we run an AI-enabled engineering org.
