That unnamed requirement is governance.

Not memory. Not context injection. Not longer system prompts. Governance: the layer that enforces architectural constraints, preserves decision provenance, and maintains behavioral boundaries across autonomous agents operating at scale.

The AI Governance Layer is where Mneme HQ publishes its thinking on this category — what it is, why it’s missing, and what it looks like when it’s built correctly.

Read these four pieces in order:

1. The Generative AI Software Engineering Stack
The full seven-layer architecture of AI-assisted engineering. Governance lives at Layer 5 — between memory and orchestration — and almost no one is building it.

2. Why Code Review Cannot Scale With AI Output
Generative AI broke the ratio of code production to human review capacity. Code review was the last gate before code entered a shared codebase. That gate no longer holds.

3. Why CLAUDE.md Stops Scaling
CLAUDE.md is useful early. It stops working at scale because context injection is not enforcement. A file that tells the model what to do is not the same as a system that verifies it did.

4. Memory Is Not Governance
The AI coding category has conflated four distinct systems: memory, context management, retrieval, and governance. Each does something different. Governance is the only one that constrains behavior — and the only one most teams don’t have.

Together, these pieces argue that AI-assisted development does not only need better models or longer context windows. It needs enforceable architectural memory.

If you are building AI-assisted development infrastructure, or thinking about where the tooling gaps are, this is the right starting point.

New pieces publish weekly, usually on Tuesdays.

Theo Valmis
Founder, Mneme HQ

Every major technology shift produces a new stack. The database era gave us a standard layering of application, ORM, query engine, and storage. The cloud era gave us a standard layering of compute, orchestration, networking, and persistence. Each layer had clear responsibilities, clear interfaces, and a growing ecosystem of tooling at each level.

Generative AI is producing a new stack for software engineering. It is less than three years old, is still being argued about, and has several layers that are genuinely unresolved. But the shape is visible, and the teams building in this space need to understand it — both to make good tooling decisions and to identify where the real unsolved problems are.

This article maps the stack as it exists today.

Layer 1: Foundation models

The base layer is the models themselves. GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro, Llama 3, Mistral, and the growing set of code-specialized variants. This layer is commoditizing rapidly. Model capability is compressing: a model released eighteen months ago at frontier quality is now matched by models that cost a tenth as much to run. The differentiation at this layer is moving from raw capability toward specialization, latency, cost, and fine-tuning surface.

Key properties of this layer: probabilistic output, context-window-constrained, stateless across calls. Every layer above Layer 1 exists in part to compensate for one of these three properties.

Layer 2: Developer tooling

The second layer is the interface through which engineers interact with the models: IDEs, editor extensions, chat interfaces, and terminal tools. Cursor, GitHub Copilot, Codeium, Sourcegraph Cody, JetBrains AI Assistant. This layer handles the user-facing experience: accepting input, formatting it into model requests, rendering output, and managing the basic interaction loop.

This layer has seen the most visible competition and the most rapid adoption. It is also the layer most teams conflate with “AI coding” as a category, which creates the false impression that choosing a good editor extension is equivalent to having a complete AI engineering strategy. It is not.

Layer 3: Context management

The third layer manages what goes into the context window: which files, which symbols, which documentation, which conversation history. This is a hard problem because the context window is finite, the relevant information is scattered across a large codebase, and the model’s performance degrades as the window fills with irrelevant content.

Solutions at this layer include: RAG over code indexes, tree-sitter-based symbol extraction, semantic chunking, conversation summarization, and embedding-based retrieval of relevant past outputs.

Context management is necessary but not sufficient for architectural consistency. Surfacing relevant code is not the same as enforcing architectural constraints.

Layer 4: Memory

The fourth layer extends the context across sessions: durable storage of preferences, past decisions, project-specific conventions, and prior outputs. Without this layer, every new conversation starts cold, and the engineer must re-establish context that should persist automatically.

Memory at this layer is typically implemented via embedding stores and retrieval. Claude’s Projects feature, Cursor’s user rules, and various agent frameworks’ memory modules operate at this layer.

Memory optimizes for recall. Given a query, return what is relevant from the past. This is an important and genuinely hard problem. It is also not governance.

Layer 5: Governance

The fifth layer is the least mature and the most strategically important. Governance is the system that represents architectural decisions as structured objects, resolves conflicts between them deterministically, and enforces the resolved constraints at code generation and review time.

