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
governance-engineering-101
Not every rule an agent reads deserves the same force, and pretending otherwise breaks governance in one of two directions: either everything is "guidance" and quietly ignored, or everything is "law" and the system cannot evolve. In episode one we made quality an exit code. This
governance-engineering-101
Every post on this blog has to pass a blocking CI check before it can ship, exactly like code. Five gates run over every artifact: sensitivity, anti-slop, faceless-voice, no-overclaim, and conversion mechanics. A post with a bloated title, an uncited number, or a missing call-to-action fails the build, and no
knowledge-systems
Most engineering teams lose what they learn. The decision lives in a chat thread, the dead-end lives in someone's memory, and the third time a question comes up, somebody re-derives the answer from scratch. We decided to treat that as an infrastructure problem. So we built a brain.
governance-engineering-101
The field names its practice in rungs, and each rung names the artifact you engineer: the prompt, then the context window, then the harness, then the loop. Four serious fleet designs are running in public right now, and comparing them dimension by dimension shows the same two cells empty everywhere:
governance-engineering-101
There is a ladder the field climbs when it names its own practice. Prompt engineering: write better instructions. Context engineering: Tobi Lütke's term from June 2025, amplified by Andrej Karpathy: fill the context window with the right things. Harness engineering: Mitchell Hashimoto's coinage from February 2026: