Revisions and the Package Lifecycle

An approved package is immutable; that is what makes its approval mean something. Change happens by revision: a new draft that carries its lineage, goes through the same gate, and supersedes its predecessor on approval. The lifecycle is designed so there is never a moment where "what did we approve?" has an ambiguous answer.

The Statuses

Draft → In Review → (Changes Requested →) Approved, then onward to Superseded or Archived. Approved, superseded, and archived packages are all locked: their documents and design are the historical record.

Revise an Approved Package

Revise as New Draft creates the revision:

It gets a family design ID: ACME-0012 begets ACME-0012-R2, so lineage is visible at a glance everywhere IDs appear.
One revision may be in flight per approved package at a time; finish or abandon it before starting another.
The revision starts from the approved content and goes through the full lifecycle again: design, assurance, readiness, review. The readiness board additionally shows the boundary change versus the predecessor's approved baseline, and the scope guard governs growth along the way.

Approving the revision supersedes the predecessor: the old package remains, immutable and clearly marked, as the record of what was previously authorized; the new baseline takes over the drift watch.

The Lifecycle and the Watch

Drift detection follows the lifecycle automatically: approval starts the watch, supersession moves it to the new baseline, and a package leaving the approved state resolves its findings. The watch always points at exactly what the organization has currently authorized; no more, no less.

Revise Early, Not Around

When a change is coming, cut the revision and work it through the gate. Editing around an approved design (in wikis, in tickets, in heads) is precisely the drift the platform exists to catch.