Mneme HQ
Mneme is an open decision and control layer for agentic software development.
It turns durable engineering decisions into agent context, deterministic enforcement, and inspectable enforcement results across AI coding agents, repositories, and CI workflows. Architecture is the first supported decision domain: Mneme prevents architectural drift by turning architectural decisions and ADRs into deterministic guardrails across coding agents, repository mutations, generated rules, and CI gates.
Where is your architecture actually enforced? Run the Architecture Audit to see which decisions are protected, which can become deterministic guardrails, and which still depend on someone remembering the rules. Try it →
Mneme is the decision layer behind that drift-prevention mechanism. It keeps recorded engineering decisions active as AI coding systems propose and modify code, instead of leaving ADRs as passive documentation.
Solid surfaces ship today; dashed surfaces are planned. Support levels per integration: integrations matrix.
Current phase: Layer 1 validation. Retrieval, enforcement, and benchmark semantics are governed by the accepted architecture and freeze record. See Current Phase before changing core behavior.
What Mneme does
Mneme separates architectural guidance from deterministic enforcement:
- Records architectural decisions in a structured, auditable decision corpus.
- Retrieves relevant decisions when an agent or model needs architectural guidance.
- Enforces governed rules deterministically under explicit applicability semantics.
- Integrates at the earliest reliable boundary exposed by each coding workflow.
- Audits bypassable mutation paths where pre-change blocking is not technically available.
- Runs in CI as a final deterministic gate before incompatible changes are accepted.
The same input and governed decision state produce the same enforcement result. Mneme does not depend on an LLM judge for its core allow/warn/fail decisions.
Mneme is not a general-purpose vector store, conversational memory system, autonomous coding agent, or deployment observability platform.
Install
Requires Python 3.11+.
pip install mneme-hq
Verify the CLI:
mneme --help
For repository development:
git clone https://github.com/MnemeHQ/mneme.git
cd mneme
pip install -e ".[dev]"
Decision MCP
Mneme exposes the Decision Index over a local MCP server so MCP-capable clients can propose candidate architectural decisions and query decision state without gaining authority to change that state.
Install the optional MCP dependency:
pip install "mneme-hq[mcp]"
Start the local stdio server. Canonical reads come from the persisted Decision Index in .mneme/project_memory.json by default; the proposal store remains separate.
mneme decision-mcp
Use --memory to select another project memory file. The file must contain a valid authoritative decision_index section; MCP fails closed rather than reconstructing authority from the compatibility decisions[] snapshot.
mneme decision-mcp --memory path/to/project_memory.json
Memory created by mneme init or mneme setup already carries an empty decision_index section and needs no migration. An older file with no decision_index section yet makes MCP stop with an error that tells you to migrate. Preview the migration first. It writes nothing and lists the visible effects: non-active decisions leave Layer 1, and legacy rule/anti_pattern items are migrated once.
mneme decision-index migrate --memory path/to/project_memory.json
Then apply exactly that migration:
mneme decision-index migrate --memory path/to/project_memory.json --apply
Migration is lossless or it refuses. There is no force or repair mode. Memory containing legacy decision metadata that the canonical index cannot represent, such as EventCatalog-imported decisions, stays on the section-less path and is not migrated.
--adr-dir is now optional validation input only. Mneme still validates and precedence-resolves that corpus before startup, but ADRs do not become a second MCP authority source.
mneme decision-mcp --memory path/to/project_memory.json --adr-dir path/to/adrs
The MCP surface is intentionally frozen to six tools:
decision.proposedecision.propose_batchdecision.getdecision.searchdecision.applicable_todecision.trace
Proposal tools create non-authoritative proposals only. Read tools query proposal and canonical decision state. MCP deliberately exposes no accept, reject, activate, supersede, exception, bypass, or trusted-evidence authority.
Human authority remains explicit through mneme decision proposals | show | accept | reject. Accepting a proposal materializes a canonical decision; it does not activate protection or run the Architecture Audit.
See ADR-027 and the v0.9.0 release notes for the authority boundary and release contract.
Architecture Audit
See where your architecture is actually protected — and where it still depends on people remembering the rules.
Mneme audits your repository and shows which architectural decisions are:
- Protected — already enforced mechanically
- Mneme-ready — can be turned into a deterministic guardrail
- Requires modelling — important, but not yet safe to automate
- Guidance — useful context, but not something that should be enforced
Run an audit:
mneme audit --memory .mneme/project_memory.json --repo-root .
For a Mneme-ready decision, validate the proposed protection before enabling it:
mneme protect validate <decision-id> --memory .mneme/project_memory.json
Then explicitly activate it:
mneme protect activate <decision-id> --memory .mneme/project_memory.json
Mneme only reports a decision as Protected after it can verify that real enforcement is in place. The full activation contract is documented in Protection Activation.
60-second enforcement example
Initialize a project-local decision corpus:
mneme init
Record one architectural decision:
mneme add_decision \
--memory .mneme/project_memory.json \
--id config-format \
--decision "Use JSON for configuration files" \
--scope config \
--constraint "Use JSON only" \
--anti-pattern "Do not use YAML"
Create a proposed input that violates it:
python -c "import pathlib; pathlib.Path('prompt.txt').write_text('Set up a new YAML config file', encoding='utf-8')"
Run the deterministic check:
mneme check \
--memory .mneme/project_memory.json \
--input prompt.txt \
--query configuration
In strict mode, the prohibited YAML proposal returns a FAIL verdict and exit code 2. A compliant JSON proposal returns PASS and exit code 0.
The CLI is the common enforcement surface. Agent integrations translate their native events into the same Mneme decision and enforcement model.
For a non-authoritative preview of which canonical decisions would apply to
caller-asserted context labels, add an opt-in, repeatable
--applicability-preview <label> to mneme check:
mneme check --memory .mneme/project_memory.json --input prompt.txt --query configuration --applicability-preview platform:windows
The preview prints only on stderr, independently of the normal check
result. It does not trust the supplied labels, exclude decisions, change
enforcement, or change stdout, JSON mneme.check/v1, hook behavior, or exit
codes. Section-less memory or a preview computation error reports
PREVIEW UNAVAILABLE on stderr; it does not migrate memory or weaken
enforcement. This preview is not a security control.
Setup mode (no enforcement)
mneme setup initializes Mneme in a repository without changing how the team works: it creates or detects project memory, detects supported agent environments, and reports protection readiness — all without enabling any blocking enforcement. Setup never turns warn/observe behavior into blocking behavior; activation of preventive enforcement is always a separate, explicit decision.
mneme setup
Optionally record an opaque Architecture Audit reference so the setup can be attributed back to a saved Audit baseline:
mneme setup --audit-ref <reference>
Setup is idempotent: rerunning it against an existing Mneme project leaves valid configuration untouched.
How it works
Architectural decisions / ADRs
|
v
structured decision corpus
|
+-----+--------------------+
| |
v v
relevant guidance deterministic enforcement
retrieval + applicability checks
| |
+------------+-------------+
|
v
workflow-specific boundary
|
+------------+-------------+
| | |
pre-change post-change CI
hooks audit gate
Mneme applies governance at the earliest reliable boundary a workflow exposes:
- Before generation when architectural context can be injected into the model call.
- Before supported file mutations when an agent exposes a blocking pre-tool hook.
- After bypassable mutations through bounded working-tree audits where shell/script writes cannot be inspected safely before execution.
- Before merge through CLI-based CI gates.
These boundaries are complementary. An integration only claims the surfaces that have been implemented and validated for that harness.
Retrieval is not enforcement
Decision retrieval answers: which architectural decisions are useful as guidance for this task?
Enforcement answers: does the proposed change violate a governed rule that applies here?
Those concerns are intentionally separated. See ADR-017, ADR-019, and ADR-020.
Supported surfaces
The authoritative support matrix lives in docs/integrations/README.md. The labels below are evidence levels, not interchangeable marketing terms.
Each integration documents its actual blocking boundary, bypass paths, degraded behavior, and validation evidence. Start with the integration matrix, not assumptions based on another harness.
ADRs and project memory
Mneme can compile architecture decisions into structured governance records rather than treating ADRs as passive prose.
The repository governance source of truth is .mneme/project_memory.json. The ADR import path preserves explicit source provenance where available so typed rules can be inspected and enforced consistently.
See:
Architecture guarantees
Three principles govern the current mechanism:
- Deterministic > clever. Enforcement behavior must be reproducible.
- Auditable > autonomous. A verdict should be traceable to the decision, rule, applicability state, and evidence that produced it.
- Prevention before review. When a reliable pre-change boundary exists, use it; when it does not, surface the limitation and audit later rather than pretending the path is blocked.
The current Layer 1 scope, frozen surfaces, accepted amendments, experimental work, and deferred Layer 2 work are maintained in docs/architecture/current-phase.md.
Do not infer architecture from this README when a linked ADR or architecture document is more specific.
Benchmark and validation
Mneme's benchmark is a regression and integrity instrument for retrieval and enforcement behavior. It is not a general model-quality benchmark.
The benchmark keeps retrieval and enforcement scoring distinct so changes cannot silently improve one surface while regressing another.
See:
Demos
More examples: mnemehq.com/demo
Contributing
Before changing retrieval, enforcement, applicability, conflict handling, or benchmark semantics, read the architecture and ADRs that govern that surface.
Core behavioral changes may require the repository's charter-amendment procedure. Documentation, tooling, integrations, and examples do not automatically authorize changes to frozen behavior.
License
MIT. See LICENSE.