8.3
Making It Searchable
Why this exists
Your vault works today because it's small and you wrote everything in it recently. In a year it'll hold hundreds of notes, most written by a version of you who's forgotten writing them, and plain search will start missing things — because you'll search for the word you'd use today, not the word you used then.
This is the last lesson of the course and it closes the loop that opened in 2.4.
The idea
Two kinds of search, and you need the second one only when the first stops working.
| Finds | Fails when | |
|---|---|---|
| Text search | The exact words you typed | You used different words |
| Meaning search | Notes that are about the thing | Rarely — but it's fuzzier |
Start with text search and stay there as long as it works. For a few hundred notes, searching for a word genuinely finds it, and pointing Claude Code at the folder — from 8.2 — covers most of the gap, because it reads the notes rather than matching strings.
When it stops working, it stops in a specific way: you know you wrote something about a problem, you search the words you'd use now, and nothing comes back — because you filed it under different language. That's the signal, and until you've felt it you don't need this lesson's tooling.
Meaning search is 2.4's retrieval, pointed at your own writing. Same mechanism: the notes get indexed by what they're about rather than which words they contain, so a search for "why did the sync keep failing" finds a note titled "expired credentials in the booking job" — no shared words at all.
Setting one up is a real but small job, and it's exactly the kind of thing you now know how to do: point Claude at the vault, describe what you want, read the plan, build it in rounds, test it, keep it read-only.
The honest advice: don't build this yet. Build it when text search fails you twice. Most people set up elaborate retrieval over forty notes and never use it, because forty notes don't need it. The value arrives with volume.
What matters more than the tooling, and what actually determines whether you ever find anything:
- Title notes by the problem, not the solution. You search for problems.
- Say what you'd have typed when stuck. Put those words in the note.
- Link related notes. Links survive vocabulary drift better than search does.
Do those three and text search keeps working far longer than you'd expect.
Do
- Test your current search. Pick five things you know are in the vault and search for each using words you'd use today, not the words in the note.
- Note how many you found. That's your honest baseline.
- For anything you couldn't find, fix the note rather than the tooling — retitle it after the problem, and add the words you actually searched for.
- Re-test. Most misses get fixed here, without building anything.
- Add links between related notes. Five minutes of linking beats an hour of indexing.
- If two or more still fail: build meaning search. Point Claude at the vault, describe what you want, plan mode, rounds, read-only.
- If you build it, test it against the same five searches and compare.
- Write
search.md: what you searched · what plain search found · what you fixed in the notes · whether you needed an index.
Step 3 is the lesson. Most search failures are note-naming failures, and fixing the note helps every future search — the index only papers over it.
Done when
That's the course.
Eight weeks ago you opened a black window and closed it again. You can now read a system you didn't build, diagnose it from a log, investigate without breaking anything, ship a fix and prove it, find out before anyone tells you, decide what to escalate, automate the parts that repeat, and keep what you learn where it'll still be in a year.
Go and open week-0.md — the note you wrote on the first day and haven't looked at since. That's the only honest measure of how far this went.
Never do
Don't build retrieval before plain search fails you. Twice. Elaborate indexing over a small vault is a project that feels productive and changes nothing.
Don't title notes after the answer. You search for problems, because problems are what you have when you're looking.