Why You Can't Find Your Notes - The Science of Re-finding Information

This article is part 1 of my series on finding notes in Obsidian. The overview, with the map of all 12 parts, is The Complete Guide to Obsidian Search.

The best search upgrade you can make happens when you write a note, before you ever open a search box.

Cognitive psychology has a name for this. The encoding specificity principle (Tulving and Thomson, 1973) says that a retrieval cue works only to the extent that it overlaps with what was stored together with the memory. Translated to notes: you will find a note again through the cues you'll have in mind later, like who was there, when it happened, which project it was for, why you saved it, and the words you'd use to describe it.

If none of those cues are in the note (or in its title, properties or links), no search engine will find it reliably, AI included.

There's a related trap called the Collector's fallacy, described by Christian Tietze on zettelkasten.de in 2014: "'to know about something' isn't the same as 'knowing something'". Every note you dump into your vault without a decent title, a type or a link makes every future search less precise/harder. Notes you can't find are often notes you never processed. (I wrote a short note about it: Collector's fallacy.)

A few habits fix most of this. This article covers the research behind them (more than forty years of studies on how people keep and re-find their own information), and the three models I use to evaluate a system: the FILE framework, the findability stack and LATCH. The next part covers how I name notes, which metadata I add and how I tag; part 3 covers how I use folders (yes, I still use them), how I link, how I organize by time, and what I do with notes I'm done with. Each habit takes seconds (or no time at all when automated) at capture time and saves minutes (sometimes hours) later.

TL;DR

• You re-find a note through the cues you stored with it (the encoding specificity principle). If its title, properties and links don't carry them, no search engine finds it reliably, AI included.
• Notes you can't find are often notes you never processed. That's the collector's fallacy, and it makes every other search less precise.
• People navigate first and search as a last resort. Navigation also costs less attention, and your own words beat a borrowed taxonomy.
• Use FILE to audit a system: is it easy to File, Identify, Locate and rEtrieve? Run it on your last ten notes, or on a new tool BEFORE you migrate.
• The findability stack has six layers, from structure to AI search. When a search fails, fix the layer that should have caught the note.
• Audit a note type with LATCH: count how many of Location, Alphabet, Time, Category and Hierarchy lead to it.

What personal information management research adds

Researchers in Personal Information Management (PIM) have studied how people keep and re-find their own stuff since the early 1980s.

William Jones wrote the first book to cover the whole field, Keeping Found Things Found (2007). He splits PIM into three activities: keeping (deciding what to save, and how), finding and re-finding, and meta-level work (organizing, maintaining, managing the flow of information). The title is his thesis: the hard part is finding again what you once found. Put differently, every decision to keep something is a guess about what you'll need later. Keep too little, and something useful is gone. Keep everything without a title, a type or a link, and the clutter makes every other note harder to find. It's the collector's fallacy again, seen from the research side.

Back in 1983, Thomas Malone studied how about ten people organized their desks. He described files (titled and ordered) and piles (untitled and unordered), and found that classifying is hard, which pushes people toward piles. His recommendation was to support *deferred* classification: put things down now, classify them later. That's what a daily note followed by a weekly ingestion does (see the daily notes section of part 3). The daily note is the pile; the Knowledge Ingestion Process is the deferred classification. Malone also described the second job of organization, reminding, which I cover in part 12.

In 2008, Bergman and his colleagues found that people navigate to their files far more than they search for them (I cover that study in the overview of this series). A later study by Bergman, Tene-Rubinstein and Shalom offers one explanation: retrieving a file by navigation used less attention than retrieving it by search. Participants who navigated remembered more words in a task they performed at the same time. That's one more reason to keep a few predictable folders and hub notes: walking them takes less attention than writing a query.

Then there's Lansdale (1988), whom I cite in the metadata section of part 2: people often can't remember the category they used. A follow-up study by Lansdale, Simpson and Stroud (1990) found that recall was better when people chose their own attributes to describe their items. So use your own words in titles, aliases and tags, rather than a taxonomy borrowed from someone else.

Finally, Peter Morville, in Ambient Findability (2005), looks at findability at two levels: how easily a single item can be found, and how easily you can find your way through the system as a whole. This series covers both. Names, aliases and properties make each note findable. Folders, tags, links and the daily-note timeline make the vault navigable.

The FILE framework

In my course, I use a simple mnemonic to evaluate any organization system. Information should be easy to:

• File: deciding where a new note goes should take seconds
• Identify: you should recognize what a note is at a glance
• Locate: you should know where to look
• rEtrieve: you should get to it fast when you need it

I call it the FILE framework. In the course, I use four questions to evaluate a system:

• How easy is it to file new information?
• How quickly can you identify what you're looking for?
• How well does your system support searchability?
• How fast can you retrieve information when you need it?

Here's how each letter translates into concrete choices in Obsidian:

