AI coding governance should be reviewable. Most AI memory is hidden state — cloud vector stores, opaque embeddings, IDE-local configuration that no one can audit. Mneme treats governance differently: architectural decisions are version-controlled files that travel with the repository, can be diffed in a PR, and are subject to the same review process as the infrastructure they govern.
Architecture 7 min read · May 2026

# AI Coding Governance Should Be Reviewable

Traditional AI memory is hidden state. Mneme treats governance as versioned engineering infrastructure. That distinction is not aesthetic — it changes what teams can audit, reproduce, and trust.

By Theo Valmis · Published May 2026

When something goes wrong with an AI coding agent — a banned framework gets introduced, a cross-boundary call slips into production, a deprecated pattern resurfaces after three ADRs told the team to stop using it — the first question an engineering lead asks is: what was the agent operating under when this happened?

With most current AI tooling, you cannot answer that question. The constraints the agent was aware of exist somewhere in accumulated prompt history, a cloud memory service, or per-session context that was never persisted. The governance state is opaque. The incident is unreproducible. The audit trail is empty.

This is not an edge case. It is the default condition for AI coding governance today.

## The assumption most teams haven't questioned

AI memory, as most tools implement it, inherits its design from consumer AI assistants: hidden embeddings, cloud persistence, black-box retrieval, state that accumulates behind an API. The mental model is a human assistant who "remembers" things. The implementation is a vector database that approximates similarity.

That model made sense for knowledge lookup. It makes no sense for engineering governance.

We do not accept hidden state in the rest of our engineering infrastructure. Terraform files are version-controlled. Kubernetes manifests are reviewed in pull requests. CI pipeline configuration is committed alongside the code it governs. The principle is consistent: if it controls how software is built and deployed, it should be visible, versioned, and reviewable.

AI coding governance controls how software is built. It should be held to the same standard.

## What reviewable governance actually means

Reviewable governance is not just "we can read the config." It is a set of properties that the governance state must have for engineering teams to trust and maintain it:

- Versioned. Every change to a constraint has an author, a timestamp, and a commit message. You can answer: who added this rule, when, and why.
- Diffable. When architectural decisions change, the change is visible as a standard file diff. Engineers can see exactly what shifted between the last governance state and the current one.
- Reviewable in a PR. New constraints, superseded decisions, and rule updates go through the same review process as the infrastructure they govern. The team can debate, approve, or block a governance change before it takes effect.
- Co-located with the repository. The governance state lives next to the code it governs. It is not in a separate cloud service or in an IDE's local config. When you clone the repo, you get the governance state. When you branch the repo, the governance state branches with it.
- Auditable after the fact. If a violation occurs, you can check out the exact commit where the agent was operating and read the constraints it was applying. The incident is reproducible. The investigation has evidence.

The key reframe: governance state is not AI memory. It is engineering infrastructure. It should be treated accordingly — version-controlled, reviewed, and auditable — not hidden in a cloud service your team cannot inspect.

## How this differs from current approaches

The contrast with existing approaches is concrete:

Approach | Governance state lives where? | Mneme
--- | --- | ---
Generic RAG memory | Cloud vector store. No authorship, no versioning, probabilistic retrieval. | Structured JSON in the repository. Version-controlled in git. Reviewed in PRs. Co-located with the code it governs. Travels with branches and forks.
Hidden cloud memory | Opaque API-backed store. Invisible to the team. Unauditable by design.
Prompt accumulation | Session history. Forgotten between sessions. Inconsistent across agents.
IDE-local state | Per-machine config. Not shared. Does not travel with the repo.

None of these approaches produce governance state you can review in a pull request. None of them produce governance state that branches when your codebase branches. None of them produce governance state an auditor can examine six months after an incident.

## Repo-native governance as engineering infrastructure

Mneme stores its governance state as a structured JSON file — `project_memory.json` — co-located with the repository it governs. The file contains architectural decisions, constraints, and prior decision records in a format that is human-readable, machine-executable, and version-controlled.

