Skip to main content

Understand the product lifecycle

AeroSim separates product, solution, implementation, and release authority so evidence from one stage cannot silently authorize another.

Lifecycle boundaries​

  1. Scope proposes and refines Epics and Features.
  2. A trusted human or the delegated AeroSim project lead may mark an exact Epic or Feature Approved for Solution with durable decision evidence.
  3. Architecture derives measurable requirements, decisions, risks, tasks, and a version proposal only for an approved Feature.
  4. A trusted human or the delegated AeroSim project lead separately grants Approved for Implementation and finalizes version allocation through exact-item decisions.
  5. Delivery implements admitted Architecture-owned tasks, publishes immutable images, and uses GitOps CD only for the development environment.
  6. UAT executes versioned end-to-end journeys against the exact development deployment and produces a separate UAT_PASSED, UAT_FAILED, or BLOCKED verdict.
  7. Releases requires both a verified UAT pass and an explicit release request before production promotion; it independently verifies production and records final DONE.

Silence, progress output, question closure, CI success, documentation activity, or Kanban movement does not substitute for an explicit decision by a trusted human or the delegated AeroSim project lead.

Durable sources​

Structured state lives in the local YAML database and is validated during every documentation build. Discord supplies discussion and source evidence; durable lifecycle state is published through reviewed documentation.