How do you build a personal knowledge system you will actually search?
Build it around retrieval, not storage. Write each note’s index line as the symptom you had — the sentence you would type at 11 p.m. when the thing breaks — rather than the topic it belongs to. Then cap what you start, log every failure as it happens, and discard notes nobody has touched in 30 days.
Most advice on how to build a personal knowledge system is really advice on how to file things. Filing is the easy half. The hard half is that the version of you who needs the note is panicking, and the version of you who wrote it was calm and organized. Those two people do not use the same words.
Why do topic-organized notes disappear exactly when you need them?
Because you search with the words of the problem, not the words of the category. A note filed under “authentication” is invisible to someone typing “works in the test tool but returns 401 in the app.” The index line has to be written in the vocabulary of the moment of pain, or the note never surfaces.
There is decades-old memory research behind this. Endel Tulving and Donald Thomson’s encoding specificity principle (Psychological Review, 1973) holds that how well a memory is retrieved depends on how closely the cue available at retrieval matches the cue present when the memory was encoded. A tidy topic label is a cue you invented afterward, in a calm state. It matches nothing about the state you will be in later.
The cost is not theoretical. The McKinsey Global Institute’s report The Social Economy (2012) estimated that knowledge workers spend roughly 19% of the workweek searching for and gathering information — close to a full day out of five. And research by Gloria Mark and colleagues at UC Irvine (No Task Left Behind? Examining the Nature of Fragmented Work, CHI 2005) reported that workers took an average of about 23 minutes to return to an interrupted task. A knowledge system that fails to answer on the first search does not merely waste the search. It spends your recovery time too.
What does a symptom index line look like next to a topic one?
A topic line names the subject; a symptom line reproduces the failure in the words you would use while it is happening. The second is longer and uglier, and that is the point. Ugly, specific sentences match the search you will actually type. Here are index lines from my own notes, before and after the switch.
| Before: topic as the index line | After: symptom as the index line |
|---|---|
| Encoding conventions in scripts | Korean text came out as ??? in the console after the file saved fine in the editor |
| Deployment notes | Build passed on my machine, failed on the host, and the log said nothing until I checked environment variables |
| API authentication | The same request works in the test tool and returns 401 from inside the app |
| Backup strategy | Restored the backup and the newest week of work was simply not in it |
| Note-taking workflow | Wrote the note, could not find it three weeks later, wrote the same note again |
Read the right column out loud. Every line is something a person would type into a search box in a bad mood. That is the only test an index line has to pass.
How did symptom indexing let me ship software I could not read?
I built and shipped working software without being able to read code. The only thing that made it possible was writing down every point of failure the moment it happened — what I did, what broke, what the screen said — instead of writing tidy summaries afterward. The failure log became the index, and the index became the manual.
Here is what I noticed. When I could not read the code, I could not reason forward from cause to effect. I could only reason backward from symptom to “what did I do last time this exact screen appeared?” So the note that saved me was never “how routing works.” It was “the page loads locally and 404s after deploy.” Ten of those, written in the minute they occurred, were worth more to me than a hundred well-organized summaries written at the end of the week.
Two rules made the log survive contact with reality:
- Write it while it is broken, not after it is fixed. Once you fix something, you forget the wrong words you were using ten minutes earlier — and those wrong words are precisely the search terms your future self will use.
- Record the failed attempts, not just the fix. “Tried A, no change; tried B, made it worse; C worked” saves the next hour. A clean note that shows only C does not.
Which indexing approach fits which kind of work?
Topic-first works for material you browse deliberately, like study notes. Tag-first works for material you slice by attribute, like sources. Symptom-first works for anything you consult under pressure — troubleshooting, procedures, decisions you will have to defend later. Most personal systems fail because they use the first two for the third job. The comparison below is a conceptual one, based on how each scheme requires you to remember a note in order to find it again.
| Approach | What you must recall to find a note | Where it breaks | Best for |
|---|---|---|---|
| Topic-first | The category you chose months ago | Under stress, when you remember the error and not the category | Study material you read start to finish |
| Tag-first | Your own tag vocabulary, consistently applied | When tags drift and three near-duplicates coexist | Sources and reference libraries |
| Symptom-first | Only what went wrong — which you cannot forget, because it is happening | Nowhere much; index lines are longer to write | Troubleshooting, procedures, anything used in a hurry |
How do you stop the system from rotting once it is built?
By rationing starts and scheduling discards. I keep an open-items ledger as the single source of truth for stalled work, tagged by what each item is blocked on: a decision, another person, an external reply, or me. Items blocked on a one-line decision are the cheapest progress available, so they get cleared first.
A backup scan of my own files once turned up 41 tasks I had abandoned mid-flight. Not 41 ideas — 41 things I had actually started. That is why I now cap work in progress at two started items per project. Ideas stay unlimited; only starting is rationed. An idea costs nothing to hold. A started task costs attention every day it sits open.
The other half is treating abandonment as maintenance rather than failure. Anything untouched for 30 days gets surfaced weekly as a discard candidate, and most of them get discarded. A knowledge system that never deletes becomes a place you stop searching, because you no longer trust what comes back.
I learned all of this the expensive way. After 26 years inside one institution, I left and had to rebuild from nothing the structure that the institution had quietly supplied: deadlines, review, and someone who noticed when a task stalled. Nobody notices now except the ledger. So the ledger has to be honest.
What are the first three notes to write today?
Do not migrate your archive. Write three new notes about problems you have already solved twice, each with a symptom sentence as the index line. Then log the next thing that breaks while it is still broken. Three retrievable notes beat three hundred filed ones, and the system compounds from there.
None of this is a productivity trick. It is the same formula I write about everywhere else — Belief × Thinking × Action. Belief that your future self deserves a findable answer. Thinking clearly about how retrieval actually works instead of how filing feels. Action small enough to take today, while the problem is still on the screen in front of you.
If you want the same structure applied to goals rather than notes, the VisionDream app turns a vision into the daily habits that carry it, and my book Why Do I Fail While Others Succeed? covers the rebuild this system came out of.
Your notes do not have to be beautiful. They have to answer when you call them by the name of the problem.