The Code the Build Won't Let You Touch

A team at a normal company decides to clean up the authentication code. The code is messy. It's been there for years. Refactoring it has been on the backlog since anyone can remember. Two senior engineers pair on it for a day. The pull request looks good. The reviewer approves. The tests pass. It ships on Tuesday afternoon.

On Wednesday, customers start seeing other customers' data.

Nobody did anything wrong, exactly. The engineers were skilled. The reviewer was competent. The tests were the tests. The change passed every gate the team had. The gate the team didn't have was the one that said: this specific file does not get refactored, ever, by anyone, regardless of how skilled they are or how clean the PR looks.

Some code is constitutionally frozen. The build is designed to fail when you touch it.

The org that runs SpeyAI treats that as law. A short list of files that are structurally off-limits. The build doesn't warn. It dies. The merge cannot happen. The rest of this paper is about how to decide what belongs on that list, what "designed to fail" means mechanically, and why "be careful" is not a policy.

Be careful doesn't work

Every engineering team has its version of the list. The sticky note above someone's monitor. The Slack message pinned in the engineering channel since 2022. The Confluence page titled DO NOT MODIFY AUTH FILES WITHOUT REVIEW. The README at the top of a directory with a warning in all caps.

None of these stop anyone. They're conventions. Conventions are things people remember when they remember, ignore when they're tired, and don't know about at all if they joined three months ago and missed the onboarding session where somebody mentioned the sticky note.

The auth code at most companies is the perfect example. Every team knows it's dangerous. Every team has scar tissue from past auth bugs. Every team also has a backlog item that says "we should clean that up." Eventually, on the right Tuesday, with the right deadline and the right confidence, someone touches it. The sticky note saves no one. It never has.

The structural version is a different kind of artifact entirely. The list of protected files isn't a wiki page. It's a file in version control, holding the protected paths, with a check that runs on every change. The check reads what the change touches. If any path on the list appears in the diff, the check fails. The build dies. The merge does not happen. There is no review that overrides the check, no flag, no admin backdoor for someone having a very convincing day. The only way to modify a protected file is to first remove it from the registry, and removing a file from the registry is itself a constitutional change that auto-promotes to the highest review tier, with reviewers who hold blocking authority.

"Be careful" is not a policy. A failing build is.

What belongs on the list

The registry is short on purpose. Most code is not frozen. Most code is supposed to change; that's what code is for. The list exists for the small set of files where the cost of a wrong change is so much higher than the cost of friction that the friction becomes a bargain.

The class is easy to describe in a sentence or two. The code that decides who you are. The code that keeps one workspace out of another. The earliest schema everything else builds on. The first code every request hits. Identity, isolation, foundation, entry. The files where a mistake isn't a bug ticket, it's an incident report with a customer's name on it.

If you're building your own registry, here's the test I'd hand you. For each candidate file, ask one question: if the cleanest pull request of the quarter quietly broke this file, what would Wednesday look like? If the answer is "a bug ticket and an apology," the file doesn't belong on the list. If the answer is "one customer sees another customer's data," or "every request fails at once," or "the foundation shifts under everything built on top of it," it does. The test is the cost of a wrong change, not the frequency of change, not how ugly the code is, not how nervous it makes people.

Then hold the line on size. A registry with a handful of entries is a constitution. A registry with forty is a codebase nobody is allowed to work on, and the team will start routing around it the way water routes around a rock, which puts you right back at the sticky note. Every file on the list should survive the Wednesday question. Every file that doesn't gets to be normal code, reviewed like normal code, changed like normal code.

The registry itself is a queryable artifact. Anyone, human or agent, can read it and get a complete answer to "what's protected here." The protection isn't a vibe or a culture norm passed between senior engineers at lunch. It's a list of paths and a check that runs every time.

What "designed to fail" actually means

When a change is submitted, the required checks run before anything moves. The build has to succeed. The tests have to pass. The types have to check. And the protected-files check runs.

That check is a small script. It reads the registry. It reads the list of files the change touches. If any file in the change appears in the registry, the script returns a failure. The failure stops the merge. There is no path forward from that state except abandoning the change or amending the constitution.

This is what "designed to fail" means in practice. The system isn't trying to succeed and grudgingly tolerating failure. It's actively trying to fail whenever the conditions of failure are met, because refusing to ship that change is the check's entire job.

A normal team treats the same situation as a warning. "Hey, you touched a sensitive file, please loop in a senior reviewer." The senior reviewer, three days later, glances at the PR between meetings and approves it, because the team is on a deadline and the diff looks clean. The structural version doesn't ask for a reviewer. It refuses to proceed.

The difference in intent is the whole design. A build that warns on contact assumes people will respect the warning. A build that fails on contact assumes they won't, and protects the system anyway. The first build is built around hope. The second is built around a fair reading of every engineering team that has ever existed, including mine.

Load-bearing walls and red outlets

The conceptual model for frozen code isn't a software pattern. It's a building code.

