A pointer rootnote — addresses, not knowledge

Most rootnotes tell an agent what to do. This one tells it nothing. It is a routing table: a list of things that exist elsewhere, what each is for, and how to reach it.

It is also the cheapest document in the set by a wide margin — a few hundred tokens that make a library of any size reachable, while loading none of it.

Where things live: {{library_root}} How to reach them: {{library_access}}

The entries

One line each. Replace these with your own; the shape is the point.

If you need to…	Fetch
write anything published — voice, spelling, headings	house-style.md
design or change a UI surface	brand-guidelines.md
call the payments API, or understand how other products call it	integrations/payments.md
set up cloud infrastructure for testing	infra/cloud-testing.md
know what was decided about data retention	decisions/retention.md

Fetch only what the task in front of you needs. The conditional phrasing is not decoration — it is the entire efficiency argument. A pointer file whose entries are not conditional is a slower way of loading the whole library.

What is deliberately not available

• Anything about the billing system. It is not documented; ask.
• Client-specific material. It is not in the library and must not be added.

This section is not optional. Without it, an agent that fails to find something concludes it does not exist, and proceeds on that basis. Absence of a pointer is a fact about the pointer file, not about the world, and only this section can tell the two apart.

Hook the decision, not the activity

The entries above read if you need to do X. That phrasing has a failure mode, and it was found in this portfolio rather than reasoned about.

An agent facing an unsigned desktop build wrote that signing and notarising would need a human for the credential step — and named the rootnote that says otherwise while doing it. The machine already held a notary profile, so the whole thing was automatable; it took ten minutes once the document was actually read. The index worked. The document was found. The document was cited.

The hook was read when notarising, which fires on the activity. The moment the document was needed was one step earlier: deciding whether notarising was something it could do at all. By the time the activity would have started, the decision to hand it back had already been taken.

So phrase each entry as the earliest moment the document could change the answer, which is usually a decision and not a task:

Instead of	Write
when signing a macOS app	before concluding signing needs a person
when writing for publication	before deciding what can be published here
when integrating the payments API	before assuming how payments behaves

A hook that names the activity cannot fire for whoever is deciding whether the activity is theirs — and that decision is where most of the value was.

The direction of the failure is worth noting, because it is not the one people guard against. Nothing was done badly. Work that was already solved was handed back, with a plausible reason attached, and what the human saw was a considered division of labour rather than a mistake. Over-delegation is invisible to everybody except the person who already knew the answer — which is precisely the person the document existed to spare.

The one rule that keeps it working

Never summarise what a document says. Entries are addresses and purposes, never content.

The moment an entry reads “the style guide requires sentence case”, the pointer file has become a second, worse copy of the style guide — and the second copy is the one that drifts, because nobody updates a file they think of as an index. Worse, an agent that finds the answer here will not fetch the source, so the stale copy wins every time and nothing reveals it.

The test: every entry should be useless without fetching the thing it points at. If a reader could act on the entry alone, it has started summarising.

Note what that test does not catch. An agent can name the right document, produce text that reads as though it consulted it, and be contradicted by the document — and nothing in the output distinguishes the two. Citing is not reading, and the difference is invisible downstream. No property of a pointer file prevents that; the only tell is a claim that disagrees with its own source, which requires somebody who already knows.

Keeping it honest

Check it in both directions. A pointer to something that has moved is worse than no pointer, because the agent spends effort failing. A document in the library that nothing points at is invisible, which is the same as not existing. Those are different faults with different causes, and a one-way check finds only the first — which is the one people think of, and the less costly of the two.

Whatever holds the library should be able to list what is in it, so that listing against this file is a diff somebody can run.

Date it. This is the file most likely to rot quietly, because nothing breaks when it does. An agent following a dead pointer simply works without the material, and produces something plausible.

Why this is a good trade

By the usual test — does it tell the agent something it does not know, or change something it would otherwise do — a pointer file is unusually pure. It contains no general knowledge, because addresses are not general. It instructs no behaviour that would have happened anyway, because an agent cannot guess a path.

It is close to the only document that is all signal, and it is the mechanism that lets the rest of the set stay small: anything too large, too general, or too rarely needed to sit in a rootnote can live in the library and be reached from one line here.