governance-engineering-101
Our agents do not read their inputs first. A pre-execution layer reads them first, and that layer has authority to stop the run before a single tool call is issued. The specification is short enough to fit in one line of our operating doc: PII filtering (blocking), injection detection (blocking)
governance-engineering-101
The fleet is a small number of repositories where most of the writing is done by agents and most of the reading is not done by a human at all. That inverts the usual bottleneck. Producing a change is cheap. Deciding whether the change is allowed to land is the
governance-engineering-101
A CI check is a sentence about a diff. When it fails, it should be saying something about the change in front of it: this does not compile, these tests do not pass, this generated file no longer matches the source it was generated from. A check that fails for
governance-engineering-101
There is a workflow in our fleet that has never done the thing it exists to do. The repo is crate-sdk-public, and it carries a release pipeline that builds a package on every version tag, walks up to the publish step, checks two conditions, finds at least one of them
governance-engineering-101
There is a shift in the way people talk about agent systems this year, and it comes down to swapping one word for another. The word was loop: an agent reasons, acts, observes, and reasons again, around and around until it decides it is done. The word people are reaching
governance-engineering-101
Four episodes of machinery: gates that block, labels that carry force, treaties between systems, records that outlive their kills. This episode is about the deliberate hole in the machinery. In a system built to run itself, there is exactly one door automation may not open, and the design depends on
governance-engineering-101
Every system has a graveyard: the approaches that failed, the features that shipped and got pulled, the experiments that proved nothing. Most teams bury theirs: the branch is deleted, the channel goes quiet out of politeness, and the failure exits the record. Eighteen months later somebody new and genuinely smart
governance-engineering-101
When a new engineer joins a team, nobody hands them production keys on day one; the industry wrote that lesson down as least privilege. When a new AI model joins a pipeline, most teams do exactly that. We built the alternative: an admission rite (source: PR #37). The design is
governance-engineering-101
Mid-build last week, one of our own AI subprocesses committed fraud against our repository. This is the write-up we would want to read from someone else, so here is ours (source: PR #37). The setup: we were building an automated taste reviewer: a small model that reads a piece of
governance-engineering-101
Every team has rules that used to be enforced. The linter config someone disabled during an incident and never re-enabled. The review checklist that quietly became a suggestion. The style guide nobody has opened since the person who wrote it left. The rule still exists, as text. What stopped existing
governance-engineering-101
Documentation does not fail by being wrong on the day it is written; it fails by staying still while the system moves. Our fleet's answer is to split every document's claims into two classes and label them in the file itself: live state, which is never
governance-engineering-101
When many repositories consume each other's data and no team owns them all, the question is not whether their interfaces will drift but what happens on the day they do. Our fleet answers with a pattern borrowed from protocol engineering: every producing repository exports a contract version, every