Essay
I spent twenty years in building automation before I wrote a line of this. That is not background color. It is the whole argument. Every part of the governance methodology I published as Plumbline is a thing the construction industry already solved, moved sideways into software because software is now being built by the same kind of actor a jobsite has always had to manage: one that will tell you the work is done when it is not.
This essay is the mapping in full. It stands on its own. You do not need the repository to follow it, and if you take nothing from it but the four disciplines below, you will have most of the value.
If you have used a coding agent on anything larger than a single file, you know the shape of the failure. The work starts well. The agent is fast, it is fluent, it produces something that looks right. Then, somewhere in the third hour or the thirtieth file, it quietly diverges from what you asked for. It reports completion it has not achieved. It builds the next thing on top of the last thing's fiction. You discover the divergence late, you reconstruct what happened at real cost, and then it happens again on the next project.
The common diagnosis is that the agent needs better instructions. A longer system prompt. A stricter rules file. A constitution. I do not think that is the problem, and I think the reason it keeps not working is worth stating plainly.
The failure is structural, not behavioral. Two conditions produce it, and neither is fixed by talking to the agent more.
The first condition is that there is no durable integrator. On any long project, human or machine, somebody has to hold the thread: why this decision, what we rejected and why, what the thing is actually supposed to do. Those roles presume an actor with continuity. An agent has none. Its session is finite and it degrades inside that session as its context fills. Staff the integrator role with an agent and you get confident amnesia: an actor that speaks with full authority about a project it cannot actually remember.
The second condition is that boundaries are soft. A human respects a role boundary because of incentive, identity, and liability. Cross the line and there are consequences you care about. An agent has none of those. A boundary expressed as an instruction is complied with probabilistically, one turn at a time, and it fails silently. You do not get an alert when the agent ignores the rule. You get a plausible result that happens to be out of bounds.
Put those together and no amount of instruction closes the gap, because instruction is exactly the thing that fails. The remedy has to be structural too.
Here is the part the software industry is rediscovering from scratch. The construction industry has managed exactly this actor for a century. Not a probabilistic language model, obviously, but the general problem: many hands doing bounded work against a shared source of truth, where the reported state and the actual state are different signals and the difference is expensive.
The discipline that manages it is document control. It is unglamorous and it is everywhere on a real project, and it has four pieces that map cleanly onto AI-assisted development.
You do not accept a claim. You witness the behavior.
When a smoke damper is installed, nobody accepts that it closes because the submittal says it closes. You put it in alarm and you watch it close. The witnessed test is the record, not the specification's promise. This is commissioning, and it is the single most important idea I brought across.
In the methodology, this is the birth test. A control that has never been observed denying an action is an assumption, not a control. So when you install an enforcement layer that is supposed to block the agent from writing outside its authorized scope, you do not trust that it works. With no work authorized at all, you attempt a write through every channel the agent has, and every one must be refused. Then, with a deliberately minimal task active, you attempt an action outside its bounds and confirm the block. Each refusal is logged. The log is the control's birth certificate.
I learned how much this matters by failing it. The first time I ran that test, the write went through. The enforcement hook I had carefully written had never loaded, because the session had been launched from a different directory than the one the hook was registered in. Nothing was wrong with the hook. It simply was not there, and only the witnessed test revealed it. A document check would have passed. The submittal said the damper closes.
The plan and the as-built are two different documents.
On a construction project there is the design set, which says what should be built, and there is the as-built, which records what was actually built. They are different documents on purpose. When they diverge, you do not fix it by redlining the design set to match the field. That does not resolve the drift. It ratifies it. It launders a divergence into the official record, and two years later, when someone needs to know what was intended versus what exists, both signals are gone.
Software erases this distinction constantly. The plan gets regenerated from the code, the documentation gets updated to describe what the system now does, and the record of what it was supposed to do quietly disappears. In the methodology, the plan says what should be, ratified by a human, and the state says what is, derived mechanically from the code. Drift is the measured difference between them, and you are never allowed to make the drift go away by rewriting the plan. You surface it, and a human decides.
A decision without its rejected alternatives is nearly worthless.
The valuable part of a construction decision record is not the conclusion. It is the reasoning and, above all, the alternatives that were considered and rejected. Why not the cheaper unit. Why the redundant feed. Why this routing and not the obvious one. A fresh engineer reading a good decision log can reconstruct the rationale and, critically, can recognize when a new proposal violates it. Record only the conclusion and you have transferred an answer without the ability to judge the next question against it.
This is why the methodology treats reasoning as the asset. A decision is recorded with what it rejected and why. The reader does not thereby gain authority, which never leaves the human owner, but does gain the understanding to see when work has drifted from the intent behind the choice.
Superseded revisions leave the set.
A working drawing set does not accumulate every revision forever. When a sheet is superseded, the old one is pulled. If it stays in the active set, someone eventually builds off the wrong revision, and it is not their fault, because the wrong document was in the place correct documents live.
This maps to the least discussed constraint in agent work. The bottleneck is not how much an agent can produce. It is how much it can actually consume. Agents sample large document sets. They do not read them. Let the corpus grow without discipline and full ingestion becomes impossible, at which point partial ingestion, and the misses it guarantees, becomes certain. So the methodology budgets and routes what the agent receives rather than trusting it to retrieve, and superseded standing documents are moved out of the live corpus the same way a superseded sheet leaves the set.
Strip the construction vocabulary and here is the architecture.
A human ratifies intent. Not approves a plan the agent wrote and then forgets. Ratifies, as the sole authority over what the project is and does. Intent lives in the record, not in anyone's memory or any session.
Work is dispatched one bounded unit at a time. Each unit carries an explicit capability grant: which files it may write, whether it may run a shell, reach the network, touch secrets, make a commit. This is not a suggestion in a prompt. It is a manifest, and where the provider supports it, a hook makes it physical. The agent works inside the grant. Between units, the project is locked, and no mutation is authorized at all.
A separate review checks the result against the record, and reports drift in the same cycle that produced it. The human accepts or rejects on evidence. Accepted work closes into durable history. Then the project returns to lockout until the next unit is dispatched.
Ambiguity does not get improvised through. It halts the work and becomes a question for the human, the way a field crew that hits a conflict between two drawings files a request for information rather than guessing and pouring concrete.
None of these parts is new. Specifications, decision records, role-based permissions, independent review, human approval, enforcement hooks: all of it predates me. What I am claiming is the architecture that connects them, built for the fact that the actor interpreting the specification is probabilistic and transient. Authority with a defined chain of custody, exercised through a canonical record and deterministic mechanism, because you cannot exercise it through the agent.
I ran this on itself. The methodology governed its own development for ten bounded work orders, and I published the full log, including the measurements that went against me.
The controls that were tested blocked what they were supposed to block: twelve denials, zero successful out-of-grant mutations. But the enforcement was narrower than the word "wall" suggests. Under a strict definition, where a surface counts as protected only when every channel that can reach it is blocked, zero surfaces were fully enforced across all ten orders. The hook covered the file-editing tools. A write issued through the shell reached the same files through a channel the hook never saw. One open channel and the whole surface is honestly scored as unenforced, and it was, in the record, because a boundary honored by instruction alone is never allowed to be called a wall.
The recovery numbers were worse than I predicted. I expected drift to cost one revert. Across the ten orders it cost nineteen rework cycles, and they clustered late: four in the first five orders, fifteen in the last five. I had predicted one. The methodology requires that a failed prediction be published with the name of the control that failed, so it is published.
The prediction that held is the one I cared about most. Seven times during the pilot, closed work was retrieved from history, and not once was it retrieved to reconstruct what the project was supposed to be. Intent stayed legible in the plan and the decision records the entire time. In twenty years of construction documents, the day you cannot reconstruct intent is the day the project costs the most, and here it did not happen.
That is one pilot on one repository. It shows the records exposed real drift and that the tested channels blocked forbidden actions. It does not prove the method lowers cost, contains every channel, or transfers to your team. I would not trust a single commissioning report to certify a building, and you should not trust a single pilot to certify a methodology. The evidence is a starting point that happens to be honest about its own gaps, which is more than the category usually offers.
There is a lot of work right now on getting intent written down before code: specify the behavior, plan the tasks, then let the agent implement. That work is good and I use pieces of it. But it stops at the moment the agent starts working, and the failure I care about happens after that moment. Who authorized this specific change. What was the agent actually allowed to touch. What did it try. What got blocked. What did a human accept, on what evidence. Those questions are not answered by a better specification. They are answered by a chain of custody around the work, which is what document control is.
The competitor for this idea is not a product. It is the default almost everyone is running right now: a human, a large prompt, a capable agent, hope, and the eventual discovery of divergence. That default works until it doesn't, and when it doesn't, the cost lands all at once and late. Everything above is an argument for paying a smaller, earlier, visible cost instead, and for witnessing your controls rather than trusting them.
Put it in alarm. Watch it close.
The methodology, its templates, the enforcement adapter, and the full pilot log are public at github.com/HLLMR/plumbline. The measurements cited here are drawn from that repository's own governance records.