Check AI Coding Assistants Against One Decision Corpus per Repository
Every team has their own .cursorrules, their own system prompts, their own interpretation of the standards. Mneme HQ gives each repository one structured decision corpus, which the agent hooks, the local Model Context Protocol (MCP) server and the continuous integration (CI) check all read.
Rules sprawl is the hidden cost of AI-assisted development.
Every team maintains separate Cursor Rules, CLAUDE.md, and system prompts
Fragmented rule files multiply across repos and teams. No team knows what the others have defined.
No single source of truth for what the AI "knows" about your architecture
Each agent operates on a different subset of standards. Outputs diverge in ways that are hard to trace back.
Prompt templates diverge over time: no versioning, no conflict resolution
Templates are copied, modified, and forgotten. There is no audit trail and no way to know which version is current.
Onboarding new teams to AI coding means re-documenting the same standards
Platform teams repeat the same setup work for every new team. Mneme does not solve this one yet: it has no way to distribute decisions across repositories, so org-wide architecture decision records (ADRs) are copied into each repository by hand.
One corpus per repo. Hooks where agents write. CI on every pull request.
Single source of truth
.mneme/project_memory.json is the repository's decision record, compiled from your ADRs and read by the command-line interface (CLI), the agent hooks and the MCP server. One file per repository. One place to update.
Scoped rules
The typed rule that can fail a check and respect paths is an exact text ban (FORBID_LITERAL), which Mneme checks mechanically, not as guidance. It can carry path selectors such as payments/**, so a payments rule fails a write under payments/ and passes the same text in analytics/. Agents look up the decisions for a task or a file path.
Conflict resolution
ADR import settles overlap by fixed rules: supersession, then priority within a scope, then date. A tie those rules can't break stops the import, so a person decides.
Enforcement where agents write
Hooks in Claude Code, Codex CLI and Kiro CLI 3.0 check a supported write before it reaches disk. A supported write is a file change made through the agent's own edit tool: Edit, Write and MultiEdit in Claude Code, apply_patch in Codex CLI, native writes in Kiro CLI 3.0. Agents without a hook, such as GitHub Copilot, meet the CI check on the pull request. Each developer still installs the runtime and the hook.
Where does your platform repository actually stand?
Before rolling a decision corpus out across teams, audit one platform repository: which platform rules are enforceable today, and which still depend on someone reading the docs.
Built for platform and governance use cases.
AI Coding Assistant Governance
Check each AI coding assistant's changes against your repository's decision corpus, through its hook where it has one and through CI where it doesn't.
Read use case →Multi-Agent Workflow Governance
Maintain consistent standards across orchestrated multi-agent pipelines where multiple models collaborate on the same codebase.
Read use case →How platform teams roll this out
We suggest three tiers of ownership. Each tier belongs to a different part of the org, and all three end up as ADRs in the repository the agents work in.
Tier 1: org-wide policy. A small set of decisions every repo should carry: approved dependencies, security patterns, observability conventions. Owned by platform / security. Mneme has no cross-repository import yet, so the platform team copies these ADRs into each repo's docs/adr folder with the highest priority value, foundational (above normal and exception), and each repo imports them.
Tier 2: team architecture. Service boundaries, language and framework choices, data-access patterns. Owned by the team that operates the service. Lives in the repo's own ADRs, compiled into its project_memory.json.
Tier 3: exceptions. Mneme 0.10.0 has no waiver or override record, and nothing expires. You write an exception as an ADR change: an exclude_paths selector on the broader rule, or a new ADR that supersedes it. The engineer making the change owns it, and the team reviews it in the pull request like any other diff. Mneme does not record who approved it, so that review is your approval record.
When you import ADRs, Mneme resolves overlap in a fixed order. An explicit supersedes link retires the older decision. When two accepted ADRs share a scope, the higher priority wins, then the newer date, and Mneme stores the other as inactive and stops enforcing it. A narrower scope does not override a broader one: both stay active and both are checked. Resolving which decisions govern a change across org, team and exception layers is a planned resolution design, not part of any release. Today you get one reviewed corpus per repository, which agents can read over MCP, hooks check before supported writes, and CI checks on every pull request.