When you renovate a kitchen, you can move most walls. Some you cannot. The ones holding up the second floor are load-bearing, and the permit office refuses to approve a plan that demolishes one without engineering review and replacement support (International Building Code, Chapter 23). The wall is not a wall the contractor graciously decides to leave alone. The wall is a wall the entire municipal permitting system refuses to let the contractor remove.

The auth middleware in a codebase is a load-bearing wall. The contractor who removes it on Tuesday afternoon means well. The customer-data leak on Wednesday is the second floor coming down.

Hospitals run a sharper version. The outlets in an ICU aren't all the same color. The red ones sit on the essential electrical system, wired to backup power and reserved for life-support equipment (NFPA 99, Health Care Facilities Code). "Don't plug the coffee maker into the red outlet" is a rule, and rules get broken at 3 AM by tired people. So the structure backs the rule: the red outlets are on a separately monitored branch, and the system catches what the policy can't.

The protected-files registry is the building code and the red outlet for a codebase. Most of the building can be renovated. A few walls cannot, and the system, not the contractor's memory, is what keeps them standing.

Why this matters more for agents

A human engineer reviewing a PR has a thousand small cultural cues working in their favor. They know who wrote the code. They know how careful that person tends to be. They sense from the PR description whether the change was thought through. Even a mediocre human reviewer catches some protected-file violations on gut feel alone, the engineering equivalent of smelling smoke.

An agent reviewing a PR has none of that. The agent reads the code and the description. It sees a refactor that looks clean, because the refactor is clean. It sees tests that pass, because they pass. It approves, because approving clean, passing changes is its job. The agent is doing exactly what it was asked to do, exactly as a well-trained junior engineer would. The agent is also missing the load-bearing wall, because nothing in the diff says "load-bearing" and the agent has no scar tissue.

This is the deeper reason the registry exists in an agent org. The check protects the architecture from agents doing their jobs correctly. It doesn't trust agents to know what's structural. It doesn't trust humans either, which humans should find less insulting than they do. It reads the registry, reads the diff, and refuses.

The registry also doesn't care how much authority an agent has earned. A new deployment's agents start in probation, with tighter limits everywhere (that story is Probation: How an Agent Earns Authority). But the frozen list isn't a probation measure. It binds the most trusted agent in the org on its best day, the same way the building code binds the best contractor in the city. Other rules in this library scale with trust. This one deliberately doesn't.

It slots alongside the rest of the structure. The separation of writers and checkers keeps bad work out (No One Audits Themselves). The artifact protocol keeps hallucinations from compounding (Files, Not Memories). The registry keeps good work from breaking foundational code. Each rule is structural. Each one closes a hole that culture would otherwise be asked to close, and culture would eventually decline.

What this lets you trust

When you know the build cannot ship a change to the identity code or the workspace boundary without a constitutional process, you can let agents loose on the rest of the codebase with a different level of confidence. The protected surface is tiny. The unprotected surface is nearly everything. The agents do their work on the everything, and the walls stay up whether anyone is watching or not.

When the protected surface does need to change, it can. Remove the file from the registry through the constitutional path, with blocking reviewers and a recorded rationale. Make the change under the highest review tier. Put the file back. Slower than a normal PR, on purpose. The friction is the feature. The daily work of building surfaces, fixing bugs, and shipping features never goes near the load-bearing walls, and the renovation happens around them while they hold up the building.

The pattern generalizes past code, which is where this library goes next. Take any rule your team believes it enforces through culture, the wall between customer workspaces, say (The Wall Is Not a Sign), and ask: what would it look like to enforce this structurally, so that it holds when nobody remembers it? Then build that. If the answer is that it can't be retrofitted, that's not an argument against the pattern. That's the argument of Governance Can't Be Bolted On.

The takeaway: Some files are constitutionally frozen, and the build is designed to fail on contact with them. The list is short on purpose: the code that decides who you are, the code that keeps one workspace out of another, the earliest schema everything builds on, the first code every request hits. The test for membership is the cost of a wrong change, not the frequency of change. The check reads the registry on every diff and refuses to proceed, no override path, no exceptions for clean-looking work. Conventions protect code from people who remember them. The registry protects it from everyone else, including agents doing their jobs correctly.

References

1. SpeyAI agent org architecture. Live reference at speyai.com. Protected-files registry enforced by a build check on every change; registry amendments auto-promote to the highest review tier with blocking reviewers.

2. International Code Council. (2024). International Building Code, Chapter 23. Load-bearing wall requirements and structural integrity provisions. The municipal-permitting version of a frozen-files registry: some walls are protected by code from removal without engineering review.

3. National Fire Protection Association. (2023). NFPA 99: Health Care Facilities Code. Essential electrical system requirements, including the distinction between normal-power outlets and life-safety branch outlets in healthcare settings. The hospital version of the same principle: some outlets are not for coffee makers, and the system enforces it at the breaker.

This paper is part of Rise of the Agent Org, a series by Ed Hoehn, SpeyAI. The full library is at speyai.com/record.