When people build an AI knowledge base, the obvious instinct is to let the AI see everything.

That sounds reasonable. More material should mean better answers, right?

In project work, I have found the opposite to be true. A project AI assistant that sees the entire knowledge base by default is usually not more reliable. It is more likely to lose the boundary of the current task.

AI-readable does not mean fully exposed

Public projects already explore AI-readable wikis and AI-maintained vaults. They share a useful premise: knowledge should be written in a form that AI can read, search, and help maintain.

I agree with that premise.

But “AI can read it” does not mean “every project assistant should read all of it by default.” In central compilation, the assistant may need a wider knowledge surface. In project execution, the assistant needs local facts, current code, the active task, and project rules. Dumping the whole central knowledge base into project context usually reduces reliability instead of improving it.

This system is not against AI-readable vaults. It turns access into an explicit, need-based action.

Large context breaks boundaries

The first job of a project assistant is not to know the most. It is to do the right thing inside the current project.

If it is changing a product repository, it should understand the current code, tests, product facts, and project rules. If it is organizing a research package, it should read the package manifest and evidence first. If it is working with private family or client material, it should remain inside that privacy boundary by default.

A full knowledge base introduces too much plausible but distracting material:

  • old conclusions from other projects
  • publication drafts that are no longer current
  • rules that only apply to another product
  • generalized summaries of private material
  • unverified discussion notes

AI is very good at weaving such material into a smooth answer. Smooth is not the same as reliable.

Local facts should not be overwritten by global theory

The central knowledge base is good for principles. The project directory owns project facts.

For example, the central system can say that the publication node should not become the content source of truth. But the actual route behavior of a website still has to be checked in the site code. The central system can say that a project skill should not copy all global rules. But whether a specific project needs a special skill depends on that project’s real workflow.

If the project assistant reads the whole central knowledge base by default, it can treat principles as implementation facts.

A better rule is:

read local truth first
ask central knowledge only when needed
promote stable lessons only after review

Privacy should default to conservative

A federated knowledge system may connect open-source projects, private repositories, product research, family material, client assets, personal writing, and publication nodes.

These directories do not have the same risk level.

If every project assistant sees the whole central knowledge base by default, different privacy levels end up in one context pool. Even without bad intent, an assistant can carry detail into a summary, article, code comment, or public draft where it does not belong.

Privacy governance should not rely on hoping the AI is careful. It should rely on default invisibility.

Narrow interfaces are better than full exposure

A project assistant should know that the central knowledge base exists. It just should not read it wholesale by default.

The better model is a narrow interface:

  • Use lookup to find existing concepts or topics.
  • Use catalog to inspect a lightweight inventory.
  • Use promote to send stable project knowledge into the central review path.
  • Use the publication workflow only when content is ready for public output.

The assistant still benefits from central knowledge, but the central system is not dumped into the project context.

This is similar to software architecture. You do not expose the entire database to every UI component. You design APIs, permissions, and response shapes. Knowledge work needs the same discipline.

Project AI should know the central system exists

Not seeing the whole knowledge base does not mean the project assistant is isolated.

It should know three things:

  • A central knowledge base exists.
  • The current project is local-first by default.
  • Cross-boundary work must use explicit commands or tools.

That is the role of federated skills, project rules, and narrow kb commands. They do not give the AI more material. They tell it how to handle boundaries.

Reliable AI work needs selective memory

Humans do not work by remembering everything at once.

We open different files in different contexts, cite different sources, and follow different rules. A lawyer does not mix every client’s material into the same memo. An engineer does not treat another product’s implementation as fact for the current repository. A researcher does not turn unverified notes directly into paper conclusions.

AI should work the same way.

The full knowledge base belongs to central compilation. It does not belong in every project context by default. Project AI needs local clarity, narrow interfaces, and traceable promotion, not infinite memory.