Where memory asks “what have we seen before that is relevant?”, governance asks “what rule applies here, and was the generated output compliant with it?”

The gap between these questions is large. Governance requires:

• A structured representation of decisions (not just text)

• Scope semantics (this rule applies to this service, not that one)

• Precedence resolution (when two rules conflict, which wins)

• An enforcement point (a hard boundary, not a suggestion)

• An audit surface (what rule was applied, why, to which output)

None of these exist in any meaningful form in the current tooling landscape. Teams cobble together CLAUDE.md files, custom lint rules, and review checklists — all of which are enforcement by convention rather than enforcement by infrastructure.

This is the layer where the most important unsolved problem in AI-assisted engineering sits. The teams that build durable governance infrastructure at Layer 5 will have a structural advantage over the teams that do not, because their AI-generated codebases will remain coherent as they scale. The teams without it will face compounding architectural drift that becomes expensive to fix.

Layer 6: Orchestration

The sixth layer coordinates multi-step, multi-model workflows: autonomous agents that plan, execute, observe results, and iterate. LangChain, LlamaIndex, AutoGen, CrewAI, and the growing set of agent frameworks live here. This layer is responsible for breaking large tasks into subtasks, routing between models and tools, managing execution state, and handling failure modes.

Orchestration amplifies everything below it — both capability and risk. An orchestrator that runs on top of a governance layer can generate and validate large amounts of code while staying within architectural constraints. An orchestrator that runs without a governance layer generates large amounts of code with no constraint enforcement, and the drift compounds across every step in the workflow.

Layer 7: Human oversight

The seventh layer is the human review and decision loop: code review, architecture review, incident response, and the organizational processes that surround them. This layer is not going away. Its role is changing.

The shift is from line-by-line verification (which cannot scale with AI output volume) to policy definition and exception handling. Humans define the architectural decisions at Layer 5. Humans review the audit trail of which decisions were applied and where. Humans handle the cases that fall outside the governance model. The governance layer makes human oversight viable at AI-generation scale by compressing what humans need to check from “every line of code” to “the policy decisions and their exceptions.”

Where teams are actually operating

Most teams building with AI today have strong Layer 1 and Layer 2 investment, reasonable Layer 3 investment, weak Layer 4, almost no Layer 5, and a Layer 6 that is growing fast. The gap between Layer 4 (memory) and Layer 6 (orchestration) — the missing Layer 5 — is where most AI-assisted engineering teams are operating blind.

The result is what you would expect from a machine running without the middle of its control plane: impressive velocity, accumulating drift, and an audit surface that cannot explain what the system actually did.

The next eighteen months of the AI engineering stack will be defined primarily by what gets built at Layer 5. The teams that solve governance will set the standard for what it means to build AI-assisted software at scale.

Read this article in full at mnemehq.com/insights/generative-ai-software-engineering-stack/

Code review is the last human gate before code enters a shared codebase. For most of engineering history, that gate was sufficient. The volume of code a human engineer could write in a day was bounded by the same biology that bounded a reviewer’s capacity to read it. The ratio of production to review held.

Generative AI broke that ratio.

An engineer working with a capable coding assistant does not produce incrementally more code. They produce categorically more code — ten times, in many observed cases, with trajectories suggesting that multiplier will keep moving. The code review process was not designed for this. It is a linear process applied to what is now an exponential input, and the resulting gap is not a workflow problem. It is an architectural one.

The math that does not work

Code review has a throughput ceiling. A careful reviewer, attending to logic, correctness, security, and style, can review somewhere between 200 and 400 lines of meaningful code per hour before quality degrades. This is not a number that improves much with practice or tooling — it is a cognitive limit. The reviewer must build a mental model of what the code is doing, hold that model against what it should be doing, and identify where they diverge.

That ceiling is per reviewer, per hour. It does not scale horizontally without adding reviewers. And reviewers are not cheap — the senior engineer doing the review is the same engineer who could be building something else.

Now put an AI coding assistant in the picture. The same senior engineer who previously produced 200 lines of thoughtful code per day is now shepherding an AI that can generate 2,000 lines in the same period. The engineer’s review capacity has not changed. The production rate has moved by an order of magnitude. The pipeline now looks like a highway merging into a country lane.

What happens when review can’t keep up

