Architecture Protection Audit Methodology
The Architecture Protection Audit examines architectural intent already recorded in a repository, determines which decisions have a deterministic protection path, and reports how much of that protection is active today. This page explains what the Audit reads, how decisions are classified, how its metrics are calculated, and what the results do — and do not — mean.
1. What the Audit examines
The Audit works from architectural intent that has been recorded in the repository. It does not ask a model to read the whole codebase and infer what the architecture ought to be.
The hosted Audit currently reads four kinds of source:
- Canonical Mneme ADRs, imported through Mneme's own decision import.
- Supported loose ADR formats, discovered in recognized ADR locations rather than by treating every Markdown file in the repository as an architectural decision.
- Agent instruction files, such as
CLAUDE.mdandAGENTS.md. - Selected project and configuration evidence.
Loose ADR discovery is deliberately constrained. A file has to sit in a recognized ADR location and match a recognized shape before the Audit will treat it as a decision, because a scan that promotes every Markdown file to architectural intent produces a decision count nobody can act on.
The Audit evaluates intent that has been recorded. It does not decide whether your architecture contains every decision it ought to contain.
How code is handled: Repository source is processed under Mneme’s documented data-handling model. See Security & Data Handling for processing, retention and infrastructure details.
2. The unit being classified
The unit is a single architectural decision, carried with its provenance.
Each classified decision retains the source file it came from and its location within that file, the classification and its confidence, the paths the decision applies to where those are known, and a concrete proposed guardrail when one can be safely represented. That per-decision record is what the summary counts are computed from, which is why the summary can always be traced back to the decisions that produced it.
3. How the four states are assigned
The Audit resolves each decision in a fixed order: does the recorded decision carry deterministic intent at all, does protection for it already exist, can a concrete guardrail be represented without guessing, and if not, is the gap a modelling problem or a sign that the decision should stay contextual.
| State | Methodology definition |
|---|---|
| Protected | Deterministic intent already has verified supported protection represented by an existing typed rule. |
| Mneme-ready | A concrete supported guardrail can be represented from the recorded decision without guessing, but it is not yet active protection. |
| Requires modelling | Deterministic intent exists, but the Audit cannot safely turn it into a supported guardrail without further modelling. |
| Guidance | The recorded intent does not have an appropriate deterministic enforcement shape and should remain contextual guidance. |
For worked examples of why two apparently similar decisions can land in different states, see Four Architecture Protection States for AI Coding Agents.
4. How the metrics are calculated
Two figures are reported, and both are shares of the protection-relevant set rather than of every decision discovered.
Guidance is excluded from the denominator: the Audit does not currently treat those decisions as candidates for deterministic protection. Including them in the denominator would treat contextual decisions as though they were missing protection and would distort the metric.
Both figures are stored as fractions and presented on the page as percentages. Where a repository has no protection-relevant decisions at all, both figures are reported as zero rather than as an undefined ratio.
A worked example. A repository returns ten discovered decisions: three Protected, two Mneme-ready, one Requires modelling, four Guidance.
The four Guidance decisions appear in the discovered count and in the report, and they are not counted against the protection figure.
5. What makes a result reproducible
An Audit result is a snapshot of a specific evaluated repository state, with a commit SHA where Git provenance is available, produced by a specific version of Mneme.
Each persisted result carries the repository identity, the commit SHA where Git provenance is available, the Mneme version that produced it, the timestamp, the summary counts, and the decision-level records those counts were derived from. The summary counts are computed from the per-decision records when the result is produced, so the reported protection figures can be recomputed from the decisions in the same result.
For a saved project, re-auditing a changed repository creates a new immutable snapshot rather than rewriting the previous result.
6. What the Audit does not measure
- It does not determine whether the architecture itself is good, or whether the right decisions were made in the first place.
- It does not claim that architectural drift has already occurred.
- It is not generalized code review, security scanning, vulnerability detection or test coverage analysis.
- It does not assume every architectural decision should become a deterministic rule.
- A higher Current Protection figure is not a general software quality score.
A repository can therefore score highly while still containing poor architectural decisions. The Audit measures protection of recorded intent, not the quality of that intent.
7. What happens after the Audit
The Audit identifies the protection state. It does not activate protection itself.
Mneme-ready does not become Protected merely because Mneme is installed. Protection is counted when the relevant guardrail is active and verified. The mechanics of that step are documented in protection activation, and the way the four states behave in the product is covered on the ADR enforcement page.
See the methodology applied to your repository. Run the Architecture Protection Audit to see the underlying decisions, classifications and protection metrics for your own repository. Run Architecture Protection Audit · See worked classification examples →
Frequently asked questions
How is Architecture Protection calculated?
Current Protection is the number of Protected decisions divided by the number of protection-relevant decisions, where protection-relevant means Protected plus Mneme-ready plus Requires modelling. Identified Mneme Potential is Protected plus Mneme-ready over the same denominator. Both are reported as shares of the protection-relevant set, not of every decision discovered.
Why is Guidance excluded from the denominator?
Guidance means the recorded decision does not currently have an appropriate deterministic enforcement shape. It is excluded from the denominator because the Audit does not count contextual guidance as missing protection.
What does Mneme-ready mean?
Mneme-ready means a concrete supported guardrail can be represented from the recorded decision without guessing, but that guardrail is not active protection yet. The Audit reports the proposed rule so it can be read and validated before anything acts on it.
Does the Architecture Protection Audit detect architectural drift?
No. The Audit examines architectural intent already recorded in the repository and determines how much of it has a deterministic protection path. It does not scan history for past deviations and does not claim that drift has already occurred.
Does a high Architecture Protection score mean the architecture is good?
No. The Audit measures protection of recorded intent, not the quality of that intent. A repository can score highly while still containing poor architectural decisions, because the metric describes how much of what was written down is deterministically protected, not whether the right things were written down.