A federated knowledge base is not built to make AI freer. It is built to give AI better boundaries.

Without those boundaries, the system becomes dangerous. Private project material may appear in public writing. Outdated documents may be treated as truth. Generated website content may start overriding the source knowledge. A project assistant may apply central theory to code it has not checked.

Boundaries are not an add-on. They are the core design.

Privacy: private by default

Material entering a knowledge system should not be public by default.

Project documents, family notes, client assets, private repositories, screenshots, logs, local debug paths, and chat transcripts may all contain material that should not be published. Summarizing them with AI does not automatically remove the risk.

A practical rule is:

raw detail stays private
generalized lesson may be promoted
public draft needs review

Original detail stays inside the project or private repository. Reusable lessons can be promoted to the central knowledge base. Public drafts must pass publication review.

Truth sources: project facts come first

The central knowledge base can store methods and principles. It cannot replace project truth.

For a software project, code, tests, configuration, and current product documentation are usually closer to fact than a central summary. For a research project, the source list and package manifest are closer to evidence than a later topic page. For a publication node, routing and component behavior must be checked in the site code.

When an AI assistant judges a project, it should first ask: where is this project’s truth source?

If the central knowledge base says one thing and the project code says another, do not blindly choose the central note. Return to the project, verify the fact, then decide whether the central knowledge should be updated.

Publication audit: public output is not copy paste

Public content needs an audit trail.

The dangerous path is simple: discuss something in a project, copy it into a website article, and ship it. That loses source traceability, privacy review, bilingual alignment, and future update control.

A safer path uses publication records:

  • The source draft stores the reader-facing source.
  • The manifest stores collection, language, slug, series, and source hash.
  • Review records privacy and schema checks.
  • The sync log records the generated site write.
  • The site artifact only renders.

Six months later, the article can still be traced back to the knowledge source instead of forcing you to guess why a page says what it says.

Failure mode: premature full automation

AI-native PKM has an attractive failure mode: let an agent watch, summarize, write the wiki, and publish automatically.

That can look impressive in a demo, but it is dangerous in a real knowledge base. The system often does not yet know which material is stable, which material is only a temporary discussion, which material contains private detail, and which material is public-safe. The more automatic the system is, the faster mistakes propagate.

My rule is review-first, not automation-first.

It is reasonable to automate checks, candidate generation, diffs, and next-step prompts. It is too early to automate silent edits to durable wiki pages, silent copying of project documents, or silent publication.

Failure mode: global knowledge pollutes project judgment

If a project assistant reads the entire central knowledge base by default, it may apply another project’s rule to the current project.

One project may treat its code repository as the product source of truth. Another may have a workspace that acts as a control layer and a sub-repository that holds product truth. If the assistant generalizes from the first to the second, it may organize the wrong directory or edit the wrong documents.

The fix is not less reading. The fix is mode detection and narrow central lookup.

Failure mode: the site captures the truth

Once a public article only exists in the website repository, the website becomes the knowledge source.

That breaks the direction of the pipeline. If the central concept changes, the site page will not know. If generated content is manually edited inside the site, the central record will not know either.

Generated content can be committed to Git. It should not become source.

Failure mode: AI output becomes evidence

AI can summarize evidence. AI’s summary is not the original evidence.

If the knowledge base only says “AI concluded this product works this way” without source, code, documentation, or tests behind it, that is not knowledge. It is a more formal hallucination.

The system must keep four layers separate:

  • source evidence
  • compiled knowledge
  • public argument
  • site artifact

They can be connected. They should not be collapsed.

Boundaries are what make the system scalable

A local knowledge system will eventually connect more directories: research projects, product repositories, open-source work, family material, personal websites, and social output.

Without boundaries, scale makes the system more dangerous. With boundaries, scale makes it more valuable.

The goal of a federated knowledge base is not to give AI infinite context. The goal is to let AI work in the right context and make every cross-boundary action traceable, reviewable, and reversible.