Teams respond to this mismatch in predictable ways, none of them good.

Review becomes a formality. Reviewers approve PRs they have not fully read. The approval signal — the thing that was supposed to mean “a human examined this and it is correct” — begins to mean “a human clicked this button.” The signal degrades faster than the team notices, because each individual approval still looks like an approval.

Review focuses on style over substance. It is faster to comment on naming conventions than to trace a logic path through five files. Review that cannot keep up with volume self-selects toward the things that are fast to check, systematically deprioritizing the things that actually matter — architecture, security boundaries, correctness under edge cases.

Batch sizes grow. Teams attempt to compensate for review bottlenecks by batching changes. Instead of reviewing 50-line PRs daily, they review 500-line PRs weekly. Larger diffs are reviewed worse, not better — the reviewer’s mental model degrades faster, and the risk surface in any individual review grows while the quality of attention per line falls.

The codebase drifts. Architecture decisions made in ADR-014 were reviewed carefully six months ago. The AI-generated PR touching the same service was reviewed for five minutes and approved. The accumulated drift between “what we decided” and “what the codebase actually is” grows silently, invisibly, until something breaks in a way that is expensive to diagnose.

Why shifting review left does not fully solve it

The conventional response to review bottlenecks is to shift quality checks earlier — into linting, type checking, automated tests, and pre-commit hooks. Shift left. Catch it before it reaches review. This is correct advice and teams should do it.

It does not solve the architectural compliance problem.

Linters enforce syntax and style. Type checkers enforce interface contracts. Tests enforce functional behavior. None of these enforce architectural decisions: which libraries are approved for use in which services, which patterns are prohibited in which contexts, which teams own which boundaries and what the rules are for crossing them.

An AI model that has been told “do not use library X in the payments service” will generate code that does not use library X — until it does, because a different session, a different context window, a different temperature setting, a different model version produces an output that violates the rule. No linter will catch this unless someone wrote a custom lint rule for this specific decision. And the set of architectural decisions in a production codebase grows faster than the set of custom lint rules anyone has time to write.

The problem is enforcement, not detection

Most teams frame this as a detection problem: how do we find violations faster? Better diff summaries. AI-assisted review. Automated PR descriptions. All of these make the reviewer’s job easier. None of them change the fact that enforcement still depends on a human catching the violation before merge.

In a world where code review throughput is a hard ceiling and AI generation volume is accelerating past it, relying on humans to catch architectural violations at review time is building on a foundation that is actively shrinking relative to the load placed on it.

The correct frame is enforcement, not detection. A constraint that needs to be enforced at review time — because it cannot be enforced anywhere else — will be enforced inconsistently as volume grows. A constraint that is enforced before the code is generated, or hard-rejected before it reaches the reviewer, is enforceable regardless of volume.

What enforcement before review looks like

Enforcement before review requires a governance layer that operates at generation time, not review time. The model generating the code needs to know — deterministically, not probabilistically — which architectural constraints apply to the current file, service, and context. Not as instructions in a prompt that can be overridden by other instructions. As a resolver that computes the applicable constraint set before generation begins and enforces it after generation ends.

This is shift-left applied to architectural governance, not just to style and syntax. It means the reviewer is no longer the last line of defense against constraint violations. It means the reviewer can focus on what review is actually good at: logic, design, intent, readability. The things that require human judgment and are not going to be replaced by a rule engine.

The window for getting this right

The teams that are under the most pressure from AI-generated code volume right now are the teams that adopted AI coding tools earliest. They are also the teams building the most. They are discovering the review bottleneck at exactly the moment when their AI-generated codebase is too large to fix cheaply.

The teams that have not adopted AI tools aggressively yet have a window. Build the governance layer before the volume arrives. The enforcement infrastructure is easier to put in place when the codebase is still manageable than after the drift has compounded for eighteen months.

Code review cannot scale with AI output. The solution is not to make code review faster. The solution is to enforce architectural constraints at the layer where they can actually be enforced — before the code reaches the reviewer, and before the reviewer becomes the bottleneck between engineering velocity and codebase integrity.

Read this article in full at mnemehq.com/insights/why-code-review-cannot-scale-with-ai-output/

CLAUDE.md is a good idea. A file that tells the model how to behave, what to avoid, which conventions to follow — better than nothing, clearly useful in early stages of a project. Most teams that use it report genuine improvement in baseline output quality.

