You Did Not Start With the Question You Ended With

You did not start with the question you ended with. A hard search through your own notes is a sequence, not a query: the question shifts as you read, and useful finds arrive one at a time. A single search box assumes the opposite. The fix is not a better matcher — it is keeping the trail in a file.

You know the scene. You typed a phrase, then a second, then a third. By the fourth try you were looking for something next to what you set out to find — and two useful notes had gone past on the way. You kept neither.

Marcia Bates described this in 1989, in a paper Crossref now counts as cited more than 1,100 times.¹² Her finding was that in real searching "the query itself (as well as the search terms used) is continually shifting, in part or whole."¹

Fifteen years later, in a small study at MIT, Jaime Teevan and colleagues found a second problem underneath the first. Their participants "used keyword search in only 39% of their searches, despite almost always knowing their information need up front."³ They walked to the target instead.

What the search box assumes about you

The search box assumes you arrive with one fixed question, type it once, and receive one set of results that either contains the note or does not. Stated charitably, that is a reasonable design: if the matcher is good enough, the note appears. Most attempts to fix retrieval therefore improve the matcher.

Bates called this assumption the classic model of information retrieval, and summarized it in one sentence: "Fundamental to it is the idea of a single query presented by the user, matched to the database contents, yielding a single output set."¹

Read that against the search field in any notes app. One query. One match. One output set.

It is an old shape. Bates wrote that the model had been used in information-science research "for over twenty-five years" — and she was writing in 1989, which puts its roots in the early 1960s at the latest.¹ The arithmetic is ours; the observation that it still describes the box on your screen is too.

The obvious reply is that modern search is smarter — it ranks results, forgives typos and matches meaning. Bates anticipated the strongest version of that reply. Even iterative relevance feedback, she argued, stays inside the classic model, "because the presumption is that the information need leading to the query is the same, unchanged, throughout."¹ A better matcher still answers one question at a time.

We have argued before that you should find your notes by searching, not organizing, and that search has a recall ceiling when you cannot name the words a note uses. This is a different wall. You can know every word and still lose the session.

Why can't I find the note I know I wrote?

Often because what you are looking for changed while you looked. Bates calls this an evolving search: each thing you read reshapes the question, so the query you typed first is not the query you need by the fourth try. A search box built for one fixed question keeps answering a question you have already left.

Bates is explicit that this is the ordinary case, not a failure of the searcher: "Rather the query itself (as well as the search terms used) is continually shifting, in part or whole. This type of search is here called an evolving search."¹

The mechanism is simple. You open a note that is almost right — it mentions a meeting and the week it happened. Now you are searching for the meeting.

Bates puts that step in one line: "Each new piece of information they encounter gives them new ideas and directions to follow and, consequently, a new conception of the query."¹

The finding has held. Marti Hearst's Search User Interfaces, published by Cambridge University Press in 2009, sets the static model against what observation shows: "searchers' information needs change as they interact with the search system."⁴ And, more simply: "Information encountered at one point in a search may lead in a new, unanticipated direction."⁴

Bates was writing about bibliographic databases, not notes. But the move she describes is the one you make every time an almost-right note sends you somewhere else.

Even a fixed question gets found in steps

Even when the question does not move, people rarely jump straight to a note. In a 2004 study of how people searched their own email, files and the web, most searches did not use the search box at all. People took small, local steps toward a target they already knew.

Jaime Teevan, Christine Alvarado, Mark Ackerman and David Karger called the behavior orienteering. Their participants "navigated to their target with small, local steps using their contextual knowledge as a guide, even when they knew exactly what they were looking for in advance."³ The opposite move — typing the answer in and landing on it — they called teleporting.³

The counts run against intuition. Only 34 of 81 searches for specific information used keyword search, 42%, against 23 of 42 searches for general information, 55%.³ People used the box less when they knew exactly what they wanted.

The paper's title carries its conclusion, and the introduction spells it out: "even when a person knows exactly what they are looking for, the perfect search engine might not be enough."³

The study is small — 15 computer-science graduate students at MIT — and the authors say plainly that "we present only qualitatively-based findings here."³ Treat it as a careful observation, not a law.

