The most important part of a federated knowledge base is not that it has many folders. It is that each folder has a different job.

If the central knowledge base, project directories, and website repository can all act as source, draft, publication layer, and archive at the same time, the system becomes impossible to reason about. You will not know where a claim came from, whether a page is current, whether a project note is public-safe, or which rule the AI assistant should follow.

So the system starts by separating ownership.

Why this is not just a better vault template

Many Obsidian templates start with inbox, areas, projects, resources, and archives, or use Zettelkasten-style atomic notes to create a connected graph. Those structures are useful for personal knowledge work. But they usually assume that the knowledge is organized inside one vault.

My problem is not that a single-vault structure is not elegant enough. It is that project facts, central knowledge, and public publishing are different kinds of ownership.

A production codebase should be governed by its code, tests, and current documentation. A central knowledge base should keep reusable concepts and methods. A website repository should care about routes, styling, build behavior, and deployment. Putting all of that into one template may look tidy at first, but it eventually makes it harder for AI to know which layer is the source of truth.

The core idea here is not a template. It is ownership.

The central knowledge base owns long-term knowledge

The central knowledge base is not a dumping ground for every file.

It should store knowledge objects that are reusable across projects: concepts, topics, methods, evaluation frameworks, publication source drafts, public candidates, and audit records. It can absorb lessons from projects, but it should not copy every project document wholesale.

The central knowledge base is good at answering questions such as:

  • Does this concept already exist?
  • Is this method reusable beyond one project?
  • Can this project lesson be generalized?
  • Which material is ready for publication?
  • Which publication records have been prepared, synced, or published?

It should not become the live product documentation for every project. It should not become the planning workspace for every codebase either.

Project directories own project facts

A project directory is the working surface for project truth.

A real project contains code, tests, docs, tasks, assets, research packages, temporary decisions, and outdated files. When an AI assistant works inside that directory, it should respect local project facts first instead of using abstract principles from the central knowledge base as if they were current implementation truth.

Project directories are the right home for:

  • current product or research material
  • code and tests
  • project-local research packages
  • local agent rules
  • project-specific skills
  • conclusions that only hold in the current project

When a project lesson becomes stable and useful beyond the project, it can be promoted into the central knowledge base.

The important word is promoted, not synced. Syncing everything pollutes both sides. Promotion is selective, sourced, and reviewable.

The publication node owns rendering, not truth

A personal website or documentation site is a publication node.

It should own layout, styling, routes, SEO, RSS, build validation, and deployment. It should not become the source of truth for knowledge. It should not invent missing translations, facts, or citations inside generated content.

If an article comes from the central knowledge base, the source should remain in the central publication record. The site consumes reviewed artifacts.

That gives the system an important property: when the source knowledge changes, the content can be regenerated instead of letting the website repository become a new island of truth.

Narrow interfaces connect the layers

The layers are not isolated. They cooperate through narrow interfaces.

A healthy flow looks like this:

project insight -> promotion inbox -> central source draft -> publication candidate -> site artifact

The reverse should not happen:

site copy -> central truth
random project note -> public article
global knowledge dump -> project agent context

Narrow interfaces give each step a boundary. A project promotes knowledge. A project looks up central knowledge. The central system prepares, reviews, and syncs publication candidates. The site renders reviewed generated artifacts.

This makes AI work safer

AI assistants fail most dangerously when they are not sure what to trust.

If a project assistant reads central theory, outdated project docs, generated site content, and a temporary chat transcript at the same time, it can easily produce a fluent but wrong synthesis.

Ownership boundaries make the assistant’s job clearer:

  • In a project directory, trust project facts first.
  • In the central knowledge base, compile reusable knowledge.
  • In the publication node, render and validate.

This is not about limiting the AI. It is about putting its capability in the right place.

A durable knowledge system does not need every directory to do everything. It needs every directory to know what it should not do.