Give Mneme a repository. It identifies architectural decisions, classifies their protection level, and shows exactly which ones have deterministic Mneme guardrails — plus where protection gaps remain.
An Architecture Protection Audit examines the architectural intent already documented in a software repository and determines how much of that intent is deterministically protected. It discovers decisions in ADRs, agent instructions, architecture documentation and configuration evidence, then classifies each decision as Protected, Mneme-ready, Requires modelling or Guidance.
The Audit is the first application of Mneme's decision model. Architecture is the first decision domain, and the Audit classifies each architectural decision it discovers as Protected, Mneme-ready, Requires modelling, or Guidance, so you can see which are deterministically protected today.
It is not a code review, security scanner or post-mutation Stop audit. It does not claim that architectural drift has already occurred. It identifies which architectural decisions can be protected against future AI-generated drift and what is required to protect them.
The Audit identifies and classifies architectural decisions; it does not itself enforce them.
Audit identifies what can be protected; Mneme guardrails provide the protection.
No GitHub OAuth required for MVP. OAuth and GitHub App come later.
How code is handled: Repository code is temporarily processed on Mneme’s servers to perform the Audit. Uploaded ZIPs and extracted code are deleted when processing finishes; Mneme retains the resulting Audit record.
Repository privacy & security
Repository material is processed deterministically by Mneme's open-source engine, is never sent to an external AI model provider, and original files are deleted when the audit completes. See exactly how the Audit processes, stores and deletes repository data — before you submit.
Security & data handling →ADRs, CLAUDE.md, AGENTS.md, architecture docs, config files — every source of architectural intent in the repository.
Each decision rated: Protected, Mneme-ready, Requires modelling, or Guidance.
See the exact deterministic Mneme guardrail where one exists (e.g., FORBID_LITERAL).
Decisions that aren't yet protected — with specific next steps: modeling needed, or a Mneme-ready guardrail ready to validate and activate.
Download the full audit as Markdown or JSON to share with your team or design partners.
This audit is the artifact you send after a design-partner call — concrete evidence of where their architecture is ambiguous to AI agents.
How the four protection states work → · How the Audit methodology and protection metrics work → · How the Audit differs from code review, security scanning and tests → · Auditing private code? See our data-handling model →
M1 adds durable project identity so the audit is no longer a one-off report. Teams can now track protection improvement over time.
Run an Architecture Protection audit against any repository. Get baseline protection metrics and identified guardrails.
Persist the audit as a project baseline with repository URL, commit SHA, Mneme version, and timestamp. Baseline is immutable.
Validate the guardrail without changing anything, activate it explicitly, then Mneme verifies that enforcement is really in place before counting the decision as Protected. "Requires modelling" gaps still need modelling first — activation is one decision at a time.
Run a re-audit against the new repository state. Creates a new immutable snapshot linked to the same project.
Baseline vs. latest comparison shows: Architecture Protection delta (e.g., 20% → 60%), newly Protected decisions, new guardrails, regressions, added/removed decisions. All computed server-side from canonical P1.2 evidence.
Illustrative example: a team starting at 20% protection (1 of 5 decisions Protected) activates 2 Mneme-ready guardrails and reaches 60% (3 of 5 Protected), after Mneme verifies both protections. Results vary by repository.
Don't say:
"Mneme found architectural drift."
The audit asks:
"Can this architectural intent be deterministically protected from AI-generated drift?"
You don't have generalized drift detection yet. The audit is valuable precisely because it answers a narrower, answerable question — and that answer is what Mneme actually does today.
Want to see what the answer looks like before running it? The ADR compiler demo takes one written decision and shows it becoming an executable constraint, and how AI coding agents use ADRs explains the ignored, advisory, and enforced progression the audit is measuring against.