A second study points the same way. Ofer Bergman and colleagues surveyed users of desktop search engines about how they retrieve their files. On average, users "estimated that they used navigation for 56-68% of file retrieval events but searched for only 4-15% of events."⁵ Those are self-estimates, and only the abstract is public, so nothing more is claimed for it here.

The abstract's most useful line is about timing: "search was used mainly as a last resort when users could not remember file location."⁵ That is the moment this essay is about. By the time you reach for search, memory has already failed once — and the box offers you a single shot.

The value is in the berries, not the basket

What works instead is collecting as you go. Bates' model says a hard search is satisfied by a series of small finds picked up at each stage, not by one final result set. The answer to the question you ended with is often assembled from notes you passed on the way.

Her wording is exact: "the query is satisfied not by a single final retrieved set, but by a series of selections of individual references and bits of information at each stage of the ever-modifying search. A bit-at-a-time retrieval of this sort is here called berrypicking."¹

Then the image that makes it stick: "The berries are scattered on the bushes; they do not come in bunches. One must pick them one at a time."¹

Hearst reports the same result from a 1993 study by O'Day and Jeffries, who interviewed 15 business analysts. In Hearst's summary, "the main value of the search was found to reside in the accumulated learning and acquisition of information that occurred during the search process, rather than in the final results set."⁴

Bates also noticed that people move through a body of material in ways a query cannot express. She describes six widely used search strategies; the first is footnote chasing, "moving backward in successive leaps through reference lists."¹ In a folder of linked notes the same move is ordinary — you follow a link from an almost-right note to the one it cites.

Re-finding makes the point sharper. In a year of web search logs from 114 users, Teevan, Eytan Adar, Rosie Jones and Michael Potts found that "as many as 40% of all queries are re-finding queries."⁶ They also found that "The query associated with a repeat search may differ from the initial query but can nonetheless lead to clicks on the same results."⁶

That study measured web search, not personal notes, so the 40% does not transfer. What transfers is the shape: people come back for the same thing by a different road, and nothing records the first road.

What your notes app already remembers

Some of the trail is already kept. Obsidian's own documentation shows that its search narrows with each added word, lists your recent search terms, and can copy or embed results. What no search history records is the sequence: which note each phrasing led to, and why you kept it.

The facts are on the page. "Each word in the search term is matched independently within each file," the Search help page says, and meeting work "returns files that contain both meeting and work."⁷ Every added word narrows the list. It also says: "Open Search with an empty search term to list recent search terms."⁷ Results can be copied out, and a query code block embeds search results inside a note.⁷

So the formulations survive. A history of search terms is a list of the roads you tried — with the destinations removed.

A saved search kept as a file you own goes further: it keeps the one query worth running again. But a saved query keeps the final formulation and drops everything before it — the three phrasings that failed, the note you opened by accident, the reason the fourth attempt worked.

That dropped part is the berrypicking. It is also the part you will need the next time the same question comes back by a different road.

Is a session file just more collecting?

Not if you write it the right way. A session file records finds from notes you already wrote, one line each, with a sentence in your own words about why the find mattered. That is a retrieval log. Clipping a page to read later is the opposite habit, and the one worth avoiding.

The worry is fair. Christian Tietze named the Collector's Fallacy in 2014: the comfort of saving things mistaken for knowing them. His correction is blunt — "having a text at hand does nothing to increase our knowledge."⁸

A session file passes that test because of what goes into it. Nothing is imported. Every line points at a note that already exists, and each carries a clause you had to think to write: this is where the number actually was, this contradicts the other one.

Hoarding adds material. A trail adds judgment to material you already had.

What to do the next time a search runs long

Open a plain Markdown note the moment your second phrasing fails, and log the session as it happens: the question you started with, each phrasing you tried, each note you kept with one line of why, the dead ends, and the question you ended with. Five habits turn a lost hour into a file.

1. Start the file at the second miss, not the first. One failed query is noise. Two is the start of a session.
2. Write the starting question in one sentence. You will want to compare it with the last one.
3. Log each phrasing as you type it. Note what it returned, even if the answer was nothing.
4. Keep each find with one line of why. Link the note; the why is the part no app can reconstruct.
5. Close with the question you ended with. Then link the session file from the note you finally used.

