Category Distinction 8 min read

# Your LLM Wiki Is a Library, Not a Law

Teams are doing real work organizing project knowledge so coding agents can read it. ADRs, PRDs, CLAUDE.md, AGENTS.md, NotebookLM, internal wikis, Cursor rules. This is a good step. It is not the final layer. A wiki helps the agent know. Governance makes the agent comply.

By Theo Valmis·May 2026

## The rise of the LLM-readable project wiki

The pattern is now widespread. Teams are restructuring docs, ADRs, PRDs, design notes, research folders, and live planning files so AI coding agents can understand the system faster. NotebookLM-style project knowledge bases, AGENTS.md / CLAUDE.md / PLANS.md conventions, Cursor rules, and repo-native wikis are all examples of the same move.

It is a useful move. An agent given a curated, retrievable library of project knowledge has a better starting point than one piecing things together from scattered chat history, tribal knowledge, or whatever happens to be open in a buffer.

The result is a generation of teams who have invested in making project knowledge legible to LLMs. The question this article is about is what that legibility actually buys you, and what it does not.

## A library improves recall. It does not create authority.

A wiki can tell the agent what the architecture is. It cannot guarantee the agent treats that information as a constraint.

In practice, agents working against an LLM-readable wiki can still:

- retrieve the wrong document for the task at hand
- miss the relevant ADR entirely
- treat a binding rule as ambient background context
- follow a rule in one session and forget it in the next
- generate code that looks locally correct but violates a system boundary the wiki described

These are not failures of the documentation. The decision is written down. The architecture is on the page. The wiki found it. The agent read it. And then the agent shipped code that contradicted it.

The problem is not that the agent cannot read the rule. The problem is that reading is not the same as obeying.

## The failure mode: the rule was documented, but not enforced

The most painful cases in real codebases are rarely caused by missing documentation. The decision usually exists. The architecture is written down. The PRD is clear. The ADR explains the constraint.

The failure is that none of it is active at the moment code is generated. The agent has access to the text. The agent may even cite it. But the text has no enforcement surface, so there is nothing in the loop that can block a generation that disagrees with it.

This is the structural reason that "we wrote it down, so the agent will follow it" keeps disappointing teams. Writing it down is necessary. It is not sufficient.

## Documentation is context. Governance is constraint.

This is the category distinction worth keeping straight.

LLM Wiki
Knowledge surface
Reference · recall · context

- Answers: what should the agent know?
- Organizes docs, ADRs, PRDs, plans
- Improves retrieval and grounding
- Passive: read only at request time
- Can be ignored, missed, or paraphrased away

Architectural Governance
Control surface
Invariants · enforcement · audit

- Answers: what must the agent not violate?
- Encodes binding architectural constraints
- Injected before generation, checked at CI
- Active: enters the loop, not just the context
- Deterministic verdicts with provenance

A wiki is a knowledge surface. Governance is a control surface. They are not competing layers; they sit on top of each other. The mistake is treating the knowledge surface as if it were already a control surface.

## What turns project knowledge into governance?

Most project knowledge stays in the wiki and should stay there. Reference material, design context, history, and rationale do not need to be enforced; they need to be findable. Only a subset of project knowledge is binding, and that subset has to clear a higher bar to become governance.

Useful project knowledge becomes governance only when it is:

1. Explicit.Stated as a checkable rule, not implied across paragraphs of prose.
2. Scoped.Tied to the part of the system it actually governs, so it is retrieved when it is relevant and not when it is not.
3. Retrievable at the right moment.Surfaced into the loop before the agent commits to a candidate change, not buried in a doc that may or may not be fetched.
4. Enforceable before code lands.Evaluable by a hook or CI gate that can return a deterministic verdict against the resulting artifact.
5. Auditable back to the source decision.Every verdict can be traced to the ADR, PRD, or policy it derives from, so enforcement is reviewable rather than opaque.

