Skip to main content

Scope

Use this operating model when creating, refining, delivering, releasing, or closing an AeroSim Idea, Epic, Feature, or Task. Scope Overview shows the complete current state; this page defines the ticketing system and how that state is managed.

Ticket hierarchy​

Idea → Epic → Feature → Task
  • Idea records an opportunity and remains linked to the delivery lineage created from it.
  • Epic groups required Features that deliver a product outcome.
  • Feature defines a user-visible capability and its required implementation Tasks.
  • Task is the exact unit of implementation and validation.

Status flows upward from required children:

Task → Feature → Epic → Idea

Authorization and execution eligibility flow downward. Relationships must distinguish required scope from optional or related work. Optional or explicitly excluded work does not block completion. An Idea must use one direct roll-up level; do not count an Epic and one of that Epic's descendant Features in the same required set.

Cumulative release versions​

Release scope uses a separate parent-child-grandchild hierarchy:

Release → versioned Epic → versioned Feature

The Release record is the cumulative parent. Release 1.0.0 contains its initial Epics and Features at v1. Every later Release must contain every Epic and Feature from the preceding Release.

  • An unchanged Epic or Feature keeps its prior version and is marked UNCHANGED.
  • An updated Epic or Feature increments by exactly one version and is marked UPDATED.
  • A new Epic or Feature starts at v1 and is marked NEW.
  • The first Release marks every entry INITIAL at v1.

Every UPDATED entry must record both What changed and Difference from the previous version. An unchanged entry must not claim a change explanation. If a Feature is new or updated, its owning Epic must also be NEW or UPDATED, because the Epic's cumulative scope changed.

Stable Epic and Feature IDs never change when their release version changes. Versioning does not rewrite Task history, approval gates, delivery status, evidence, or the original Release in which an item appeared. A later Release references the prior scope and adds an explicit delta; it does not duplicate canonical Epic, Feature, or Task records.

Release readers must expose this hierarchy as a progressive drill-down. A Release disclosure shows its canonical summary and nested Epics; each Epic disclosure shows its canonical summary and nested Features; selecting a Feature shows its canonical version, change type, summary, and preserved version explanation. Release and Epic controls use visible SVG chevrons, keyboard-operable buttons, complete accessible names, aria-expanded, and aria-controls targets that remain mounted while hidden. Feature selection uses aria-pressed and a mounted details region; it is not a third disclosure and does not require a chevron. The reader must retain indentation and nesting and must not flatten the hierarchy into a table or peer list.

Question placement and Idea conversion​

Every Question must name exactly one closest owning Epic through canonical epic_id. Its reader page belongs under that Epic's Questions child page, while affects_ids may also link the exact Features constrained by the answer. A Question must not appear in a global Question bucket or beneath several Epics.

When a question-shaped proposal cannot be mapped honestly to any existing Epic, capture it as an Idea rather than a Question. Preserve its original wording and source as opportunity provenance, then promote it to governed Epic or Feature scope before creating product Questions for that scope. Rephrasing an unmapped opportunity with a question mark does not make it a Question.

Each Epic retains a Questions child page even when it has no mapped Questions; the empty page makes the classification explicit and gives future Questions one deterministic location.

Clean-slate restructuring​

A clean-slate restructuring may reuse an existing canonical ID only when the governing decision explicitly names the reused identity and its exact current meaning. Reuse preserves identity allocation; it does not transfer the old title, parent, approval, solution, implementation, Task state, acceptance finding, release claim, or reader narrative.

The current AeroSim restructuring is governed by the eight-Epic portfolio and Feature decomposition, its engineering-stack refinement, and the execution-order Epic identity decision. Epic identities AEROSIM-EP-1–AEROSIM-EP-9 now map monotonically to canonical delivery order. Feature identities AEROSIM-FT-1–AEROSIM-FT-52, the ten existing Tasks, thirteen Questions, three Ideas, functional requirements FR-0001–FR-0015, and non-functional requirements NFR-0001–NFR-0006 retain their identities. The current coverage correction allocates new Proposed requirements FR-0016–FR-0059 and NFR-0007–NFR-0014; it does not present them as retained historical identities. Every parent relationship and reader route follows the execution-ordered Epic identity.

After a material redefinition:

  • Epics and Features return to an honest Proposed Scope gate and derive IN_DESIGN while their current definition is active;
  • Tasks remain exact IN_BACKLOG work records unless task-level evidence moves them; release 1.0.0 now carries exact READY_FOR_DELIVERY Architecture-readiness evidence;
  • requirements describe the current proposed product and must not retain acceptance from the retired meaning;
  • existing implementation is prototype and discovery evidence only until exact current acceptance outcomes receive new evidence;
  • reader pages, routes, indexes, Roadmap, Board, and Focus must all resolve from canonical YAML and show only the current hierarchy;
  • old scenario titles, legacy aliases, decision-history tables, and stale approval or implementation claims must not appear on current reader surfaces.

