Navigation vs Search

Two ways to retrieve from a body of linked notes. Search matches a phrase you already have against every page and returns a ranked list. Navigation follows the structure the notes already carry (links, backlinks, sections, containment) one hop at a time. They answer different questions, and a wiki needs both (Blumenfeld — Scaling Karpathy's LLM Wiki (Neo4j), Anthropic — The Components of Agent Memory).

What each answers

Question	Mode	Cost on a plain file system
Where is "rate limiting" mentioned?	search	one scan (or an index)
What does this page link to?	navigation	read one file
What links to this page?	navigation	scan every file, no index
What sits two hops away?	navigation	two full scans
Which pages are load-bearing?	navigation (in-degree)	scan everything, count
Which pages cluster without anyone naming the cluster?	navigation (communities)	not answerable
What changed downstream of a contested claim?	navigation	not answerable

Blumenfeld's point is that the right-hand column grows with the wiki, while an index over the structure makes "a hop a pointer rather than a scan." His thesis: "Give the agent a structure it can navigate, not just a box it can search."

Why both

Anthropic — The Components of Agent Memory measured the combination: search alone 53%, wiki alone 48%, wiki plus search 61%. Read through this distinction, search finds the entry point and navigation follows the overlap from there. The wiki's links are judged relations (Surface vs Deep Structure); search only sees shared words. Navigation is also how a semilattice is read without flattening it: one neighbourhood at a time, never the whole (Tree vs Semilattice).

In this wiki

• The recipe anticipated the order. Karpathy — LLM Wiki Gist: read index.md first, which "works surprisingly well at moderate scale (~100 sources, ~hundreds of pages)," then add proper search. Navigation by link was left to Obsidian's graph view, for the human. This wiki is at 25 sources and ~105 pages.
• The human already has the index. The front door's build step produces the graph (pages, sections, links, backlinks with the linking sentence, log events) and the page view shows a center's neighbourhood (Front Door Pattern Language, pattern 3).
• The agent does not. INGEST's "search before you write" runs on qmd and grep. When qmd broke during the auto-ingest run, the job fell back to grep, which is the linear scan the article describes. At ~100 pages this costs nothing; the failure mode is the one Blumenfeld names: "The retrieval failure quietly becomes a write defect."
• Remedy adopted 2026-11-08: expose the same graph.json to the agent through a small CLI (site/scripts/graph-query.mjs: backlinks, links, neighbours, path, most-linked, orphans, unresolved, section). One builder, two readers (Do It Once, at the Right Place). A graph database is deferred until a scan is actually felt (Living Structure: add the differentiation where its absence hurts).
• Lenses are navigation made visible. In-degree is the Hierarchy lens; community detection is the Location lens (LATCH).

Connections

• Agent-Maintained Wiki — the pattern whose scaling this distinction explains.
• Agent Memory — "injected top layer + searched depths" is a two-mode design; navigation is the missing third verb.
• Dreaming (Offline Memory Consolidation) — orphans, dangling links and in-degree are navigation queries a dream pass should run.
• The Borges Map — a summary that stays a pointer to a section is compression without loss.
• Method Reflection — T5.

Sources

• Blumenfeld — Scaling Karpathy's LLM Wiki (Neo4j) — the hop-vs-scan argument and the data model.
• Anthropic — The Components of Agent Memory — the wiki-plus-search result this distinction explains.
• Karpathy — LLM Wiki Gist — index-first, then search; the scale estimate.