FID lifecycle — the bookkeeping that keeps the board honest

The pipeline is Backlog → Investigation (if needed) → FID (epic) → Jira tickets → To Do → Implementation → review → approval → merge. This skill is not the process; it is the hygiene that stops the process rotting into several disagreeing records.

One principle underneath all of it: every fact lives in exactly one place, and moving work forward means moving the record, not copying it.

Taking an item off the Backlog

The Backlog holds problems, not solutions, including the founder's own running notes. When you pick one up:

1. Decide, explicitly, which path it takes: straight to a ticket (small and obvious), investigation (approach or cost unclear), or parked with a stated trigger — and if parked, name the condition that would un-park it. "Not scheduled" with no trigger is how an item sits for weeks while the thing it was waiting for was itself abandoned.
2. When the FID exists, delete the Backlog item. Do not leave both. A Backlog entry whose work has moved on is litter, and worse, it is a second description of the same thing that will drift. Replace it with nothing — the FID is now the record. If the Backlog page held context the FID does not, move that context into the FID first, then delete.
3. If an investigation concludes "do not build", the Backlog item still goes — but record the decision and its reasoning on the FID or investigation page. A killed idea is a valuable artifact; an undeleted Backlog entry is not.

Creating a FID and its epic

A FID is the Confluence page (behavioural intent, invariants, kill conditions). Its Jira epic is the tracking mirror.