Every current Epic and Feature still explains who uses it, what the user can do, why it benefits them, its bounded scope, and observable outcomes. A later exact decision may approve a current item, but it must name that redefined item and cannot rely on an approval made for materially different semantics.

Delivery statuses​

Ideas, Epics, and Features use:

IN_BACKLOG → IN_DESIGN → READY_FOR_DELIVERY → IN_DELIVERY → TO_BE_RELEASED → DONE

Tasks use:

IN_BACKLOG → READY_FOR_DELIVERY → IN_PROGRESS → TO_BE_RELEASED → DONE

CANCELLED is an explicit exceptional terminal state. BLOCKED is a separate flag with a reason and evidence; it never replaces delivery status.

Approval gates—including Approved for Solution and Approved for Implementation—solution completeness, CI, deployment health, release evidence, and acceptance evidence remain independent dimensions. They are not delivery statuses.

Status basis​

  • Tasks show Exact item evidence and change only through verified task-level transitions.
  • Ideas, Epics, and Features normally show Required-child roll-up and are recalculated from their complete required-child set.
  • A product item without required children may use an exact decision only when its completion condition and evidence are explicit.
  • Promotion is provenance, not completion. A promoted Idea follows the delivery status of its resulting governed scope.

Deterministic roll-up​

Evaluate a parent in this order:

  1. DONE — every required child is DONE, and applicable parent-level completion evidence exists.
  2. TO_BE_RELEASED — every required child is TO_BE_RELEASED or DONE, at least one remains TO_BE_RELEASED, and the parent belongs to that release boundary.
  3. READY_FOR_DELIVERY — every required child is READY_FOR_DELIVERY; the complete governed scope is architecture-ready for pickup, while execution remains unstarted.
  4. IN_DELIVERY — at least one required descendant has entered active execution or a later nonterminal state, but the parent does not satisfy a later rule.
  5. IN_DESIGN — product definition, decomposition, solution, dependencies, or required-child structure is actively being designed and delivery has not started.
  6. IN_BACKLOG — the item is retained, but active design or delivery has not started.

Examples:

  • One Task DONE and one Task IN_BACKLOG make the Feature IN_DELIVERY, not DONE or TO_BE_RELEASED.
  • Tasks split between TO_BE_RELEASED and DONE make the Feature TO_BE_RELEASED when the Feature belongs to that release boundary.
  • Every required Feature must be DONE before its Epic can become DONE.
  • An Idea linked to two required Epics becomes DONE only when both Epics are DONE and the original opportunity is satisfied.

Task transitions​

  • IN_BACKLOG: recorded, but not yet admitted to Focus or available for implementation.
  • READY_FOR_DELIVERY: architecture, dependencies, implementation boundaries, and verification steps are complete. The Task is already admitted to Focus and available for Delivery pickup; no additional Focus-admission decision is required.
  • IN_PROGRESS: implementation or task-level validation is active.
  • TO_BE_RELEASED: implementation and validation are complete and the result awaits its release boundary.
  • DONE: the applicable completion condition is verified.

When a READY_FOR_DELIVERY Task is in the current dependency wave and Delivery has capacity, implementation must start and the claiming Delivery agent must record the transition to IN_PROGRESS. Capacity and dependency order determine when work starts; they are not a second approval gate.

A direct IN_PROGRESS → DONE transition is permitted only when the Task explicitly has no release boundary and its evidence proves the terminal outcome. Releasable AeroSim application work normally passes through TO_BE_RELEASED.

Blocking, cancellation, and dependencies​

A blocked ticket retains its delivery status:

status: IN_PROGRESS
blocked: true
blocked_reason: Waiting for verified dependency evidence

A critical blocked child may derive a parent blocked indicator. An optional or non-critical blocked child does not automatically block its parent.

Cancellation never rolls up automatically. Cancelling a parent requires an explicit disposition for every descendant: cancel, supersede, exclude from required scope, or re-parent. A cancelled child never counts as DONE and cannot be silently omitted from roll-up.

Evidence and synchronization​

Canonical YAML is authoritative. Discord supplies decisions and source evidence; reviewed documentation publishes durable state. Every status or relationship change must update, in one reviewed change:

  1. the exact canonical record and append-only event evidence;
  2. required and optional relationship indexes;
  3. Scope Overview;
  4. Roadmap, Board, and Focus views that consume the same selector;
  5. any affected approval, release, deployment, or acceptance evidence.

Validation fails on missing or duplicate tickets, dangling or one-sided relationships, invalid status/type combinations, incorrect status basis, premature parent TO_BE_RELEASED or DONE, cancelled-child aggregation, missing blocker reasons, and matrix/selector count drift.