It is a familiar pattern in software infrastructure. Authentication rules do not live inside one HTTP client. Database schemas do not live inside one ORM. Security policies do not live inside one CI runner. The rule has to outlive the tool, because tools turn over and rules are supposed to stay.
AI-assisted development is now reaching the same conclusion about architectural governance. The model the team used in March is not the model they use in November. The IDE they used last quarter is not the one they use next quarter. The agent runtime that runs unsupervised today is not the one that will run unsupervised in a year. If the team’s architectural rules live inside any of those, the rules are coupled to whatever turns over fastest.
The operational definition
Model-independent governance is the property that architectural rules are not embedded inside one model, prompt, IDE, or agent runtime. Governance lives as a repo-native control layer that:
- is evaluated by a deterministic engine, not by the model’s discretion
- applies at every surface where work happens — pre-tool-use hook, pre-commit, CI gate, PR check
- produces the same verdict regardless of which model or harness generated the change
- is version-controlled with the codebase it governs, not with the tool it was last enforced through
Five roles, one of them must outlive the others
An AI-assisted development workflow has five distinguishable roles. Four of them are designed to be swappable. Only one of them is the system of record.
If governance lives in roles 01–04, the team has to re-encode it on every migration and accept inconsistency in the meantime. If governance lives in role 05, the migrations cost what they should cost — the work of swapping a tool — and the architectural rules survive intact.
The repo is the system of record. The model is an execution engine. The agent is an operator. The IDE is a surface. Governance belongs outside all of them.
The same verdict, at every surface
Model-independent governance is testable. The test is: does the same proposed change produce the same verdict across every surface that touches it?
Each surface is wired to the same governance engine consulting the same repo-native corpus. A change that violates ADR-007 at the pre-tool-use hook in Claude Code violates ADR-007 at the CI gate when GPT-driven CI tries to commit the same diff, and violates ADR-007 at the PR check no matter which agent opened the PR. The model and the runtime do not affect the verdict.
Provider lock-in vs governance lock-in
The conversation about "lock-in" in AI infrastructure usually focuses on the API. That is the visible cost — multi-provider routing, fallback chains, vendor diversification. There is a second, less visible kind of lock-in that is more expensive to discover later.
- Which provider hosts the model
- Solved by multi-provider routing
- Cost: medium — SDK rewrites, retesting
- Mostly an integration concern
- Where the team’s architectural rules actually live
- Not solved by routing — the rules are model-coupled
- Cost: high — rules must be re-encoded per migration
- A continuity concern across model and tool changes
Teams can address provider lock-in and still carry governance lock-in if the rules are encoded inside one model’s prompts or one IDE’s configuration. Model-independent governance closes the second gap.
How it differs from adjacent concepts
Versus a CLAUDE.md or AGENTS.md. Those files are model-coupled by design — they live in the runtime’s prompt loading, not in the repo’s enforcement layer. They are useful and they remain useful; they do not produce a deterministic verdict at the CI gate.
Versus an LLM wiki. An LLM wiki is a knowledge surface. Model-independent governance is a control surface. The wiki helps any model read the same context; governance enforces the same verdict regardless of which model read it.
Versus orchestration framework rules. Orchestration constrains the order of work. Governance constrains what the work is allowed to do. They sit at different layers of the AI operating layer — orchestration is model-aware by necessity; governance does not need to be.
Governance should outlive the model. If the rules survive only as long as the runtime that taught them, governance is a feature of the tool, not a property of the system.
How Mneme implements it
Mneme is a repo-native, model-independent governance layer. Architectural intent is encoded in a version-controlled corpus, retrieved through a deterministic scoping layer before agents generate, and validated at the hook and CI levels after generation. The same corpus and the same engine drive every enforcement surface — Claude Code today, a different harness tomorrow, a different model the day after.
The rules do not live in the prompt. They live in the repo. That is the property that makes them survive the next migration.