It stops scaling at around the point where the project gets interesting.

This is not a criticism of Claude, of Anthropic, or of the teams using the file. It is a structural observation: CLAUDE.md is a context-injection mechanism, and context-injection mechanisms have a ceiling. The ceiling is not about file size. It is about what context injection cannot do, regardless of how well-written the file is.

What CLAUDE.md actually is

CLAUDE.md is a prompt. A very good prompt — one with a name, a file location, and a community norm around its contents — but a prompt. When the model reads it, what happens is identical to what happens when any text lands in the context window: the model attends to it, weights it against everything else in the window, and incorporates it into the response it generates.

That process is powerful and it is also the source of every scaling failure this article is going to describe.

Prompts do not enforce. They inform. The model’s behavior under a CLAUDE.md instruction is as reliable as the model’s behavior under any other instruction — which is to say: excellent under low-load conditions, degraded under high-load conditions, and structurally unable to provide the guarantees that architectural governance actually requires.

Failure mode 1: Context accretion

CLAUDE.md starts small. Teams add to it. By month six it is a dense, structured, internally cross-referencing document that covers everything from naming conventions to deployment philosophy to third-party dependency policy.

Every line added to CLAUDE.md competes with every other line for the model’s attention. The model does not read CLAUDE.md the way a human engineer reads a policy document — top-to-bottom, with careful retention, flagging conflicts for later resolution. It reads the entire context window at once, and its behavior is a function of that whole.

The practical result: long, dense CLAUDE.md files produce inconsistent behavior because different parts of the file dominate depending on what else is in the context window at query time. A team that added a new constraint in section 12 will find it reliably followed when the query is simple and largely ignored when the query is complex and the rest of the window is full.

This is not a bug. It is how transformers work.

Failure mode 2: No deterministic enforcement

The most important word in architectural governance is not. Not this library. Not this pattern. Not this approach in services that touch payment data.

CLAUDE.md can express “not” as an instruction. It cannot enforce it. Enforcement requires a system external to the model — a thing that checks output against constraints and rejects it when it fails. CLAUDE.md has no such system. The model is both the instruction-follower and the only checker, and a model that generated a violation does not reliably detect that it generated a violation.

Teams discover this when they find that the constraint they wrote in CLAUDE.md three months ago has been violated in eleven places, consistently, across multiple sessions, by the same model that read the constraint. The model did not forget. It was never in a position to enforce.

Failure mode 3: No decision provenance

Architectural decisions have histories. ADR-014 said “use Pydantic for validation” in January. ADR-031 said “do not use Pydantic for validation in the payments service” in March. The interaction between those two decisions — which one applies, in which scope, under which conditions — is load-bearing information for anyone generating code that touches the payments service.

CLAUDE.md cannot represent this. It is a flat document. It has no concept of decisions, scopes, supersession, or precedence. A team can write “do not use Pydantic in payments” in CLAUDE.md, but that instruction carries no provenance — no reason, no date, no relationship to the earlier instruction it overrides. When the context window is under pressure and something has to give, the instruction with no provenance gives first.

Failure mode 4: Poor scope resolution

A CLAUDE.md at the repository root applies globally. A CLAUDE.md in a subdirectory applies locally. This is a reasonable file-system approximation of scope, and it works until the architecture has scope rules that do not map cleanly to directory structure.

Real scope in a production codebase is not just about directory. It is about service boundaries, team ownership, compliance classifications, data sensitivity tiers. A payment processing module might live in the same directory as a logging utility and have completely different constraint sets. CLAUDE.md has no way to express this. The team either writes global rules that are too broad, or splits files in ways that fragment the governance and make it impossible to reason about from a single location.

Failure mode 5: Autonomous agent drift

In interactive coding, a human is reading every output. When the model violates a constraint, the human catches it (sometimes) and corrects it. CLAUDE.md was designed for this world — a world where there is always a human downstream of the output, closing the enforcement loop informally.

Autonomous agents change this. When the agent is writing code across multiple files in a single session, running tests, interpreting results, and writing more code based on those results, the human is out of the loop for the duration. Drift compounds. A constraint violation in the third file affects the code generated in the fifth file. By the time a human reviews the output, the violation is structural, not stylistic.