• File. A note's type decides where it goes and which template it gets. A meeting note is a meeting note: no hesitation. If you regularly stop and wonder "where should this go?", your structure is too clever or you failed to automate what needs to be (i.e., filing should be automated!). Even better: let a plugin or a template do the filing for you (more on that in part 3).
• Identify. The title, the type suffix, the icon and the first few properties should tell you what a note is before you open it. 2025-01-21 - Work session (Meeting) is a meeting note. Obsidian Starter Kit V5 (Project) is a project. Untitled 23 is... nothing.
• Locate. You should know where to start looking: the quick switcher for a title, a tag for a type, a folder for a kind of note, a daily note for a date, a Map of Content for a topic. If you can't name a starting point, the note is effectively lost, even if search could technically find it.
• Retrieve. Once located, getting to the note should take a few keystrokes. Retrieval speed comes from good names, consistent tags and links, not from browsing.

You can also use FILE as a quick audit. Take the last ten notes you created and ask the four questions for each. Did filing take more than a few seconds? Could you tell what each note is from its name alone? Do you know which tool you'd use to find it in a year? My rule of thumb from the course: "if you consistently struggle to find information quickly, your retrieval process might need improvement." It's also a good lens to evaluate a new tool or a new organization method BEFORE you migrate everything into it. I wrote more about the framework in Introducing the FILE Framework for Information and Knowledge Management and about LIFT in this article.

Best Practices for Organizing Information: LIFT Principle

Discover the LIFT principle and why you should apply it to better organize data, information and knowledge

Sébastien DuboisSebastien Dubois

The findability stack

I couldn't find any published model that describes the different layers of findability in a personal knowledge base. So here's mine: the findability stack. Each layer is a fallback for the one above it, and resurfacing runs across all of them.

The top layers are investments you make when you create a note. The bottom layers are effort you spend when you look for it. AI makes the bottom layers much cheaper, but it works much better when the top layers exist.

Notice that layers 1 to 4 are about navigation, and 5 and 6 about search. That matches the research: navigate when you can, search when you must.

The stack is also a debugging tool. When you finally find a note after a frustrating search, ask yourself which layer should have caught it, and fix that layer on the spot:

• You found it through full-text search after three attempts? The title was probably the problem. Rename it (layer 2).
• You found it, but only by remembering the person it was about? Add a link to that person's note, or a property (layers 3 and 4).
• You needed AI to find it because you only remembered the idea? Add an alias with the words you used, and link it from the relevant Map of Content.

Each fix takes seconds, and the next search for that note (or any note like it) will hit a higher layer. Over time, you'll need the bottom layers less and less.

A second lens: LATCH

The findability stack tells you when you invest in findability. Richard Saul Wurman gave us a model for another question: in which ways can information be organized? In Information Anxiety (1989), he summarized them with the acronym LATCH, also known as the Five Hat Racks: Location, Alphabet, Time, Category, Hierarchy.

Each letter maps to Obsidian features you already have:

Watch out for the last one. Wurman's Hierarchy is NOT a folder tree. It means ordering things on a scale: cities by size, books by rating, tasks by urgency. In Obsidian, that's a sort in a Base. Sort your notes by number of backlinks (descending), and your hub notes rise to the top.

LATCH makes a good audit. Pick a note type and count how many letters you can use to reach it. A meeting note in my vault: Location (the meeting notes folder), Alphabet (the topic in its name), Time (the date in its name, and the daily note that links to it), Category (its type tag, plus links to the project and the people). That's four out of five. Hierarchy isn't needed for meetings. Now compare with a note called Thoughts sitting in the vault root: Alphabet only, and a weak one.

The more letters a note type supports, the more different memories lead to it. That's the encoding specificity principle again, turned into a checklist.

The findability principles I teach in my course

Everything in this article and the next three comes from my Knowledge Management for Beginners course. Finding information gets its own lessons there: the FILE framework, the search escalation ladder, tags as pathways, naming conventions, folder structure, and live demos of search in Obsidian.

As I say in the course: "whether you use a Tool for Thought or not, the findability of your notes depends on how well you organize them, and how consistent you are with naming, tagging, metadata and linking." The course will help you build that system step by step, with practical demonstrations and an example vault. If you want the foundations behind this series, that's where they live.

Knowledge Management for Beginners - Stop Drowning in Information | Transform How You Learn

10+ hour video course teaching Personal Knowledge Management. Build a second brain that helps you think better, learn faster, and actually use what you know. 200+ students. Lifetime access.

Knowledge ForgeOlivier Larue

Conclusion

Whether you'll find a note again is mostly decided when you write it. The research says so, and FILE, the findability stack and LATCH turn that into checks you can run on your own vault today. Pick one note type, run the LATCH audit, and fix the weakest letter. Part 2 shows how, with names, aliases, note types and metadata.

Next in the series: Design Notes You Can Find - Names, Aliases, Types and Metadata in Obsidian. Previous: the overview of the series.

Prefer to read the whole series in one place? I turned it into an ebook, The Obsidian Search Handbook, with an exercise at the end of every chapter (the Complete edition adds a starter pack and worksheets).

Free cheat sheet. The commands and operators worth remembering, and the search escalation ladder (which tool to try first, depending on what you remember about the note), on 13 pages you can keep next to your vault. Enter your email and I'll send it right away: the Obsidian Search Cheat Sheet.

Free Obsidian Search Cheat Sheet: operators and the search escalation ladder

A free 13-page PDF with the Obsidian search operators worth remembering and the search escalation ladder: which tool to try first, depending on what you remember about the note.

Sébastien DuboisSebastien Dubois

About Sébastien

Ready to get to the next level?