Every planning tool we tried failed the same way. The plan lived in one place and the work lived in another, and the two drifted apart quietly until the plan was a work of fiction that everyone still nodded at. The fix was never a better plan document. Plan documents are where good intentions go to become stale claims.
Then Matt Pocock published a skill called wayfinder, and it had the right bones. His idea: when an effort is too big for one working session and wrapped in fog, don't write the plan. Chart a map instead. The map's unit is not a task but a decision ticket: a question whose resolution is a decision. You work the frontier, the questions answerable right now, one at a time. Resolving one clears fog and reveals the next. And, critically, you refuse to pre-slice the fog: if you can't state a question sharply yet, it isn't a ticket, and no amount of planning enthusiasm is allowed to harvest it into fake ones.
We adopted the bones and rebuilt the body on our own substrate. We call the result Rasti, from Finnish orienteering, where a rasti is a control point you navigate to through terrain and punch to prove you were there. The name earns itself below.
The map lives where the work lives
Pocock's original keeps its maps on an issue tracker. Ours live in the same database as the roadmap itself. A map is a parent item; its decision tickets are child items; blocking relationships are real dependency rows; the frontier is a query. That one choice dissolves the drift problem that kills plan documents: there is no second store to fall out of sync, and every planning surface, including the map view itself, is generated from the same rows the execution views read. Our standing rule for status of any kind is generated or absent. If a number appears on a planning page, a query produced it. Nobody types "7 of 12 decided" anywhere, ever, and so that number is never a lie.
Visiting a control is not enough. You punch it.
Here is where our version stops being a planning method and becomes an evidence discipline. In orienteering you don't get credit for standing near the control. You punch it, and the punch is checkable. When a Rasti ticket resolves, the resolution lands as a decision record carrying the decider's verbatim words, with a where-and-when anchor, in the same substrate. The ticket closes citing it. The map's decisions-so-far index is generated from those records, never hand-written.
Months later, "why is it built this way" is one hop, not an archaeology dig through chat logs. And because the punch is a record rather than a memory, an agent working the codebase at 2am has the same access to the reasoning as the person who made the call.
Tickets are typed by how they resolve
Not every question resolves the same way, and pretending otherwise is how planning meetings happen. Rasti tickets carry a type:
- Judgment tickets wait for me. They queue into a gate walk where each arrives packaged with background, one committed recommendation, and the honest cost of each branch. Terse answers are fine; the conditions inside a terse answer are the ruling and get recorded verbatim.
- Research tickets never wait for anyone. They dispatch to background agents the moment they're filed, and downstream tickets cite the findings artifact.
- Prototype tickets resolve by reaction. When the question is "how should this look or behave," nobody word-engineers an answer. Something cheap and concrete gets built, the human reacts to it, and the approved artifact is the spec. Approval confers authority.
The routing is labels on the same items, which means "what needs a human decision right now" is one query, and so is "what did we already decide and never build."
You have to earn the right to chart
The uncomfortable discovery came before the first map. We ran a sweep for the foggiest efforts in the backlog, the best charting candidates, and the top nominee turned out to have been decided weeks earlier. The decision was recorded, clear, and thorough. The item never heard about it. It sat there radiating fog that had already lifted, and a charting session would have dutifully mapped it.
So the prerequisite for charting is a purge: cross-check every open item against every decision made since the item was last touched, and against the shipped code, in both directions. That last clause matters, because the purge birthed a class we didn't expect: ruled-but-unexecuted. A decision existing is not the decision being real. Some items flagged as stale turned out to be the only thing in the system still remembering an unbuilt ruling, and closing them would have silently erased a mandate. They don't close. They convert into execution carriers citing their ruling, and they stay visible until the code agrees with the decision.
"What should we work on now" is a page, not a meeting
Once decisions, work, and evidence share a substrate, the daily question answers itself in four generated bands: what's broken, first, always; then the decision frontier, ranked by how much each answer unblocks, computed from the real dependency graph; then the work that's dispatchable this minute; then the short list only I can move. The system computes the can. The should comes only from recorded judgment, priorities and rulings already made, because a planning page that invents its own priority scores is just a new way to lie.
What it costs and what it pays
Rasti is not free. Charting is a real working session, punching is discipline, and the purge was a genuine slog. The payback is token economics as much as clarity: judgment gets spent exactly once, at the control point, and every session afterward, human or agent, reads it for the price of a query. The day we adopted it, eight rulings from a single sitting became running build lanes within the hour, coordinated across two orchestrating agents working the same repositories without a single collision, because the plan they were both reading was the same live rows.
The system caught its own author
Honest coda. Twice on adoption day, the discipline flagged mistakes made by the agent building it. The first was the stale recommendation above: the charting candidate that was already decided, caught because I remembered and the substrate could prove me right in one query. The second was a mis-scripted verification step that pushed a colleague-agent's staged work early, caught within a minute, closed with a written procedure change, and recorded, verbatim, like everything else. Both closures live in the same system as every other punch.
That is the real argument for Rasti. Not that it produces prettier plans, but that it produces a system where being wrong is cheap, visible, and short-lived, and where the proof you were somewhere is never anyone's memory.
The wayfinder pattern this practice builds on is Matt Pocock's, open-sourced in his skills repository. The bones are his; the punching is ours.