An ADR is not automatically a guardrail
Most teams that adopt coding agents already have the decisions written down. There is a docs/adr/ directory, a CLAUDE.md, an architecture page in the wiki, and a set of conventions everyone senior already knows. The documentation is not the problem.
The problem is what sits between the document and the change:
ADR → human-readable document → coding agent → generated change. Nothing in that chain guarantees a control. The agent may retrieve the decision, or may not. If it retrieves it, it 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 exactly the kind reviewers are worst at catching.
So counting ADRs measures the wrong thing. A repository with forty decision records and no enforcement is not better governed than one with twelve; it simply has more documented intent that an agent can contradict. The useful question is narrower and answerable:
Which of the decisions you have already written down can a coding agent violate today without anything stopping it?
Four states, not two
The instinct is to sort decisions into “enforceable” and “not enforceable”. That split is too coarse to act on, because it hides the distinction that actually determines what you can do this week.
Mneme’s Architecture Protection Audit classifies every decision it discovers into one of four states:
| Decision | State | What it means |
|---|---|---|
| “Do not use SQLite” — with a deterministic rule already active | Protected | Enforcement exists now. A violating change is already rejected, and the Audit verified the rule rather than taking the decision’s word for it. |
| “Do not use Redis” | Mneme-ready | The Audit can reduce this to one concrete supported guardrail — FORBID_LITERAL redis — and hands it to you. Available, not yet active. |
| “No vector DBs, agent loops, or LiteLLM” | Requires modelling | The intent is genuinely enforceable, but the sentence spans several independent terms. Decomposing it safely is modelling work, and the Audit will not guess. |
| “Keep retrieval and enforcement conceptually separate” | Guidance | Real architectural intent that should not become a literal rule. It belongs in review and design conversation, not in a deterministic check. |
The Audit reports how many decisions fall into each state and what share of the mechanically governable ones are currently Protected. That figure is the honest denominator: it excludes Guidance rather than counting decisions the product should never have promised to enforce.
The two states in the middle are the ones that matter
Protected and Guidance are the easy ends of the range. The commercially useful distinction is between the two in between, and it is mechanical rather than editorial:
- Mneme-ready means the Audit has a concrete supported guardrail it can represent without guessing. In the automatic literal path shown here, a single significant term is enough. Multi-term intent remains Requires modelling unless a safe explicit guardrail is available. When a guardrail exists, the Audit emits it and you can copy it.
- Requires modelling means the architectural intent appears enforceable, but turning the prose directly into a rule would risk false positives or misrepresent what the decision actually says.
That boundary is not a judgement call, which is why it can be stated plainly on a page like this one. Either the decision reduced to a single supported guardrail or it did not, and the Audit shows you the guardrail when it did.
Why the Audit refuses to guess
It would be easy to be more generous here. A decision like “no vector DBs, agent loops, or LiteLLM” obviously carries enforceable intent, and a tool that wanted a better-looking number could simply treat each word in it as a forbidden literal.
That approach was tried, and it failed in a specific and instructive way. Treating the words of a multi-term architectural instruction as independent forbidden literals means the rule fires on any one of them in isolation. The sentence above decomposes into five separate terms — vector, dbs, agent, loops, litellm — and several of those can appear innocently in code or documentation. Earlier dogfooding showed that treating them independently produced false positives. The enforcement layer became noise, and noisy enforcement gets switched off.
The design principle. Mneme does not automatically promote ambiguous multi-term prose into deterministic enforcement. For a single-term anti-pattern, the Audit can formulate a literal guardrail without decomposing the prose. A multi-term decision needs modelling first — scoping it to the paths it governs, or splitting it into the separate constraints it actually contains.
“Requires modelling” is therefore not a failure state. It marks a boundary of what can be enforced automatically today, and the useful thing is that the Audit exposes that boundary rather than fabricating a rule to hide it. It is also the reason the Mneme-ready count means something when you see it.
What this is not
ADR enforcement is a narrower claim than it is usually mistaken for. It is not:
- Putting ADRs in a retrieval index. Retrieval gives an agent the decision. It does not make the agent comply — see RAG versus governance.
- Adding decisions to
CLAUDE.md. A rules file tells an agent the rules; it cannot stop the agent breaking them. See the CLAUDE.md comparison. - Reviewing harder. Review is a human-throughput process and agent output is not throughput-bounded. See why code review cannot scale with AI output.
- Generalised drift detection. The Audit answers whether a decision can be deterministically governed. It does not claim to find every architectural deviation in your history.
For the fuller account of how agents actually treat decision records — ignored, advisory, or enforced — see how AI coding agents use ADRs. To watch one decision become an executable constraint, see the ADR compiler demo.
Where this goes
The Audit is the diagnostic, not the whole path. It runs against a repository, classifies the decisions it finds, saves a baseline you can return to, and lets you re-audit later and compare against that baseline to see what changed.
From there the direction is deliberate rather than automatic:
Audit → install → review your protection gaps → activate guardrails deliberately.
Nothing in that sequence happens to your repository without you choosing it. Installing Mneme does not silently switch on the guardrails the Audit identified, and it does not change your Architecture Protection figure on its own. Current Protection increases when a decision gains active deterministic protection. Modelling a harder decision may first move it to Mneme-ready, increasing the protection Mneme has identified as achievable; it becomes Protected only when that guardrail is activated. Guardrails for Requires modelling decisions are not generated automatically; that is the point of the classification.
Start with the decisions you already have, and find out which state they are in.