Knowledge that meets all five criteria is doing a different job than knowledge that sits in a wiki. It has stopped being reference material and become an executable architectural constraint.

## The Mneme comparison frame

It helps to name each layer by what it actually does, rather than treating them as interchangeable.

Layer | What it does
--- | ---
LLM wiki | Organizes project knowledge so agents can read it
Prompt files | Remind the agent what generally matters in this repo
ADRs & PRDs | Record architectural and product decisions for humans
Mneme | Turns selected decisions into enforceable constraints in the agent loop

None of the upper layers go away. A team that adopts governance still needs ADRs and a project wiki, just like a team that adopts CI still needs a README. What changes is that the binding parts of the knowledge stop relying on the agent’s discretion to be honored.

## Where Mneme fits

Mneme does not replace docs, ADRs, AGENTS.md files, or project wikis. It sits after them. It takes architectural intent from repo-native sources and makes it available as enforceable constraints for AI-assisted development — retrieved before generation, enforced at the hook and CI layers, and provenanced back to the source decision.

The wiki remains the library. Mneme becomes the law.

An LLM wiki helps agents understand the system. Architectural governance determines which parts of that understanding are binding.

## Closing

If your team already has ADRs, design notes, or project rules, the next step is not another wiki. It is deciding which parts of that knowledge should become enforceable architectural constraints — and what enforcement surface they belong on.

The library is good work. It is not the last layer.

## Frequently asked questions

Is an LLM wiki bad or insufficient?+
No. An LLM-readable project wiki is genuinely useful. It improves agent grounding, reduces repeated explanation, and gives onboarding teams a real artifact. The argument here is not that wikis are insufficient in some absolute sense — it is that wikis are knowledge surfaces. They were not designed to enforce architectural constraints, and using them as if they were leads to the failure mode where the rule is documented but ignored at generation time.
Can I use both an LLM wiki and Mneme?+
Yes — and in most teams that is the right combination. The wiki organizes the full body of project knowledge: rationale, history, design discussion, reference material. Mneme governs the subset of that knowledge that has to bind agent behavior: ADR rules, dependency policies, scope boundaries, security invariants. The wiki tells the agent what the system is. Mneme makes sure the binding parts of that description are honored at generation time and verified at CI.
Doesn’t putting rules in CLAUDE.md or AGENTS.md count as governance?+
Prompt files like CLAUDE.md and AGENTS.md are useful as reminders. They are still knowledge surfaces, not control surfaces: the model decides how to weight them, they apply only within sessions that load them, and they have no deterministic enforcement at the hook or CI layer. They reduce friction. They do not produce a verdict. Treating them as if they were policy is the version of this failure mode that lives one layer above the wiki.
How do I decide what to promote from wiki to governance?+
Two practical questions: would you reject a PR that violated this rule, and can the rule be stated as a check the agent must not fail? If both answers are yes, the knowledge is doing governance work and should be encoded as an enforceable constraint — explicit, scoped, retrievable at generation time, enforceable before merge, and traceable back to the source decision. If either answer is no, the knowledge belongs in the wiki and not in the governance layer.
Related governance concepts

- Executable Architectural Intent

  The slice of project knowledge that has been promoted from documentation into machine-evaluable, enforceable constraints.

- Architectural Governance

  The discipline of constraining what AI agents are allowed to do, not just describing what they should know.

- Governance Before Generation

  Architectural constraints retrieved and applied before the agent commits to a candidate change.

- Verification Contracts

  Predefined checks that prove architectural intent survived the agent run.

Related operational essays

- Agent Skills vs Architectural Governance

  Skills teach agents how to act. Governance constrains what those actions can do to the system.

- Goal-Driven Agents Need Architectural Governance

  Tests verify outcomes. Governance preserves architectural intent while the loop runs.

- Why CLAUDE.md Stops Scaling

  An instruction surface is not a governance layer.

- Memory Is Not Governance

  Context persistence cannot enforce architectural invariants. Recall is not constraint.