CLAUDE.md was not designed for this world. The teams discovering this are not doing anything wrong. They are running a governance mechanism designed for interactive sessions in an autonomous context, and finding that the informal enforcement loop the mechanism depended on is no longer there.

What the ceiling means in practice

None of the five failure modes above are catastrophic in a small codebase with two engineers and a simple architecture. CLAUDE.md works fine there. The ceiling becomes visible at specific thresholds:

• When the number of architectural decisions in the project exceeds what a single document can express without internal contradiction

• When multiple services have overlapping but non-identical constraints

• When autonomous agents are generating code that nobody reviews at the file level

• When the team needs to audit what constraint a given diff was generated under

• When a new decision needs to override an old one in a specific scope

At each of these thresholds, the problem is not that CLAUDE.md was written poorly. It is that the mechanism cannot carry the load regardless of how it is written.

What comes after CLAUDE.md

The pattern that replaces CLAUDE.md is not a better CLAUDE.md. It is a different category of system: one that represents decisions as structured objects with identity, scope, and precedence; one that resolves conflicts between decisions deterministically before they reach the model; one that enforces at a hard boundary rather than relying on the model’s own compliance.

This is what architectural governance infrastructure means. CLAUDE.md is a useful on-ramp. It is not the destination.

The teams hitting the ceiling are not behind. They found the ceiling, which means they built enough to find it. The next step is to stop writing instructions into a context window and start building the layer that makes instructions enforceable.

Read this article in full at mnemehq.com/insights/why-claude-md-stops-scaling/

The AI coding category is awash in memory products. Letta. Mem0. OpenAI’s memory feature. Cursor’s per-user context. Claude’s projects. Every agent framework ships a “long-term memory” primitive. They are all built on a similar conceptual core — durable storage of past interactions, embedding-based retrieval, opportunistic injection — and they all do recall well.

None of them governs.

That sentence sounds polemical and is meant to. The conflation of “memory” and “governance” in the AI coding category is the single biggest source of category confusion in 2026, and it is the reason most engineering teams are paying for tools that promise architectural consistency and shipping codebases that do not have any.

One word, four systems

Walk into ten engineering conversations about AI coding and you will hear the same four words used as if they meant the same thing.

• Context. The window of tokens the model can see right now. A per-request property.

• Retrieval. The mechanism by which something gets into that window. An index lookup.

• Memory. The durable store of past interactions, decisions, preferences, and conversations that retrieval reads from.

• Governance. The rule system that decides which architectural constraints apply to which code, and enforces them.

These four concepts get blurred because three of them are tightly coupled and the fourth happens to use the other three. Governance systems do read from memory. They do retrieve. They do inject into context. So at first glance, governance looks like a flavor of memory.

It is not. Memory and governance differ on the most important thing a system can differ on: what they are trying to be good at.

Memory systems optimize for recall. Governance systems optimize for constraint enforcement. Different targets, different math, different failure modes.

What memory actually optimizes

A well-designed memory system is judged on questions like:

• Given a query, did we surface the relevant past artifact?

• How fuzzy can the query be before recall degrades?

• How long does the system continue to find the right thing as the corpus grows?

• How well does the system tolerate paraphrase, synonyms, near-duplicates?

All four of these are recall metrics. The optimization target is: given fuzzy input, return relevant material. The corpus is allowed to be redundant. The output is allowed to be ranked, partial, probabilistic. The user is allowed to read multiple items and choose. The system is doing well if the right thing is somewhere in the top results.

That target is the right one for the problems memory systems were built to solve. Personal assistants need to remember a user’s preferences across sessions. Agents need durable context between runs. Customer-support tools need to surface prior tickets. In every case, recall is the job, and fuzziness is acceptable because a human (or a reasoning model) is on the other end to filter.

None of those properties survive the move to governance.

What governance actually optimizes

A governance system is judged on a different question entirely:

Given the current task, current file, current scope, and the full set of architectural decisions — which decision applies here, and was the resulting code obedient to it?

The optimization target is constraint enforcement. Output a single resolved rule. Reject code that violates it. Produce an audit trail explaining why. The job is not to surface candidates. The job is to pick.

That distinction cascades through every property of the system:

01. The output is one value, not a ranking. Recall systems return top-k. Governance systems return top-1, by construction. “Here are five possibly-relevant ADRs” is a recall answer. “ADR-022 applies to services/payments/charge.py, and ADR-014 is overridden in that scope” is a governance answer.

