The Edge of the Map

This morning I installed a system for planning that I have not used and am not sure I believe. It is Matt Pocock's wayfinder, a skill for agent sessions that treats the plan — not the code — as the thing too big to hold in one context window. You hand it a loose idea whose destination you can name but whose route you cannot see, and it charts a map on your issue tracker: a map made entirely of questions.

Not tasks. Questions. Each ticket on the map holds one decision — something that has to be settled before anyone builds — and a session resolves it by conversation, by a throwaway prototype, or by delegated research. The rule underneath is the interesting part: produce decisions, not deliverables. When nothing is left to decide, the map collapses into a spec and hands off. The whole apparatus exists to produce one document.

A task assumes the way is known

A task list is a plan that has already stopped listening. "Build the queue, add retries, write the dashboard" — each line presumes the route exists and only the order of operations is open. That is why task-sliced plans collapse on contact: the first real answer to a real question deletes half the list. One of the two hostile readers I ran the design past put the difference best: a task is a slice of an answer you already have; a decision ticket is a question you don't.

Wayfinder's load-bearing distinction is subtler, and it is the thing I would steal even if the machinery turned out worthless. The test for whether something becomes a ticket is not whether you can answer it — it is whether you can state the question precisely now. A question you cannot answer belongs on the map. A question you cannot yet phrase stays in the fog of war: a section of the map for suspected decisions you can feel coming but cannot write down. Most planning systems pressure both into the same format, manufacturing specificity before there is evidence for it. That is how vague unease becomes a confident task that should never have existed.

The machinery, briefly

The map is a single issue; each decision ticket is a child issue sized to one agent session. A session claims one ticket, resolves it, posts the answer, closes it, appends one line to the map's Decisions so far, and stops — never more than one ticket per session. The open, unblocked, unclaimed tickets are the frontier: the edge of the known, rendered by the tracker's own blocking links so a human can see what is takeable without opening the map. Resolving a ticket clears the fog ahead of it; whatever is now specifiable graduates into fresh tickets. The map itself stays an index, not a store, so each new session pays for the gists, not the history.

What the record shows

I have not run it, but its author has, hard. Pocock reports close to a hundred grilling, prototyping, and research sessions feeding a single map while planning a course — a scale no unbroken context could hold — and describes the map growing as he learned and shrinking as he found answers. The field reports he publishes are unusually honest about the failures:

• One user charted twenty-seven tickets; by the thirteenth, the rest no longer made sense — each later ticket resting on assumptions the earlier answers had invalidated.
• The "plan, don't do" default can be overridden in the map's own Notes block — which the agent writes. One user watched an agent write "this map carries execution" into its Notes and read it back in later sessions as its own licence, building on a live server. The constraint and its exemption live in the same file the constrained party owns.
• "The grilling is exhausting" is, per the docs, the sharpest live complaint, and it is unresolved. The verbosity causes decision exhaustion and strips out why each question is being asked. The human is the bottleneck, and the docs do not pretend otherwise.

What I could not verify

Some objections survive everything published so far. Once a ticket closes, its answer becomes a one-line gist in Decisions so far — and there is no verb for "this closed decision was wrong." The convention is to comment on the closed ticket and revise the affected ones, but a wrong answer keeps asserting itself in the index until someone does that by hand. Decisions are also coupled in a way tasks are not: the answer to one question changes what the next question means, and the one-ticket rule forbids settling them together. Parallel sessions share no context at all.

And the deepest one: the destination is named first and governs everything after, but discovery can reveal the destination itself was wrong. Pocock's reply — a map you designed to change is a scoping smell — is true and also convenient. Plenty of real projects learn where they are going by walking.

The honest version

Installed this morning. Zero maps run. Everything above is a review of a design and its public record, not a report from the field — the vetting was reading the machinery closely and running it past two frontier models as hostile readers, not living in it.

What I would underwrite today is not the tool but the distinction: there is a difference between a question you cannot answer and a question you cannot yet ask, and planning that forces the second into the shape of the first produces confident fiction. The vocabulary has earned its sharpness through revision — "decision-mapping" renamed because it was jargon, "scout" rejected because scouts go there and come back and a wayfinder takes you there, the fog section renamed once conflating it with out-of-scope proved to be a real bug. This is a fourth draft, and it reads like one.

Whether the machinery earns its keep is a different bet: that the scarce resource is my attention, and a system that makes each live question fewer and sharper is worth the ticket ceremony. Pocock caught himself saying, of an unrelated project, "I've done all the wayfinding, I just haven't built it." That sentence is the whole claim. If the map makes it true, the tool is worth the name it chose. I will find out on the next effort foggy enough to deserve one.