The default research move is to open a search engine. You type your question, you skim the first three results, you find what you need, you close the tab. Half an hour later you've forgotten that you ever ran the search. Two months later you run the same search again, find the same three results, skim them again, forget again.
This is the most expensive habit in knowledge work, and I had it for a decade.
The alternative is what I call vault-first research. Look at your own notes first. The web is the fallback, not the default. The premise sounds arrogant when you write it down, "I'll trust my own notes over Google", but in practice it's the opposite. Your own notes are the cheapest and most relevant source for whatever you keep looking up. Treating them as the first stop forces you to invest in the notes, which then makes them worth treating as the first stop. The feedback loop is the entire point.
The compounding problem with search-first
Every time you search for something you already learned once, you pay a tax. The tax is small per incident, a few minutes of skimming, a quick re-derivation. The tax compounds.
Worse, the tax obscures itself. The re-derivation feels productive. You are, after all, finding the answer. You're not visibly losing anything. What you're losing is invisible. It's the version of you who built up a personal corpus of the things you've already figured out, who walks into research questions with a head start instead of a blank tab.
I noticed this pattern only when I started timing my actual research sessions. The same questions kept arriving, six months apart. The same articles kept getting opened. The same conclusions kept getting redrawn. The thing missing was a place to put the conclusion the first time, so that the second time I could read it instead of re-deriving it.
What a vault actually is
The word "vault" is doing some work here. It's a structured personal knowledge base, a directory of markdown files, organized by topic, that I read and write to constantly. Mine lives in a folder I sync between machines. The tooling is unremarkable, plain markdown, a text editor with good search, a few conventions about file naming.
The unremarkable tooling is the feature, not a limitation. The vault has to be cheaper to write to than the web is to search. If writing a note takes longer than running a search, you'll skip the note. Once you skip the note, the vault degrades, and search becomes the default again. The whole pattern collapses.
A few rules I've found work:
- One file per topic, not per session. A note about "how Stripe handles failed webhooks" is one note that gets updated over years. Not one note per debugging session.
- Active reasoning at the top. The most recent thinking lives at the top of the file. Historical notes live below. Reading the file in reverse-chronological order tells you the story of how your understanding evolved.
- Link generously. Every concept that has its own file gets linked when it comes up. This is the property that makes the vault navigable two years later, when you don't remember what you wrote where.
- Write the conclusion, not the journey. What did you decide? What did you reject? What constraint did this run into? The journey is forgettable; the conclusion is the value.
The retrieval pattern
I run a four-level retrieval pattern. The naming is mine; the underlying logic is "cheap signals first, expensive signals last."
- Level zero, the project's own context file. Two hundred tokens. What am I doing in this project right now, what's blocked, what was the last decision.
- Level one, the top three sections of the project's full context document. Six hundred tokens. The active reasoning artifacts.
- Level two, the full context document plus any referenced docs. Two thousand tokens. Read this when level-one signals indicate the relevant context is here.
- Level three, grep across the entire vault. Knowledge files, cross-project context, maps of content. Four thousand tokens. Only when the question genuinely spans projects.
Most research questions resolve at level zero or one. The whole pipeline is built around resolving as cheaply as possible, escalating only when the cheap level doesn't have the answer. This sounds like a programmer's organizational fetish. It's actually the discipline that prevents me from defaulting back to web search out of frustration.
What goes in the vault, what doesn't
Not everything I read goes into the vault. The filter is brutal and the brutality is the point.
Things that go in:
- Decisions I made and the reasoning that produced them. These have value forever.
- Patterns I noticed that generalize across projects. The vault is where pattern-recognition compounds.
- Numbers I've verified, with sources. Especially numbers I expect to look up again.
- Definitions of domain terms I had to figure out. Anything I would have to re-Google.
Things that don't go in:
- Code that's already in a repo. The repo is the source of truth.
- Information I can get back from running a command. Why store
git logoutput when I can ask git. - Anything in a CLAUDE.md or README. Those files are already the canonical version.
- Summary or activity logs that decay fast. The vault is for durable knowledge, not state.
The discipline is harder than the rule. Most things feel like they should go in. Most things shouldn't.
The confidence gate
The piece that took me longest to figure out: a confidence threshold for retrieval.
Before I start working on a domain I haven't touched in a while, I run a quick self-check. Do I have full context for this? If the answer is below maybe ninety-six percent confidence, I pause and retrieve before acting. The number itself is arbitrary; the discipline is what matters. Retrieval costs about five hundred tokens and three seconds. Acting on stale context and redoing work costs far more. The check forces me to price both costs explicitly.
There are a handful of domains where I always check, regardless of confidence, anything touching auth, schema migrations, pricing, tag taxonomies. These are the domains where the cost of a wrong move is high enough that even ninety-six percent confidence isn't enough.
Where the vault wins over the web
Eight times out of ten, when I have a question, my vault answers it better than the web does. The vault knows what I already know. It frames the answer in terms I already use. It links to the related concepts I'm going to need next. It tells me what I decided last time and why.
The web is great when I'm genuinely off the edge of my own knowledge. It's a poor substitute for my own memory.
I'm not all the way there yet. The vault still has gaps. There are still days when I default to a search out of habit and notice myself only halfway through the third tab. But the trend is in the right direction, and the trend is what compounds.
The vault uses plain markdown files. The file conventions are documented in the vault's own root README, and the conventions evolve. The tooling has changed three times in two years. The files have outlasted every tool.