In many engineering organizations adopting coding agents, the inventory is already substantial. A docs/adr/ directory holding a few hundred records. A CLAUDE.md at the repository root. An AGENTS.md beside it for another tool. An architecture space in Confluence, a golden-path README, and a platform standards page the staff engineers actually keep current.
The problem is rarely a shortage of written architecture.
The count you have is not the count that matters
Two different numbers get treated as one whenever architecture and AI come up in the same meeting.
The first is how many architectural decisions your organization has recorded. Any team can produce that number in an afternoon. It is large, it grows, and it reads like progress.
The second is how many of those decisions a coding agent can be prevented from violating. Almost nobody can produce that number, and it is the one that predicts what lands in the repository next week.
Writing the three-hundred-and-first ADR moves the first number. It leaves the second where it was.
Nothing in the chain is a control. ADR, then human-readable document, then coding agent, then generated change. The agent may retrieve the decision or may not. Having retrieved it, the agent may respect it or may not. Either way the diff arrives looking reasonable, the tests pass, and the violation is architectural rather than functional, which is the kind reviewers are worst at catching.
Why the enforceable subset is smaller than the folder
This is not a documentation-quality problem. Those decisions were written for a human reader, and a human reader supplies three things for free that a deterministic check cannot.
- Scope. “Use the repository pattern for data access” assumes the reader knows which directories count as data access. A check has to be given the paths.
- Terms. “No direct database calls from handlers” assumes the reader knows what a handler is in this codebase and which import signals a direct call. A check needs the literal.
- Exceptions. A reviewer waves the migration script through without writing anything down. A check either encodes that exemption or fires on it.
Enforceability is a property of each individual decision, evaluated against the repository it governs. It is not a grade you can hand a team, and it does not improve when the team writes more decisions.
More intent surfaces, more ways to disagree
The rest of that inventory earns its own attention. A repository carrying docs/adr/, a CLAUDE.md, and an AGENTS.md has three places where the same decision can be stated, and three chances for them to diverge after a year of edits.
A person resolves the conflict by asking someone. An agent does not ask. Whichever surface reaches the context window wins, and which surface reaches the context window is settled by tool configuration rather than by architectural authority.
One enforced guardrail collapses that ambiguity, because the check runs against the proposed change regardless of which document the agent happened to read.
Four states, not two
The instinct is to sort the corpus into enforceable and not enforceable. That split hides the distinction that decides what you can act on this quarter. Mneme’s Architecture Protection Audit uses four states.
| State | What it means | What you do next |
|---|---|---|
| Protected | A deterministic guardrail is active now, and the Audit verified the guardrail rather than taking the decision’s word for it. | Nothing. Re-audit later to confirm it held. |
| Mneme-ready | The decision reduces to one concrete supported guardrail the Audit can write without guessing. Available, not active. | Validate it, then activate it explicitly. |
| Requires modelling | The intent is genuinely enforceable, but the sentence carries several independent terms or leaves its scope implicit. Decomposing it safely is design work. | Scope it or split it, then re-audit. |
| Guidance | Real architectural intent that should not become a literal rule. It belongs in review and design conversation. | Leave it as guidance. Counting it as a gap would be dishonest. |
Two of the four are already settled. Protected decisions need no attention, and Guidance decisions should never become checks. The work sits in the middle two, and the boundary between them is mechanical rather than editorial: either the decision reduced to a single supported guardrail or it did not. The ADR enforcement page walks through the classifier’s reasoning, including why a multi-term instruction stays in Requires modelling instead of being chopped into separate forbidden words that then fire on benign code.
Run the inventory before you write anything new
Take a repository shaped like the one above: 214 decision records, a CLAUDE.md, an AGENTS.md, three standards pages. The inventory that matters has three layers, and none of them is a file count.
- Decisions discovered. Every distinct architectural commitment the Audit extracts from those sources, with the file and line it came from.
- Protection-relevant decisions. The subset that could mechanically govern a change. Guidance drops out here, deliberately.
- Protected decisions. The subset with active, verified enforcement. That is the numerator.
The second layer surprises people more often than the third. A mature ADR corpus holds a lot of context, history, and superseded records, which is fine, because those documents were doing a different job. The layer that governs agent output is smaller than the directory listing implies, and its size changes what you do next.
Illustrative shape only. What a real audit returns depends entirely on what a given repository has written down.
What changes once you have the number
ADR count stops being reported as coverage. An architecture review that opens with “we have 214 decision records” is reporting an input. Protection is the output, and it is a fraction with an honest denominator, because Guidance is excluded rather than counted against you.
The Mneme-ready set becomes a work queue. These are decisions where a guardrail already exists and nobody switched it on. Activation is deliberate and happens one decision at a time. Installing Mneme enables nothing by itself and moves no protection figure on its own.
Requires modelling becomes a scoping backlog rather than a defect list. Each entry is a decision worth enforcing whose sentence is doing too much at once. Splitting it into the constraints it actually contains is an afternoon of architectural thinking, and it converts directly into protection.
What the Audit does not tell you
It does not tell you that drift has already happened. The Audit reads the intent your repository has recorded and asks whether each decision can be deterministically protected from future AI-generated change. It does not scan history for past deviations, and it is not a code-quality or security tool.
It also does not enforce anything. Classification and enforcement stay separate by design: the Audit identifies what can be protected, and Mneme guardrails provide the protection once you activate them.
Point the Architecture Protection Audit at a repository and see which of your existing ADRs are Protected, which are Mneme-ready, which require modelling, and which should stay Guidance.