Title reference items with the words your future self will search for, not the words that categorize what it is
For any reference item you store, write the title using the words your future self will search for when they need it, not the words that categorize what it is.
Why This Is a Rule
There's a fundamental asymmetry between filing and retrieval that most naming conventions ignore. When you file a reference item, you're thinking about what it is: "Meeting notes — Q3 planning." When you retrieve it months later, you're thinking about what you need: "What was the budget we decided on for the marketing campaign?" The category-based title ("Q3 Planning Meeting Notes") doesn't match the need-based search query ("marketing budget decision"). The item exists in your system but you can't find it because your filing self and your searching self use different words.
Search-oriented naming reverses the perspective: instead of asking "What category does this belong to?" when filing, ask "What will I be looking for when I need this?" and use those words in the title. "Marketing budget decision — $50K approved Q3" is findable when you search for "marketing budget" or "$50K" or "approved." The category ("Q3 Planning Meeting Notes") is useful for organization but useless for retrieval.
This principle becomes more important as reference systems grow. With 50 items, you can browse. With 500, you can scan categories. With 5,000+, you rely on search — and search only works when the stored words match the searched words. Every item titled for the filing context rather than the retrieval context is effectively lost in a large system.
When This Fires
- When saving any reference item (document, note, bookmark, file) for future retrieval
- When you can't find something you know you saved because you can't remember what you named it
- When building or organizing a reference system (PKM, file system, notes app)
- Complements Separate reference material (static lookup) from working notes (evolving thinking) — mixing them corrupts both retrieval and development (separate reference from working notes) with the naming strategy for the reference side
Common Failure Mode
Category-based naming: "Finance — Tax — 2025 Documents." This is an organizational hierarchy, not a retrieval aid. When you need your 2025 tax documents, you'll search for "W-2" or "1099" or "deduction receipts," not "Finance Tax 2025." The hierarchy makes the file system look organized but doesn't help you find what you need.
The Protocol
(1) When naming a reference item, simulate retrieval: "Six months from now, when I need this, what will I type into the search bar?" (2) Use those search words as the title. Include the specific nouns, numbers, and keywords you'd search for. (3) Front-load the most searchable words: "Marketing budget $50K approved — Q3 planning meeting" not "Q3 planning meeting notes including marketing budget." (4) Include disambiguation where needed: dates, project names, specific numbers, and key decision points that make this item findable among similar items. (5) Test: could you find this item by searching for two natural words? If the title doesn't contain any plausible search terms, rewrite it.