The policies it ships with

People and their agents follow these when they record in a collection made from this template. Its owners can change them.

1. A node belongs on a product roadmap when it documents an outcome-oriented bet or its result: an Intent (a desired outcome — a user-behavior change or business result — the team is betting on), an Eval (the measurement that says whether an outcome was met), a Decision (a prioritization call about what to bet on and why), or a Reference (the discovery, research, or data informing a bet). PASS when the candidate is one of these. FAIL when it instead describes HOW work gets built or delivered — a process step or implementation task, a release / changelog event, a UI spec, or a one-off incident — which belongs in a process collection or the backlog, not on the roadmap.
2. Only Intent, Eval, Principal, Reference, Decision, and Rule belong on a product roadmap. An Intent is a roadmap item — a desired outcome the team is betting on; an Eval is that bet's result — the measurement of whether the outcome was met; a Principal is the accountable owner; a Reference links the discovery, research, or data behind a bet; a Decision records a prioritization call; a Rule captures success criteria or guardrails. Delivery steps (Action), milestones (State), and shipped-event logs (Log) describe how and when work is built — they belong in a process collection or a changelog, not on the roadmap.
3. Only these relationship edge types belong on a product roadmap: `has_parent` (group an initiative under the outcome, theme, or objective it serves), `attributed_to` (a roadmap item → its accountable owner Principal), `supports` (an Eval result, or a Reference's evidence, → the item it measures or informs), `constrained_by` (an item → a Rule that sets its success criteria or guardrails), `relates_to` (a dependency or see-also between items), `derived_from` (a bet's provenance from discovery or a prior item), and `replaces` (a re-scoped item supersedes the one it replaces). Process sequence flow (`flows_to`) describes delivery, not strategy, and has no place on a roadmap.
4. Every committed (`queued` or `active`) roadmap item is attributed to the Principal accountable for its outcome — an `attributed_to` edge from the Intent to that owner. A `drafting` (parked / Later) idea may defer naming an owner.
5. Every committed (`queued` or `active`) roadmap item carries a `horizon` — its Now / Next / Later bucket — so the roadmap stays ordered by time-confidence rather than by precise dates. A `drafting` idea in the parking lot may defer its horizon until it is committed.
6. Every committed (`queued` or `active`) result links to the item it measures with a `supports` edge to that Intent. A result that measures nothing is a dangling metric; the `supports` edge is what lets the roadmap show whether a bet paid off.
7. Check the roadmap item's `prose`. PASS when it frames a desired OUTCOME — a change in user behavior or a business result, for a stated audience — together with how success will be measured (a metric and a target). A good item reads like `cut new-team setup time so 40% reach first value in week one`, not `build an onboarding checklist`. FAIL with a reason when it names only a feature or output to ship with no outcome behind it, states a vague theme with no measurable target, or reads as an implementation task. The point of a roadmap is the outcome, not the output.
8. Check the Eval result. PASS when it closes the loop on its bet: it states the target that was set (the `expected` metric value), the actual measured result, whether the target was met (its `last_status`: pending while still measuring, pass = validated, fail = invalidated), and the decision that follows — persevere, iterate, pivot, or kill — with the learning to carry forward. FAIL with a reason when it records a target with no result, a result with no target to judge it against, or a verdict with no decision or learning. A result that does not close the loop teaches the next bet nothing.
9. Check the Principal's `prose`. PASS when it names a single accountable owner for outcomes — a person, role, or team answerable for whether a bet pays off. FAIL when it is a vague label (`the team`, `product`) with no clear accountability, or an empty shell with only a bare name.
10. Lead with outcomes, not outputs. Frame each item as the change you want to see — a shift in user behavior or a business result — not the feature you will ship. `Build dark mode` is an output; `raise long-session retention by giving night readers a comfortable view` is the outcome behind it. The feature is just one bet on that outcome; name the outcome so a better bet can replace the feature without rewriting the roadmap.
11. Bucket every item into a Now / Next / Later `horizon`, and let commitment and detail fall off with distance: Now is in progress and fully specified, Next is coming up with less detail, Later is a direction — a problem worth solving with no committed solution yet. Resist putting precise far-future dates on the roadmap; they get read as promises and assume the estimate holds and the first solution works. Reserve real dates for high-integrity commitments made AFTER discovery (an extension: add a target date to a Now item, or coordinate the launch in a delivery collection).
12. Give every committed item one accountable owner — an `attributed_to` edge to the Principal answerable for the outcome, not merely whoever builds it. Shared ownership is no ownership.
13. Group bets under the outcome, theme, or objective they serve with `has_parent`, so the roadmap reads as a few goals with bets beneath them rather than a flat feature list. To align with OKRs, model the Objective as the parent Intent and each bet's Key Result as its target Eval — map outcomes to Key Results, never features to Key Results.
14. Prioritize explicitly and show your work. Record a prioritization call as a Decision (what you are betting on over what, and why), and capture the criteria or scoring behind it — value vs. effort, or RICE (Reach × Impact × Confidence ÷ Effort), or whatever your team trusts — as a Rule linked with `constrained_by`. Keep the score together with its inputs so the ranking stays auditable; the framework itself is your team's choice, not the roadmap's.
15. Ground bets in evidence. Link the discovery that informs an item — user interviews, an experiment, analytics, a brief, or an opportunity from a discovery tree — as a Reference via `supports` (or `derived_from` when the bet grew directly out of that finding), so a reader can tell whether a bet rests on insight or on a hunch.
16. Wire dependencies between items with `relates_to`, so a bet that is blocked by or must coordinate with another shows the link rather than failing silently when its prerequisite slips.
17. Close the loop — this is the half most roadmaps skip. Shipping is not success; a bet is done when it is MEASURED. When an item ships, give it a result Eval linked by `supports` that carries the target you set (`expected`) and, over the measurement window, the actual result; move its `last_status` from pending (measuring) to pass (validated) or fail (invalidated); and record the decision that follows — persevere, iterate, pivot, or kill — with the learning, before you `retire` the item. A failed bet that taught you something is worth more than a shipped feature nobody measured.
18. Revisit the roadmap on a cadence — quarterly to re-prioritize bets and score outcomes, more often (every week or two) when uncertainty is high — rather than setting it once and treating it as a contract. Re-bucket horizons as you learn. When a bet's direction changes, supersede it instead of rewriting it: create the re-scoped item, link it to the old one with `replaces`, and `retire` the original, so the roadmap keeps a history of what you bet on and why it changed.
19. A roadmap is not a backlog and not a release plan. Keep stories, tasks, and bug lists in the backlog, the delivery flow in a `process` Collection, and the dated shipped history in a changelog of Logs. Reference those siblings from a roadmap item rather than absorbing them — the roadmap stays at the altitude of outcomes and bets, linking down to execution rather than becoming it.
20. Agents: read `GET /<handle>/api/authoring-contract.json` and write with `POST /<handle>/api/changesets.json`. Create each roadmap item as an Intent with its `horizon`, its `attributed_to` owner, and (once it ships) its result Eval and the `supports` edge in the same changeset, rather than as disconnected nodes.