Two architectural decisions sit in the same repository. Both were agreed in the same meeting, both are written in the same voice, and both read as settled. One records its prohibition as orm. The other records it as introduce ORM framework.
The Architecture Protection Audit returns Mneme-ready for the first and Requires modelling for the second. Neither answer is a judgment about which decision matters more, and no model was asked for an opinion. The difference is that the first reduces to one concrete guardrail and the second does not.
The wording of a decision is not itself the guardrail. A decision is classified by what deterministic protection can be represented from what it recorded, not by how firmly it is phrased. An emphatic sentence with nothing mechanical in it is Guidance. A terse one-word prohibition can be Mneme-ready.
What the four states mean
Mneme classifies architectural decisions as Protected, Mneme-ready, Requires modelling, or Guidance. Protected means deterministic enforcement exists and was verified. Mneme-ready means a concrete supported guardrail can be represented without guessing. Requires modelling means deterministic intent exists but needs further decomposition or scoping before it is safe to enforce. Guidance means the decision should remain contextual rather than become a literal deterministic rule.
Why the Audit uses four states, and not two
The intuitive split is binary: enforceable or not. For how this particular classifier works, that split collapses two genuinely different questions into one answer, and the two questions have different owners and different fixes.
The first question is about the decision: how much of this can be represented as a deterministic rule at all? The Audit's answer has three levels. All of it, some of it, none of it.
The second question is about the repository: does that rule already exist and is it active? That question only makes sense for decisions that cleared the first one, and its answer is yes or no.
Three answers to the first question, two to the second, four states in total
Three answers to the first question and two to the second are why this classifier ends up with four states rather than five: the second question is meaningless for a decision that never cleared the first. Nobody asks whether the rule for “services should be loosely coupled” is active. There is no such rule to activate.
Protected is a claim about the repository, not the document
A decision reaches Protected when a typed rule exists on it. A decision reading “do not call boto3 directly from application code”, carrying a recorded FORBID_LITERAL boto3 rule, comes back Protected, and the Audit reports the guardrail it verified rather than repeating the decision’s own claim about itself.
This is the state most often assumed and least often true. A team that has written the decision down, agreed it, and referenced it in onboarding has changed nothing about what an agent can do. Protected is the only state that describes the repository rather than the decision, which is why it is the only one that cannot be improved by editing prose.
Mneme-ready means the guardrail is written, not running
When a decision records a single significant term, the Audit can state the guardrail without interpretation. An anti-pattern of orm yields FORBID_LITERAL orm. An anti-pattern of litellm yields FORBID_LITERAL litellm. The rule is emitted, and you can read it before anything acts on it.
The word doing the work in that sentence is emitted. Mneme-ready decisions are not protected. The Audit has produced a candidate guardrail and is waiting for a person to validate and activate it, one decision at a time. A repository can have every decision in this state and still reject nothing.
Requires modelling is a scoping problem, not a defect
An anti-pattern recorded as introduce ORM framework carries three significant terms: introduce, orm and framework. There is no single literal that captures it. Forbidding framework would fire across most of the codebase. Forbidding only orm would silently enforce a narrower decision than the one the team agreed.
So the Audit declines. Requires modelling says the intent is genuinely enforceable and the safe decomposition has real choices in it: which terms actually carry the prohibition, which paths it applies to, what the exceptions are. Those are architectural questions with architectural answers, and guessing at them produces rules that fire on innocent code. A guardrail that produces false positives gets switched off, and a guardrail that is switched off protects nothing.
Guidance is an end state, not a backlog
Some decisions should never become literal rules. “Services should be loosely coupled” is real architectural intent with no mechanical predicate behind it. So is a requirement like “all new HTTP APIs are versioned under /v2/”, which sounds far more concrete but records nothing a deterministic check can act on: the word “new” is a temporal qualifier no literal can see, and the requirement is positive rather than a prohibition.
Both return Guidance, and that is the correct answer rather than a limitation. The Audit excludes Guidance from the protection denominator instead of counting it against you, because reporting these as unprotected gaps would imply they ought to have been rules. Most repositories should expect a meaningful share of their decisions to stay here permanently.
What moves a decision between states
For moving deterministic intent toward active protection, two transitions matter most.
Requires modelling becomes Mneme-ready when a person decomposes or scopes the decision sufficiently to express a safe, explicit supported guardrail. The important change is not stronger prose; it is removing the ambiguity that prevented deterministic enforcement.
Mneme-ready becomes Protected when the identified guardrail is activated and deterministic protection is verified. Take the decision whose anti-pattern is orm: Mneme-ready on its own, and Protected once a typed FORBID_LITERAL orm rule exists on it. Same decision, same wording, different repository state. Nothing about the document changed.
Neither transition is automatic, and nothing here implies every Requires modelling decision is expected to reach Protected. Some record intent complicated enough that decomposing it is never worth the effort against how often that code path changes, and staying at Requires modelling is a legitimate resting place, not a stalled one.
Guidance is deliberately absent from that list. A Guidance decision moves only if someone decides it was recording deterministic intent all along and writes that intent down explicitly. That is occasionally right and usually not, and there is no version of a healthy repository in which every Guidance decision has been converted into a rule.
Three things that do not make a decision Protected
- The decision existing. A written, agreed, well-argued ADR with no typed rule on it is not Protected, however many people signed off on it.
- Mneme being installed. Installation enables nothing by itself. Activation is per decision and deliberate.
- The Audit proposing a guardrail. Mneme-ready means the rule has been written out for you to read. It is not running, and it rejects nothing until you activate it.
Each of these is a way of mistaking intent for enforcement, which is the confusion the four states exist to make impossible to sustain.
The Architecture Protection Audit reads the decisions a repository has already recorded and reports which are Protected, which are Mneme-ready, which require modelling, and which should stay Guidance.