I no longer trust chat history as a serious knowledge-management system.

Chat is excellent for exploration. I can ask a question, challenge the answer, paste a document, compare options, or let an AI assistant help me think through a messy problem. But chat has a structural weakness: it does not naturally become durable knowledge.

A conversation contains facts, guesses, temporary decisions, mistakes, context-specific assumptions, and useful conclusions all mixed together. If I do not reorganize it, it becomes a long trail of plausible text that is surprisingly hard to reuse.

What I want is not more chat history. I want a local system where AI can help turn project work, research, and public writing into durable knowledge.

That is why I built an Obsidian + Codex federated knowledge base.

This is not an invention from zero

The boundary matters: this system is not claiming to invent the idea of an AI knowledge base.

Public practice already contains several important patterns. Obsidian shows that local Markdown, links, backlinks, and folders can carry long-term personal knowledge. PARA and Zettelkasten-style workflows show that knowledge organization is a living process, not a one-time archive. Karpathy-style LLM Wiki treats a wiki as a surface that language models can read, maintain, and act on. Projects such as LLM Wikid, SwarmVault, and Zettelclaw explore AI-maintained local wikis and vaults.

So the point is not simply “let AI read a vault.”

The point is this pipeline:

project evidence -> federation inbox -> central wiki/source draft -> publication candidate -> site artifact

Project facts, long-term central knowledge, AI compilation, human review in Obsidian, and public website output should not collapse into one undifferentiated pile. Existing practices give useful building blocks. My problem is narrower: when I have multiple projects, privacy levels, and publication targets, how can AI help form knowledge without destroying the boundaries?

Files are better truth sources than chat logs

The first advantage of a local knowledge base is control.

Files have paths, versions, sources, ownership, and review history. They can be opened in Obsidian, searched with command-line tools, changed by Codex, checked by scripts, and tracked in Git. Chat logs are interaction traces. They are not good long-term fact layers.

The working rule is simple:

conversation is working memory
files are durable knowledge

Conversation helps me think. Stable conclusions must return to files. Otherwise every discussion starts from scratch, every project needs the same background repeated, and new ideas cannot reliably connect to older material.

Why not one giant vault?

Putting everything into one big vault sounds convenient until the boundaries disappear.

I research products, develop software, manage private projects, write public essays, and keep sensitive material in different places. These contexts have different privacy levels, source quality, update rhythms, and publication rules. If everything is flattened into one pile, an AI assistant can easily treat a project-specific conclusion as a global rule or carry private detail into public writing.

The federated model avoids that.

The central knowledge base stores long-term concepts, methods, and publication sources. Project directories keep project facts, code, research packages, and local conclusions. The publication node renders reviewed material into the website. AI assistants work in the current directory by default and cross boundaries only through narrow interfaces.

This is not folder aesthetics. It is fact governance.

Codex is a compiler here, not just a chatbot

In this system, Codex is not primarily a conversational partner. It is a knowledge compiler.

It can read source material, extract concepts, update topic pages, organize indexes, create publication source drafts, and check public boundaries. But it should not silently move project documents into the central knowledge base, and it should not invent missing facts inside the website repository.

The same AI tool has different roles in different directories:

  • In the central knowledge base, it compiles knowledge.
  • In a project directory, it works from local project facts.
  • In a publication node, it helps with rendering, routing, and build validation.

Without directory roles, an AI assistant quickly becomes a black box that can see everything, change everything, and explain too little about where its conclusions came from.

Obsidian gives the human a control surface

I still need Obsidian because the knowledge base is not only for AI.

Obsidian gives me reading, linking, backlinks, search, navigation, and manual editing. It is not there to replace Codex. It gives me a human cockpit for checking whether concepts are stable, whether a topic lacks evidence, and whether a publication source is ready to become public.

AI can accelerate compilation. I still decide what should remain local, what should be generalized, what can be published, and what should be deleted.

The real goal is continuity

The hardest part of knowledge work is not storage. It is continuity.

Today’s product research may become tomorrow’s topic page. A project retrospective may later become a reusable concept. A private engineering workflow may become a public methodology. A discussion about site publishing may become the rule that protects future articles from becoming source-of-truth drift.

Chat history does not handle that continuity well. A local federated knowledge base can.

It gives each layer a place: evidence, concepts, project facts, source drafts, publication records, and audit boundaries. More importantly, it lets the AI know what kind of material it is handling instead of improvising inside an unlimited context window.

That is why I do not treat chat logs as my knowledge base.

I do not need a smarter chat box. I need a knowledge operating system where humans, AI tools, local projects, and public publishing can work together over time.