Anyone whose knowledge base has grown so large it has become hard to navigate, and who wants to split it without knowing what criterion to use.
A replicable splitting method: change one decision criterion, divide into three vaults, establish a filing workflow, and handle one exception.
One decision question (who actually uses this?), a concrete three-vault structure, and an index-first filing workflow.
Everything in one vault: the bigger it grows, the harder it gets
My knowledge base kept growing. In the beginning, everything went into the same vault: project plans, meeting notes, code, websites, Skills packs, all mixed together.
Over time, three concrete problems emerged:
- Finding a document required scrolling a long way, and search would surface a flood of unrelated results.
- When an AI agent read the vault, it would wade through human-facing documents it could not use, or fail to locate the executable scripts it needed among hundreds of files.
- I myself could no longer remember where something lived, so every filing decision became a moment of hesitation.
I decided to split the vault. But before acting, I ran into one prior question: what criterion to split on. Choose the wrong criterion and the split only makes things worse.
First attempt: splitting by file type does not work
My initial criterion was file type: documents in one vault, code in another.
Problems surfaced immediately. I have a public-facing website that is simultaneously code (it needs deployment and version control) and a finished product meant for an audience. Sorted by file type, it belonged in both vaults and fit cleanly into neither.
This was not a single edge case. Any deliverable that happens to be code would hit the same boundary. I abandoned the approach entirely. The problem was not that the split was too coarse; the criterion itself was wrong.
A working approach: ask "who actually uses this?"
I replaced the criterion with one concrete question. For every file coming in, I ask: who actually uses this?
There are only three answers, each mapping to one vault.
Everything I personally consult when working or making decisions: project plans, notes, meeting records, reference documents. This vault is also the entry point every AI agent reads first.
Assets the machine runs: code, version control, deployment files, Skills backups. I do not browse these directly; the AI reads and executes them.
Finished deliverables: products, public websites, Skills packs for clients or course participants. I am still gradually migrating content into this vault.
Back to the website that was stuck: it exists to be used by an audience, so it goes into the public-facing vault. Whether it is also code no longer enters the judgment. One question, and the ambiguous case is resolved.
How it works: read the index first, then route and file
Three vaults alone are not enough. With more vaults, an AI agent has more opportunities to file something in the wrong place. To prevent that, I keep an index page in the main vault that serves as the mandatory first stop for every filing action. The workflow has three steps:
The index page holds four cross-references: a directory index, a tag index, a project index, and a people index. Every agent reads this page first to understand the landscape before touching anything.
Apply the question above: is this item for human use, for AI execution, or for an audience? Pick one of the three without hedging.
Place the item in the main vault, secondary vault, or public-facing vault based on the answer. Attach the appropriate tags and update the index. The index stays current with every filing action.
One exception: operability takes priority over clean categorization
Following the "who uses this" criterion produces one situation that looks contradictory.
Some Skills packs are read and triggered by AI agents. By the criterion, they should live in the secondary vault for AI execution. But they must stay in the main vault for the AI to trigger them at all. Move them to the secondary vault and they stop working.
So Skills packs I use internally stay in the main vault. This is easy to miss when organizing a knowledge base: the method is a tool in service of real-world operation, not the other way around.
The whole method in three sentences
First, change the criterion: stop sorting by file type and ask "who actually uses this?" instead. Second, divide into three vaults: human-facing content goes to the main vault, AI execution assets go to the secondary vault, audience-facing deliverables go to the public-facing vault. Third, establish the workflow: read the main vault index before every filing action, determine who the item is for, file accordingly. When following the rule would break operability, let operability win.
This is the AI knowledge management method I use myself. The full folder structure, how to build the four cross-reference indexes, and how to connect them across vaults: I will continue to document all of it here. If you want to organize your knowledge base together, the community is a good place to start.
Two free sessions every month.
Join the LINE Community ↗