Project Backlog Operating Model
Canonical backlog hierarchy, optional Finder intake, requirements boundary, and provider-writing rules
Project Backlog Operating Model
This glossary defines the provider-neutral product hierarchy, optional Finder intake, Requirements Phase boundary, roadmap, and mutation authority shared by Finder and backlog-writing skills.
Product Topology
Product/Backlog Root
└── Product Area
└── Initiative
└── Epic
└── Story [one V* milestone iteration]
└── Task [same V*, blocker relations when needed]Fog is lateral provenance. It records intake, decisions, evidence, and the backlog objects it enriches or produces, but it is not another ownership level.
Business Finder ──optional projection──> Product Area / Initiative
Functional Finder ──optional projection──> Business structure / Epic
Requirements Phase ──accepted `OUT-###` outcomes──> derived Epic / Story / Task identities
Fog ──exact accepted production evidence for resulting delivery scope──> completeTerms
Product/Backlog Root
One provider-native destination for one product. Several independent roots may exist in the same provider workspace.
Product Area
A stable top-level product responsibility inside one Product/Backlog Root.
Initiative
A business goal inside one Product Area. Writers reuse and enrich an existing matching Initiative before proposing another.
Epic
A long-lived product slice inside one Initiative. An Epic may be enriched by several Fogs and span milestone iterations.
Story
One shippable product outcome inside an Epic. Every Story belongs to exactly one contextual V* milestone iteration.
Task
An atomic, independently ownable unit of Story delivery. A Task is understandable within its Story, traces to stable specification authority, and inherits the Story's contextual V* milestone. Tasks and blocker edges are derived only when supported by accepted requirements; no fixed Task count is required.
Fog
An external intake, uncertainty, decision-history, and delivery-provenance record. It retains its immutable original Business or Functional intake lens. It may own several generic Kind/grilling children plus direct Research and Prototype support children.
Business Finder
An explicitly human-invoked optional intake lens for nontechnical business intent. It may project Product Areas and Initiatives, never Stories or Tasks.
Functional Finder
An explicitly human-invoked optional intake lens for product behavior. It may project Business structure plus Epics, never Stories or Tasks, and does not require Business Finder to run first.
Requirements Phase
The only route that runs Requirements Grill, Create Spec, and delivery-depth Write Backlog projection. It can start directly from bounded requirements or consume optional Finder context. Create Spec assigns neutral OUT-### outcome identities; Write Backlog derives actual Epic, Story, and Task identities after compilation.
V* Milestone Iteration
A provider milestone representing one contextual product delivery iteration. It is not a sprint, provider Cycle, or provider Iteration field. Stories and Tasks belong to one iteration; Product Areas, Initiatives, and Epics may span iterations.
Normalization
An explicit backlog-reconciliation operation. It detects duplicates, stale status, invalid hierarchy, missing metadata, roadmap drift, and provider/wiki disagreement. It automatically repairs only unambiguous mappings; structural changes require preview and approval.
Intake And Delivery Flow
direct bounded requirements ------------------+
optional Business / Functional Finder context +--> Requirements Phase
-> Requirements Grill
-> Create Spec (`OUT-###`)
-> Write Backlog
-> derived Epics / Stories / TasksFinder is not a maturity sequence or prerequisite. Business, Functional, and Technical are not Grilling stages or provider fields. Reaching a Finder result returns control without claiming the Fog is complete. Research and Prototype can support uncertainty but never authorize backlog projection independently.
No schema or route imposes a fixed number of Grilling children, specifications, Stories, or Tasks. Requirements determine the eventual delivery shape.
Mutation Authority
write-backlog is the only physical provider writer. It owns initialization, allowed Finder projection, Requirements Phase delivery projection, exact-identity reconciliation, normalization, delivery-status writes, provider readback, and Linear/GitHub mechanics.
Before mutation it inspects the project wiki, configured Product/Backlog Root, repository identity, fresh provider objects and relations, milestone iterations, fields, and views. Existing coherent structure is reused first. Stable provider identity plus durable wiki identity authorizes enrichment; title-only or ambiguous matches authorize no writes. Material hierarchy, roadmap, boundary, milestone, merge, split, reparenting, or reorganization changes require an authority-derived preview and explicit approval.
Project Context And Views
The project wiki owns the full product brief, business objectives, target users, boundaries, constraints, operating rules, repository link, and roadmap context. The provider carries its supported projection and links back to that authority.
| View | Contents |
|---|---|
| Product Map | Product Area → Initiative → Epic, without Story or Task noise. |
| Roadmap | Ordered V* milestones with Story and Task progress rolled up through Epic and Initiative outcomes. |
| Fogs | Fog status, original lens, affected structures, generated work, and production evidence. |
| Current Delivery | Active Stories and Tasks by V*, status, owner, and blocker readiness. |
An equivalent existing view is preserved. Creating or materially changing one requires preview and explicit approval.
Provider Mapping
linear-free-v1 is the sole default Linear Free projection:
| Product meaning | Linear Free (linear-free-v1) |
|---|---|
| Product/Backlog Root | Native Initiative |
| Product Area | Project |
| Initiative | Issue labeled Kind/initiative |
| Epic | Child Issue labeled Kind/epic |
| Story | Child Issue labeled Kind/story |
| Task | Child Issue labeled Kind/task |
| Blocker | Native blockedBy / blocks relation |
| Fog | Lateral Issue with reciprocal provenance links |
The Linear Free writer never creates nested Initiatives or represents a semantic Initiative as a Project. It verifies the connected workspace before using provider data.
The GitHub adapter uses one Projects V2 operating surface, Issues, recursive parent/sub-issue relations, repository milestones, blocker relations, semantic fields, and accepted product-owner views. When a required representation cannot be created or read back, it returns exact setup guidance and performs zero writes.
Every Story and Task belongs to one contextual V* milestone, and a Task uses its Story's milestone. Blockers may cross Stories or Epics when the dependency is real. Before writing, the complete reachable graph rejects missing targets, future-iteration dependencies, self-edges, and cycles.
Delivery Status Truth
Delivery records only directly observed facts for exact linked work:
started ≠ blocked ≠ reviewed ≠ merged ≠ staged ≠ produced ≠ completeMerge does not prove deployment, and staging does not prove production. A Fog completes only when accepted production evidence covers its resulting delivery scope. This model defines no CI/CD trigger, pipeline adapter, release-branch workflow, sprint, Cycle, or Iteration-field behavior.
Historical staged tickets remain unchanged evidence. Compatibility reads may inspect them, but no current route depends on their former stage metadata.