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 in an idea tracker when it is an Idea — a candidate solution someone proposes (a feature, an improvement, an experiment, a new offering: something a team could choose to pursue) — or an Intent naming the opportunity ideas serve: a problem, unmet need, or desired outcome worth solving. PASS when the candidate is one of these. FAIL when it is instead a defect report (expected-vs-actual broken behavior — that belongs in a bug tracker), a committed task or scheduled work item (that is a backlog or process collection), a raw complaint or feedback quote with no proposal in it (record it as evidence supporting an idea, not as the idea), or — for an Intent — a feature dressed up as an opportunity: an opportunity names a problem or outcome, never a solution.
2. Only Idea, Intent, Eval, Log, Reference, Rule, and Principal belong in an idea tracker. An Idea is a candidate solution awaiting a verdict — its prose is the proposal, its `problem` the need behind it, and `promoted_to` / `rejection_reason` how it ended. An Intent is an opportunity (a problem, need, or outcome worth solving) that ideas cluster under; an Eval is an assessment — a scoring pass or validation experiment; a Log is one demand event (someone asked for this again); a Reference carries evidence (feedback, research, data, competitor moves); a Rule states the evaluation criteria; a Principal is the shepherd accountable for moving an idea. Delivery steps, milestones, and decision records belong in their own collections — promote an idea there instead.
3. Only these relationship edge types may be used in an idea tracker: `has_parent` (an idea → the ONE opportunity Intent it serves; a narrower opportunity → its broader opportunity or outcome), `supports` (evidence References, demand Logs, and assessment Evals → the idea they back, request, or test), `attributed_to` (an idea or opportunity → the Principal who shepherds it), `constrained_by` (an idea or opportunity → a Rule stating the evaluation criteria or a strategic guardrail), `relates_to` (a see-also or dependency between related or competing ideas), `replaces` (the canonical idea supersedes a duplicate), and `derived_from` (an idea → the demand Log, feedback Reference, or prior idea that sparked it). Process sequence flow (`flows_to`) describes delivery, not ideation, and has no place here.
4. Every committed (`queued` or `active`) idea carries a `problem` — the user or business need behind the proposal, ideally in the proposer's own words. The prose is the candidate solution; the `problem` is the durable part a reviewer evaluates. A `drafting` inbox jot may capture the proposal first and frame the problem at triage.
5. Every committed (`queued` or `active`) idea is attributed to the Principal who shepherds it — an `attributed_to` edge from the idea to that Principal — accountable for moving it to an honest verdict: promoted, parked, or rejected. An idea in evaluation with no shepherd rots in the funnel. A `drafting` inbox jot may arrive ownerless.
6. A committed (`queued` or `active`) idea names the opportunity it serves — a `has_parent` edge to the Intent for that problem, need, or outcome — so competing ideas for one opportunity sit side by side and can be compared. Strongly recommended and surfaced as a warning, not enforced: an idea may be triaged before the opportunity map exists.
7. Every committed (`queued` or `active`) idea serves AT MOST one target opportunity: it carries at most one `has_parent` edge to an Intent. An idea pinned to two opportunities can't be evaluated — its impact and its competitors are ambiguous. Split it into one idea per opportunity, or pick the primary one. A `drafting` sketch is exempt.
8. Every committed (`queued` or `active`) assessment links to the idea it assesses — a `supports` edge from the Eval to that idea. An assessment that assesses nothing is an orphaned verdict; the edge is what lets the tracker show how an idea earned its evaluation. A `drafting` assessment may defer the link.
9. Check the idea's prose (the proposal) and its `problem`. PASS when the prose pitches ONE concrete, actionable proposal and the `problem` states a real user or business need — who has it, what the pain is, and why it matters — that would still be worth solving if this particular proposal died. FAIL with a reason when the record bundles several distinct proposals (split them and link with `relates_to`), when the proposal is too vague to evaluate (`make the product better`), or when the `problem` merely restates the proposal as a lack or absence (`we don't have feature X`, `users can't do X yet`) instead of naming the need behind it.
10. Check the assessment's prose and fields. PASS when the assessment shows its work: it names the method (a scoring pass against stated criteria such as ICE/RICE with the per-factor inputs, or a validation experiment such as a prototype test, painted-door, or interview round with what was run and observed) AND a verdict or recommendation a reader could challenge — validated / invalidated / score with what follows from it. FAIL with a reason when it is a bare gut call (`feels high-impact`), a score with no inputs to audit, or an experiment with no observed result.
11. Keep capture frictionless — the inbox is sacred. Anyone (or any agent) jots an idea the moment it occurs, as a `drafting` node in the proposer's own words, without a perfect pitch: a bare one-liner is a valid jot. Credit the proposer — set `proposer_id` to their real user id when they are an in-product user (it references the users table; an invented id fails the write), or name an outside source (a customer, a sales call) in the prose or `problem`. Ideas die in unsent drafts, not in triage.
12. Keep one idea per record. Each Idea is exactly one proposal, so it can be evaluated, promoted, or rejected on its own; split a record that bundles several proposals and connect the parts with `relates_to`. Variants of one proposal stay on the canonical record (note them in the prose) rather than spawning siblings.
13. Separate the problem from the solution. The prose is the candidate solution; the `problem` field is the user or business need behind it — who has it, what the pain is, why it matters, ideally in the proposer's own words. The problem is the durable part: solutions are cheap and interchangeable, and a strong problem with a weak proposal is a better record than the reverse. Never write the problem as the solution restated as a lack (`we don't have X`).
14. Dedupe to one canonical idea. Search before filing; when a duplicate arrives anyway, fold its wording and evidence into the canonical record, retire the duplicate, and link the canonical idea to it with a `replaces` edge (the `supersede` changeset op does both at once) — so demand consolidates onto one record instead of fragmenting across near-duplicates.
15. Record demand as a stream, not a tally. Every time someone asks for an idea again — a support ticket, a sales call, a forum thread — capture it as a Log (who asked, when, in what context, how acute) with a `supports` edge to the idea. A demand event is a fact that already happened, so record it as `active` (the collection-wide `drafting` default is for ideas, not facts); the same goes for evidence References. Frequency, recency, and who's asking are then read off the stream, which is the evidence a prioritization call needs; a vote count on the node tells you none of that. When a request arrives that no tracked idea covers, the orphan Log is the signal to write one — link the new idea `derived_from` the Log that sparked it.
16. Ground ideas in evidence. Link the feedback quotes, research, analytics, and competitor moves behind an idea as References with `supports` edges, and mark provenance with `derived_from` when the idea grew directly out of a finding. An idea backed by evidence can be evaluated; an opinion can only be argued with.
17. Cluster ideas under opportunities — the opportunity-solution-tree shape. Model each problem, unmet need, or desired outcome as an Intent, nest narrower opportunities under broader ones with `has_parent`, and link each idea to the ONE target opportunity it serves. Several competing ideas under one opportunity is healthy: it makes 'compare and combine before you commit' the default reading, and it keeps solutions tied to the problems that justify them.
18. Triage on a cadence — weekly or biweekly — rather than on arrival or never. Triage is where a jot earns commitment: dedupe it, frame its `problem`, name its shepherd (`attributed_to` a Principal — a person or an agent), link its opportunity, and move it to `queued` — or park or reject it honestly. An inbox that only ever grows is where ideas go to die.
19. Evaluate against explicit criteria, and show your work. Capture the team's rubric — ICE, RICE, value-vs-effort, strategic fit, whatever your team trusts — as a Rule linked with `constrained_by`, and record each scoring pass or validation experiment (a prototype test, a painted-door, an interview round) as an Eval that `supports` the idea, carrying its inputs and verdict so the ranking stays auditable. Test before you invest: a cheap experiment beats a confident opinion, and an invalidating result is a success — it killed a bad bet for the price of a test.
20. Walk an idea through the funnel on its lifecycle: `drafting` is the inbox and the parking lot (a jot may be a bare one-liner), `queued` is triaged (deduped, problem framed, shepherd named), `active` is in evaluation (the few ideas actually being scored and validated — keep this set small), and `retired` is closed. Completeness and quality gates apply once an idea is committed (`queued`/`active`); the inbox is spared.
21. Close every idea with an honest disposition, and close the loop with the proposer. Promote: record what the idea became in `promoted_to` — the roadmap bet (Intent), decision record, or delivery work it turned into, usually in a sibling collection — then retire it. Reject: retire with a written `rejection_reason` that is kind, specific, and durable (future proposers of the same idea will find it; offer the alternative when one exists). Park: keep it `drafting` with a dated `rejection_reason` note saying what would revive it (a demand threshold, a dependency landing). In every case, tell the proposer what happened and why — an idea that dies of silence costs you every idea that person never files again.
22. Prune rather than hoard — the pipeline is not a commitment. An idea nobody has touched in months gets retired with an honest reason, not kept 'just in case': a backlog of a thousand stale ideas is worse than none, because nobody trusts or reads it. Trust resurrection over hoarding — a good idea will come back with fresh demand (and its retired record, found by the next proposer, carries the context forward).
23. Agents: read `GET /<handle>/api/authoring-contract.json` and write with `POST /<handle>/api/changesets.json`. Capture a jot as a bare `drafting` Idea; at triage, set its `problem`, and add its `attributed_to` shepherd and `has_parent` opportunity edges in the same changeset. Log each repeated request as an `active` Log with a `supports` edge to the canonical idea (use `supersede` to fold duplicates), record each assessment as an Eval together with its `supports` edge to the idea it assesses in one changeset, and close by patching `promoted_to` or `rejection_reason` and retiring — never by deleting.