The three properties that matter
Repeatable. A lesson written as a note is written once. “Column grants are additive; revoke the table grant first or the narrower one is a no-op” was learned from a failing test on a Tuesday and has been applied to every project since without anyone thinking about it. The note is the memory. The person is free to learn the next thing.
Automatically applied. The index in context at session start is what makes this different from a wiki nobody reads. The tool sees “centralized polling with poke broadcast, for push-less APIs” in its first few hundred tokens, and when a task involves an API that cannot push, it connects the two on its own. No search, no remembering. The quality of each index line is what moves the odds: written for a stranger searching by problem, symptom and stack, not by title.
Continually improved. Notes go stale, contradict each other, and pile up. So the vault audits itself: a script that checks every link both ways and flags thin index lines, run automatically on every change. A gardening pass, monthly, merges near-duplicates and prunes.
And a conflict rule: if a new lesson contradicts an old note, stop and decide. Did I change my mind, or is the new information wrong? On a change of mind, the old note is updated in place with a dated line saying what it used to say and why it changed. Never two notes disagreeing. The history keeps the old version.
The habits that keep it alive
Save mid-session, not at the end. The moment a decision or gotcha is settled, it goes in. A long session’s context gets summarized, and the thing decided an hour ago is exactly what gets lost.
Read before designing. The obligation, not just the awareness. The tool is told to check, and to name the notes it applied, so stale ones get noticed.
Distil, do not dump. A raw source, a transcript, an article, is read once and turned into a note that stands alone. Nothing re-reads the raw source. Recall works on the distilled notes only.
Extract the general idea. Project work produces project notes. When a project note contains a lesson that would apply anywhere, it gets its own note that the project note links to. Otherwise the lesson is buried where only that project can find it.
For a company: the team version
Everything above works for one person. For a company it is the answer to a question leaders keep asking in different words: how do we make sure what one team learns about AI, every team gets, and how do we not lose it when someone leaves?
Two different payoffs answer that, and they arrive on a different schedule. The daily one: two people on different projects hit the same gotcha and solve it twice, which happens constantly and has nothing to do with anyone leaving. The rarer, sharper one: when someone does leave, the next person’s first AI session is already informed, because the record is put in front of the tool automatically rather than left for them to go and search for.
The team version adds four things to the mechanism above.
An owner. Someone whose job includes the monthly gardening pass, the same way someone owns the backlog. Every note also carries an author, so a genuine contradiction can be routed to the person who wrote it rather than argued about by whoever is in the room.
A route in. Anyone can save a note, from any tool, through the repository. A shared inbox folder for raw material that the owner distils.
A route out. Every project repository carries a pointer to the vault, so every AI session on every project starts with the same index. New projects get the pointer stamped in automatically. Nobody has to remember to connect it.
A conflict rule with no approval step. Two entries that look contradictory are usually both true under different conditions; state the boundary before calling it a conflict at all. When it is genuine, the author decides, or a named fallback if they have left, and the resolution is recorded, not silent.
What the rule deliberately does not add is review before a note gets saved — that would stop people writing things down in the moment, which is the one habit the whole thing depends on.
I have also used the same shape for something a vault is not: the bus-factor problem. A nightly automated draft of a handoff note per project, from the ticket system and the repository, that a developer edits and commits daily. The principle is identical. Logic that lives centrally cannot be forgotten or uninstalled per project.
None of it is tested by anything except an actual departure, which is a bad time to find out. So a quarterly drill, someone picking up a piece of work with zero help from whoever normally owns it, is the check that stays manual on purpose. Whatever they get stuck on is the real gap.
The full method for a team, with what good looks like for each part, is here: Standards and continuity for a small AI-coding team.
Why I would start here
If a company could do only one thing from its AI plan, I would pick this over any tool or feature. The tools will change. The lessons about using them well are what the company keeps, and a company that keeps them is a company that gets better at this every month while its competitors relearn.
Build your own
The full build guide, with the folder structure, the session-start hook, the standing rules and the audit script, is here: Build your own knowledge vault. It takes an afternoon. Start with ten notes, the ten things you would tell a new starter, and let the habit do the rest.
Earlier on this page is my own vault, mapped, and the six lessons that only showed up once its notes were linked. These pieces go deeper on individual parts.