Every engineering team that adopts an AI coding assistant goes through the same evolution. The first sessions produce inconsistent output. Naming conventions get ignored. Service boundaries blur. Approved dependencies get substituted for whatever the model prefers.

The natural response is to write it all down. A CLAUDE.md file in the repo root. A system prompt injected at session start. A context block prepended to every request. "Use PostgreSQL, not SQLite. Services must not call each other directly. All data access goes through the repository layer." The rules are all there. The AI reads them. The sessions improve.

For a team of two, on a codebase that is six months old, this works well enough to feel like a solution. It is not.

What context injection actually is

CLAUDE.md files and system prompt injection are forms of static context. At session start, a block of text is prepended to the model's context window, and the model is asked to respect it for the duration of the session. The rules exist as natural language instructions, and compliance depends on the model interpreting them correctly and consistently.

This is a useful technique. It is also fundamentally different from governance memory. The distinction matters:

Context injection
Static, textual, advisory
Rules exist as natural language in a file. The model reads them at session start. Compliance is probabilistic. Nothing enforces them.
Governance memory
Structured, precedence-aware, enforced
Decisions are stored as typed records with metadata, scope, and precedence. They are injected at the moment of generation and enforced at hook level.

Teams using CLAUDE.md as governance are solving a real problem with the wrong tool. They feel the friction of inconsistency and add more rules. The file grows. The problem does not go away.

The four failure modes

Context injection breaks down in predictable ways. Each one compounds as the codebase ages and the team grows.

Failure progression
01
Context window pressure
Every token of injected rules competes with the actual task. A 3,000-token context block on a complex refactoring session degrades output quality and increases inference cost. Teams discover this when their CLAUDE.md hits 500 lines and sessions start feeling slower and less accurate.
02
Maintenance lag
The codebase evolves. The CLAUDE.md does not. An architectural decision made in January is still in the file in October, but the decision was superseded in March and nobody updated the context file. The model enforces a rule that no longer applies. The team writes the old pattern and wonders why review keeps flagging it.
03
No precedence engine
Rules accumulate and eventually conflict. Rule 14 says all async operations use the task queue. Rule 47 says new notification services can call external APIs directly. Both are in the file. The model must resolve the conflict using natural language interpretation. Sometimes it picks correctly. Sometimes it does not. There is no structured way to express that one rule supersedes another in a specific scope.
04
Enforcement is advisory only
The model can read the rules. It cannot be compelled to follow them. Every instruction in a CLAUDE.md is a suggestion. If the model's strongest signal for a given generation task contradicts the context file, the context file loses. Governance that depends on probabilistic compliance is not governance.

The session boundary problem

There is a fifth failure mode that affects every team eventually: context injection does not persist.

Each new session starts from zero. The CLAUDE.md is re-read, the system prompt is re-injected, and the model re-learns the rules. There is no continuity. The AI assistant has no memory of why a decision was made, what alternatives were considered, or which rule takes precedence when two rules conflict on this specific class of problem.

This is not a solvable problem within the context injection paradigm. It is a structural limitation. A text file cannot carry the reasoning that an architectural decision record contains. "Use the repository pattern" cannot communicate what a decision record communicates: who made this decision, when, why, what alternatives were rejected, which services it applies to, and when it was last reviewed.

The session boundary problem amplifies with team size. Two engineers sharing a CLAUDE.md can manually coordinate. Ten engineers, three repositories, and eighteen months of accumulated decisions cannot. The file becomes a maintenance problem before it becomes a governance solution.

Why large codebases expose the limits faster

Context injection can feel adequate on a small codebase because the failure modes are invisible. The team knows the rules well enough to catch violations in review. The file is short enough to maintain. The decisions are recent enough to still be accurate.

Scale breaks these compensating factors in order:

  • At 3 engineers, the team can remember the rules that the file does not capture.
  • At 8 engineers, the institutional knowledge is distributed and unreliable. The file is the only canonical source, and it is already stale.
  • At 20 engineers across 5 repositories, there is no single file that covers all relevant decisions. There are multiple files, possibly conflicting, with no defined precedence relationship between them.
  • At AI-assisted velocity, the problem compounds faster. A team generating code at 10x human pace needs governance that operates at 10x human pace. A text file maintained by engineers does not scale with AI output.

What governance memory actually requires

The teams discovering these limits are correctly identifying that they have a memory problem. What they misdiagnose is the structure that memory needs to have.

Governance memory is not a text document. It is a structured record of decisions, each with scope, rationale, precedence, and status. The difference between a CLAUDE.md rule and a governance record is the difference between a sticky note and a ticket in your issue tracker. One is a reminder. The other is a traceable, queryable, maintainable artifact.

Effective governance memory has four properties that static context injection cannot provide:

  • Structure. Decisions are typed records, not paragraphs. The system knows what kind of decision it is, what scope it applies to, and when it was created.
  • Precedence. When two decisions conflict, the system resolves the conflict based on explicit precedence rules, not natural language interpretation.
  • Enforcement. Decisions are enforced at the hook level, before generation output is accepted. Compliance is not probabilistic.
  • Maintenance. The system tracks decision status. Superseded decisions are flagged, not silently ignored or accidentally applied.

These are infrastructure properties. They require infrastructure to implement, not a better-maintained text file.

The category framing

Context injection served a purpose. It was the first tool available for communicating architectural intent to an AI assistant, and it moved the problem forward. But it has a ceiling, and most teams building with AI at scale are already above it.

The next step is not a more organized CLAUDE.md. It is a structured decision memory that operates at the layer the problem actually lives in: between the engineer's intent, the AI assistant's generation process, and the codebase that inherits the output.

That is the infrastructure problem Mneme is designed to solve.