The way to keep a federated knowledge base under control is not to stop AI from doing useful work. It is to turn cross-boundary actions into explicit interfaces.

If a project assistant can freely read the central knowledge base, edit long-term wiki pages, copy project notes into public articles, and change generated website content, the system will become unmaintainable. What you need is not a larger context window. You need a small set of clear commands.

I group these commands into three actions: lookup, promote, and publish.

Rules files are not enough; operations matter

Karpathy-style LLM Wiki has an important lesson: an AI-maintained wiki should not rely only on a vague natural-language wish. It needs a schema or rules file that tells the agent how to ingest, query, and lint knowledge. AGENTS.md, CLAUDE.md, and skill files can all play that role.

But rules only answer “how should this work?” That is not enough.

The knowledge system also needs executable operations that answer “what can be done now?” Otherwise an assistant may read the rule and still choose its own way to scan directories, edit the wiki, copy project material, or draft public content.

So the federation rule becomes a command surface:

status  -> know the current mode
lookup  -> reuse central knowledge
promote -> send stable project knowledge into review
publish -> prepare, review, and sync public output

These commands are not decoration. They turn knowledge boundaries into an executable protocol.

Start by checking the current mode

Before any cross-project knowledge work, ask where you are.

The command shape is:

kb status

It should tell you whether the current directory is central mode, project mode, or external mode.

This matters because the same AI assistant has different responsibilities in different places:

  • Central mode can compile global knowledge.
  • Project mode should work from local project facts by default.
  • Publication node mode handles rendering and build validation, not knowledge invention.

Without a mode check, the AI can do the right kind of action in the wrong directory.

lookup: retrieve only the central knowledge you need

When a project needs an existing concept or method, do not let the AI scan the whole central knowledge base.

Use lookup:

kb lookup "project skill governance"

The goal of lookup is not to put the entire vault into context. It should return relevant concepts, topics, or lightweight source summaries. The assistant gets a narrow result, not the whole system.

Use lookup when:

  • a concept in the project may already exist centrally
  • a reusable method may have already been written down
  • a project needs a central governance rule
  • a note may be worth promoting and should be checked for duplicates first

Do not use lookup to bypass project facts, search private material broadly, or skip the local project rules.

promote: only stable lessons enter the central review path

Projects produce useful lessons all the time. That does not mean every note should become central knowledge.

Use promote:

kb promote path/to/stable-note.md

Promotion sends a stable conclusion into the central review path. It does not directly write a long-term wiki page.

A note is a good promotion candidate when:

  • it is not a temporary judgment
  • it is useful beyond the current project
  • its project, date, and source context can still be traced

This keeps the central knowledge base from becoming a pile of project drafts.

publish: public output needs candidates and review

Publication is another boundary.

Public articles should not be copied directly from a project directory into the website. The website should not fill in missing facts or translations. The safer workflow is:

source draft -> prepare -> review -> sync -> set site status

The command shape is:

kb publish prepare <source>
kb publish review <candidate-id>
kb publish sync <candidate-id>
kb publish set-site-status <candidate-id> --status published

Prepare creates the publication candidate and bilingual public draft. Review checks privacy, paths, language siblings, metadata, and source hashes. Sync writes reviewed candidates into the site as generated artifacts. The site renders and builds. It does not invent missing source content.

The three interfaces form a loop

lookup, promote, and publish correspond to three actions:

reuse knowledge
promote knowledge
publish knowledge

They let AI participate in the knowledge system without bypassing its boundaries.

That is why I prefer narrow interfaces over exposing the central knowledge base directly to every project assistant. The narrower the interface, the clearer the responsibility. The clearer the responsibility, the easier it is to keep the knowledge base usable over time.

Good knowledge automation is not “let AI organize everything automatically.”

Good knowledge automation is: every cross-boundary action has a name, a source, a status, and a review path.