Architecture Protection Audit vs Code Review, Security Scanning and Tests
Code review, security scanners and tests are essential engineering controls — and they inspect different properties of software than the Architecture Protection Audit does. This page sets out what each examines, what each produces, and where the Audit and Mneme enforcement fit alongside them. It is a comparison of scope, not a claim that any layer replaces another.
1. Different tools answer different questions
Those tools inspect different properties of software. The Architecture Protection Audit examines architectural intent already recorded by the team and asks whether that intent has a deterministic protection path.
That is the whole of what the Audit adds, and it is deliberately narrow. It is not code review, security scanning, vulnerability detection or test-coverage analysis — the methodology page states that boundary in canonical form, and this page explains what the boundary means when you already run the other controls.
2. Side-by-side comparison
| Capability | Primary question | Typical evidence or result | Does Mneme replace it? |
|---|---|---|---|
| Code review | Should humans approve this change? | Diff, reviewer judgment, comments, approvals | No |
| Security scanning | Does code or configuration match known security risks, vulnerabilities or security policies? | Findings, severities, policy violations | No |
| Tests | Does implemented behavior satisfy the expectations encoded in tests? | Pass/fail test results | No |
| Architecture Protection Audit | Which recorded architectural decisions have a deterministic protection path, and which are already protected? | Protected / Mneme-ready / Requires modelling / Guidance | — |
| Mneme enforcement | Does this proposed change violate an active encoded architectural decision? | Allow / warn / block evidence | Complements the above |
The fifth row matters. The Audit and enforcement are deliberately not collapsed together. The Audit identifies and classifies decisions; Mneme enforcement protects them, and only after an explicit activation decision. A classification is a measurement; a blocked change is an enforcement action. The methodology documents how the four states are assigned and how a Mneme-ready guardrail becomes counted protection, and the ADR enforcement page shows how the four states behave in the product.
3. Why tests are not architecture protection
A service may pass every functional test while introducing a dependency that violates an ADR. Conversely, a dependency rule can be perfectly respected while the software still fails its tests. These are different properties.
Tests can enforce architecture when teams deliberately write them to do so. The distinction is that the Architecture Protection Audit starts from recorded architectural decisions and asks systematically which of them have deterministic protection, rather than assuming the test suite represents the architecture. A suite assembled feature by feature rarely maps cleanly onto the decision record, and nothing in a normal test run reports which architectural decisions it happens to cover.
4. Why code review is not deterministic architecture enforcement
Code review remains a judgment layer. Reviewers can reason about trade-offs, context and architectural changes that should not be reduced to deterministic rules. Mneme complements that judgment by making selected architectural constraints mechanically checkable before or alongside review.
That complement goes both ways. Decisions the Audit classifies as Guidance should stay exactly where they are — in the reviewer's head, applied with context. Turning every recorded decision into a mechanical check would be a worse outcome than leaving it to judgment, which is why the Audit treats contextual decisions as guidance rather than as missing protection.
5. Why security scanning is a different layer
Security scanners answer security questions: known vulnerabilities, unsafe patterns, dependency risk, secrets, policy violations and related controls. Those tools are essential, and enterprise scanners often support custom policy that goes a long way.
But the problem definition is different. An architectural decision such as “service X must not depend directly on package Y” may have nothing to do with security. The Architecture Protection Audit starts from the team's own architectural intent rather than from a vulnerability catalogue, and its evidence model reports the state of recorded decisions rather than findings against code. Mneme can enforce encoded architectural rules that have security implications, but Mneme is not a vulnerability scanner or a general security-analysis product.
6. Where the Architecture Protection Audit fits
This is not a stack diagram with Mneme sitting above everything. The Audit and the enforcement layer it feeds run alongside review, scanners and tests — the same change can flow through a pull request, a scanner, a test suite and an architectural guardrail at the same time.
7. When you need more than one
Every normal engineering organization should use these together. Review approves changes, scanners and tests protect the properties they are built for, and the Audit answers the question the others do not ask: how much of the architecture your team has written down is actually protected, and where the gaps are. Once you have that answer, the gaps become a modelling and activation plan rather than a general worry about “keeping the architecture healthy”.
The Architecture Protection Audit does not determine whether the architecture itself is good. It does not detect vulnerabilities, replace tests, or approve pull requests, and it does not claim that architectural drift has already occurred.
See which architectural decisions your existing controls protect. Run the Architecture Protection Audit against a repository to identify which recorded decisions are already Protected, which have a Mneme-ready guardrail, and which still require modelling. Run Architecture Protection Audit · Read the methodology →
Frequently asked questions
Does Mneme replace code review?
No. Mneme makes selected architectural constraints deterministic; reviewers still handle judgment, design trade-offs and changes that should remain contextual.
Can tests enforce architecture?
Yes, if teams explicitly encode architectural constraints into tests. The Audit instead starts from recorded architectural decisions and measures which currently have a deterministic protection path.
Is Mneme a security scanner?
No. Mneme can enforce specific encoded architectural rules, including rules with security implications, but it is not a vulnerability scanner or general security-analysis product.
Why use an Architecture Protection Audit if we already have CI?
CI is an execution environment. The Audit identifies which recorded architectural decisions actually have deterministic protection that CI or agent integrations can execute.