02. The result has to be deterministic. Recall can be probabilistic without harm — if the order of the top-3 shuffles between runs, the user reads them all anyway. Governance cannot. The same input must produce the same answer in every agent, every model, every temperature, or the codebase is not actually governed by anything.

03. Conflict is the central case, not an edge case. Recall systems treat overlapping documents as a ranking nuisance. Governance systems treat overlap as the entire point — conflict resolution is what makes governance deterministic. A memory system has no opinion on which of two ADRs wins. A governance system must have one.

04. The audit surface is different. A memory system’s audit answer is “here is what we showed you, ranked by similarity.” A governance system’s audit answer is “this diff was generated under ADR-022, which won over ADR-014 because its scope is narrower.” The first is a log. The second is an explanation. Engineering teams need the second.

05. The enforcement point exists. Memory systems have no enforcement point. They surface and stop. Governance systems have a hook — pre-generation injection, post-generation check, CI gate — where output is rejected if it violates the resolved constraint. The hook is what turns governance into infrastructure rather than advice.

The optimization-target table

The clearest way to see the gap is to put the two systems next to each other on the properties that actually matter.

Memory vs governance — what each is built to be good at:

• Optimization target: Memory = recall under fuzziness | Governance = constraint enforcement under conflict

• Output shape: Memory = top-k ranked list | Governance = top-1 resolved rule

• Determinism: Memory = probabilistic, acceptable | Governance = required, by construction

• Conflict semantics: Memory = ranking nuisance | Governance = central concern (precedence)

• Audit surface: Memory = “what we showed you” | Governance = “which rule won and why”

• Enforcement point: Memory = none, surfaces and stops | Governance = hook at file write / commit / PR

• Failure mode: Memory = missed recall (false negative) | Governance = silent drift, contradictory diffs

A team that buys row one of that table and assumes they got row seven has bought a recall system and labeled it governance. Six months later, the codebase has both versions of the rule in production, the embedder is rotating its index, and nobody knows which decision the last bot-generated PR was actually written under.

Memory is an input to governance, not a substitute

Naming the gap is not the same as saying memory does not belong in the picture. It does — just one layer below where the category currently puts it. Memory is one of the inputs a governance system reads from. It is not the governance system itself.

The current framing: Buy a memory product. Index your ADRs. Hand the agent the top retrieved chunks. Call it AI coding governance. Discover six months in that the same constraint resolves differently across services and nobody can audit why.

The correct framing: Memory stores decisions and their metadata. Governance queries memory to discover candidates, then resolves between them deterministically over a declared precedence order, then enforces the resolved rule at the file-write or PR boundary.

Why the conflation persists

The conflation has a market logic. Memory products exist. They have APIs, SDKs, and pricing pages. They are being bought and deployed right now. The governance category is early — clear in concept but undersupplied in product. The gap between “what exists” and “what is needed” creates a genuine, if temporary, incentive for memory products to claim governance use cases.

There is also a technical reason: the line between memory and governance is invisible in demo conditions. Give a memory system a single, non-conflicting ADR to retrieve, and it looks correct. The failure mode only surfaces under conflict — multiple overlapping decisions, scope inheritance, cross-service inheritance chains — which is exactly the kind of load a demo does not show and a production codebase always has.

The conflation persists because the cost is deferred. Teams do not know they built on the wrong abstraction until the codebase is six months old and the inconsistencies are expensive to fix.

The takeaway

This is not a criticism of memory systems. Letta, Mem0, and the rest are building real infrastructure for real problems. The criticism is of the category framing that has allowed “memory” to become a synonym for “governance.”

Engineering teams buying AI coding infrastructure in 2026 should ask one question: does this system pick, or does it suggest?

If it suggests — surfaces candidates, ranks them, lets the model or the human decide — it is a memory system. Useful, necessary, not governance.

If it picks — resolves conflicts deterministically, enforces the result at a hard boundary, produces an audit trail of why the rule that won did win — it is a governance system.

Most of what is currently being sold as governance picks nothing. It suggests well.

The architectural consistency problem in AI-assisted engineering will not be solved by better recall. It will be solved by the first layer that actually enforces.

Read this article in full at mnemehq.com/insights/memory-is-not-governance/