A finished session file looks like this:

# Search session — 2026-09-25

Started with: the meeting where we decided to drop the weekly report
Ended with:   who argued to keep it, and what they said it caught

## Tries
1. "weekly report" — 31 notes, mostly the reports themselves
2. "drop the report" — nothing
3. "reporting cadence" — [[2026-04 planning notes]], almost right: mentions the meeting, not the reasons
4. followed its link to [[2026-04-17 team meeting]] — the actual meeting
5. "caught" inside that note — the objection, and who raised it

## Kept
- [[2026-04-17 team meeting]] — the decision and the one objection; the objection is the real answer
- [[2026-03 incident review]] — the issue the weekly report had caught; why the objection mattered
- [[2026-04 planning notes]] — only as the bridge; it names the meeting date

## Dead ends
- tag #reports — too broad, 60+ notes
- searching the objector's name — they are named differently in older notes

## Next time
Search the incident, not the report.

Each line of that file does work. The tries show which words your notes actually use. The kept list is the berries. The dead ends save the next search from repeating them. The last line is the question you ended with, turned into advice.

Because the file is ordinary Markdown in a folder you control, it is searchable like any other note. A later search for the same meeting will land on the session itself. The choice between one note per file and one big file doesn't matter here; a session log works either way.

When one search box is enough

For most lookups, one box is enough. A known-item lookup — a phone number, a recipe, a note whose title you remember — is served well by a single query, and a session file would be clutter. The trail pays off only on the hard searches: the ones where the question moves.

Teevan's own data carries this caveat. Of the searches the team classified, 81 were for specific information and 42 for general information.³ A specific target does not drift the way an evolving question does, and nothing in this essay claims that every search evolves.

Recording also has a cost, and some people choose not to pay it. One Obsidian user asked for a setting to turn off recent search history because "It's not a feature I use and find it distracting".⁹ That is a reasonable preference — a trail you never read is noise.

The rule of thumb is short. One query, no file. Two misses, open one.

Frequently asked questions

The questions below are thread titles from the Obsidian community forum, quoted as their authors wrote them. Each is a version of the same problem, a search that took more than one try, and each answer points back to the evidence above rather than restating it.

"How to find notes again in overall flat structure?"

In a flat vault, finding a note again is usually a series of steps rather than one query. In a survey study of personal files, people estimated that they navigate far more than they search, and reach for search mainly when memory of a location fails.⁵ Record the steps of any search that misses twice, and the next one starts from your trail.

"How could I see the number of results from multiple search queries within a single note?"

The author's own workaround is to "make a search, copy the search results, paste them in another note".¹⁰ That is berrypicking done by hand, and it is the right instinct. A session file makes it deliberate: one line per query, the result that mattered from each, and a sentence on why it mattered.

"Link to Search Results"

Search results can be embedded in a note with a query code block.⁷ A stored query can also be kept as plain text you own. Both keep the final formulation. Neither records the path that led to it, so pair the saved query with a short session file when the search took real work.

"Option to delete individual items from search history"

Obsidian keeps your recent search terms and lists them when you open Search with an empty field.⁷ That history is a list of formulations. Curating it is reasonable, but the items worth keeping belong in a note: a search term plus what it found and why it mattered is worth more than the term alone.

"Setting to disable recent search history"

A fair request. Recording a trail has a clutter cost, and for quick lookups it adds nothing. A session file avoids the problem because you open it on purpose, only for the searches that run long. The automatic history can stay off; the deliberate record is the one that earns its space.

Keep the trail

A search that runs long is not a failure of memory or of the matcher. It is a sequence — and a sequence can be written down. The question you ended with is usually better than the one you started with, and the notes you passed on the way are the evidence for it.

This essay rests on Marcia Bates' berrypicking model and the orienteering study by Jaime Teevan and colleagues; the session file is our practical reading of both.

The box will keep answering one question at a time. The file can hold the whole walk.

A session file is just another plain Markdown note — the kind mnmnote.com keeps locally, in your browser.