Anatomy of a Node Passport

Every node in a MonkeyLLM forest travels on a passport: a title, a summary held to sixty tokens, tags, and aliases. It looks like metadata. It is the most deliberate design decision in the system: the exact place where intelligence gets spent so the model can spend less.

Four fields, one job

A passport exists so an agent can judge a node without paying to open it. During a hunt an agent skims dozens of passports and opens only a few nodes, so every field has to earn its keep.

Title. A name specific enough to decide from, the kind a well-run wiki would have. "Payment retry backoff policy", not "Notes (final v2)".

Summary. The sixty-token contract. Not a teaser, a verdict: what this node knows and when opening it pays. Sixty tokens because passports are read constantly, and reading one has to be close to free.

Tags. Coarse geography: billing, infra, compliance. Enough to orient, never a taxonomy project.

Aliases. The names people actually use. "SSO" next to "single sign-on", the project code name, the old service name half the team still says. Aliases are where vocabulary mismatch goes to die.

Paid once, at write time

None of this is free, and the honest place to pay for it is ingest. We measured the write-time trade across 100 heterogeneous real-world documents: 1.71 s per document, with 100% of summaries passing the sixty-token contract and zero broken links afterwards. The Ingest screen (this post's cover) shows that work as a job you can watch: files, folders, and clips going in, passports coming out.

This is the Forest Principle applied to a schema: spend intelligence on the environment so you can spend less on the model. Read time never pays the curation cost again, and read time is where every hunt, every session, every day lives. The longer argument is in the Forest Principle.

Field-weighted BM25 cashes it in

Entry search, the way an agent first drops into the forest, is BM25 over SQLite. BM25 is the classic keyword-ranking function behind most search engines, and SQLite ships it out of the box: no embeddings, no vector database, no GPU on the entry path.

On our benchmark corpus it reaches recall@5 = 1.00 at 1.3 ms p95. The reason is the passport: weighting the curated fields, title and aliases above all, closed the gap to hybrid search entirely. The mismatches an embedder is usually hired to smooth over ("dunning" versus "payment retries") get solved instead by a deliberate alias sitting exactly where the ranking function looks.

The embedder is optional and supported, not removed. If your corpus genuinely needs semantic recall, plug one in. It is just no longer the toll booth at the front door.

What discipline feels like

Curation sounds precious until you reduce it to reflexes. If a summary cannot say why the node exists within sixty tokens, it is two nodes. If a hunt misses because the agent searched a word the passport never uses, the fix is a one-line alias, not a new retrieval stack. Tags stay coarse and few. And agents planting new nodes are held to the same contract as the ingest pipeline, mechanically, so the forest cannot quietly rot. Every passport you sharpen makes every future hunt cheaper.

Reproduce the table

The corpus, the question sets, and the harness are committed, and every number in this post regenerates with one command; the paper is a preprint and we say so. The primitives docs describe the passport fields precisely. Reproduce the entry-search table yourself from https://github.com/JimmyWesley/MonkeyLLM, or read the preprint via https://monkeyllm.com.