This is not a clever trick for working around vector databases. It is a deliberate architectural commitment to a different model of what governance state is.

// project_memory.json (excerpt) — lives in the repo, versioned in git { "decisions": [ { "id": "adr-014", "title": "Data platform calls belong in backend services only", "constraints": ["no BigQuery client in frontend routes"], "supersedes": [], "status": "active" } ] }

When a new ADR supersedes an old one, the change is a pull request. Reviewers can see exactly what constraint was removed, what replaced it, and why. The governance history is the git history.

## Why this matters for enterprise trust

The reviewability property connects directly to the concerns that block AI coding adoption at the enterprise level:

- Compliance and audit. Regulated industries require an audit trail for decisions that affect production systems. Governance stored in git satisfies this. Governance stored in a cloud vector store does not.
- Deterministic behavior. If the same query always retrieves the same constraints, behavior is reproducible. If retrieval is probabilistic, the same task may be governed differently on different days — which is not a property enterprises can accept in production AI workflows.
- Multi-agent consistency. When multiple agents — Claude Code, Cursor, a CI governance gate — operate against the same repository, they all draw from the same governance file. There is no per-session state drift, no agent-local divergence, no inconsistency between what the IDE agent allowed and what the CI gate blocks.
- Governance state travels with the repo. When a team forks the codebase for a new product line, the governance state forks with it. When a contractor clones the repo, they get the constraints. When an agent runs in CI on a branch, it applies the branch's governance state.

## Governance decisions are infrastructure decisions

The deeper principle here is architectural. Governance decisions — "we use Pub/Sub, not Celery," "BigQuery clients live in backend services," "no raw SQL string concatenation in production paths" — are engineering decisions with the same authority and permanence as the infrastructure decisions they constrain. They should be stored with the same discipline.

Treating AI constraints as ephemeral prompt context is the wrong mental model. Treating them as version-controlled engineering infrastructure — subject to review, authorship, and audit — is the right one.

Most teams haven't confronted this distinction yet because they're still in the early phase of AI coding adoption, when the volume is low enough that opaque governance is survivable. As agent usage scales, the distinction will become unavoidable. Unreviewed governance state will produce unauditable violations. Opaque constraints will produce irreproducible incidents. Hidden AI memory will produce engineering debt that no one can trace.

The time to establish the right model is before that debt accumulates — not after it.

← Back to Insights

### See the governance file in practice

Browse the open-source `project_memory.json` format and watch Mneme enforce it against a live AI prompt.

Watch the demo

## Frequently asked

What does it mean for AI governance to be reviewable?
Reviewable governance means the constraints an AI agent operates under are stored as structured, version-controlled files that engineers can read, diff, and review in a pull request — exactly like infrastructure configuration. When a rule changes, the change is visible in git history with authorship, context, and rationale.
Why is opaque AI memory a governance problem?
When AI governance state is hidden — in a cloud vector store, accumulated prompt history, or IDE-local configuration — there is no way to audit what constraints the agent was operating under when a violation occurred. You cannot review what you cannot see, and you cannot enforce what you cannot version.
How does Mneme store governance state?
Mneme stores governance state as a structured JSON file (`project_memory.json`) co-located with the repository it governs. The file travels with the repo, is version-controlled in git, and can be reviewed, diffed, and approved in a pull request like any other infrastructure-as-code artifact.
Does repo-native governance work for multi-agent teams?
Yes — and it has a significant advantage over agent-local or cloud-opaque memory. All agents operating against the same repository draw from the same version-controlled governance file, producing consistent, reproducible constraint enforcement. There is no per-session state drift.
How is this different from just committing a Cursor Rules file?
Rules files document standards as free-text prompts. Mneme's governance file is a structured decision graph with precedence, scope, supersession, and status fields. It is machine-executable, not just human-readable — Mneme enforces it deterministically at every AI call, rather than hoping the model reads and respects a text file it was given once.
ï»¿