Release Management

A release is a set of work packages that ship together. It is planned in the lifecycle’s own units — packages whose Definition of Done has passed, grouped by intent, release phase and workstream — approved on two keys, and says which key results it expects to move.

What can go on a release

A work package can join a release when it is completed — its Definition of Done passed for the package as it now stands — and its pull request is merged, or, before the merge, its merge hold says success on the head it was set on. The Candidates list shows every package in delivery or completed, intent by intent, phase by phase and workstream by workstream, marked ready or not with the reason.

Planning a release

On the Release plan, choose New release, give it a title and version, pick the packages, and save the draft. The release gets a reference such as REL-3. Only owners and studio admins plan and approve releases; everyone in the studio can see them.

Expected signals

Each release names the key results it should move: the key result, the direction (up or down), an optional baseline and target, a horizon of 1 to 365 days (30 by default), and the telemetry connector whose readings measure it. The Feedback Loop checks each one at +7 days and at its horizon. Without a connector there is nothing to read, and the Feedback Loop says so.

Two keys, then release

Approve release re-checks every package on the server — the readiness key — and records you as the approver — the human key. A release with AI-generated changes also needs a DPIA that a studio owner or reviewer has approved; the release keeps a copy of the DPIA as it stood, and that DPIA cannot be deleted or taken out of approved while the release relies on it. Once approved, the release’s content, including its expected signals, is frozen. Mark released needs every pull request on it merged, at the head that was approved: if a pull request changed after approval, Reopen the release with a reason and approve it again. A released release can be rolled back, with a reason; its record stays.

Rules from your organisation

Where the work packages on a release were created under an organisation’s guardrail policy, the policy’s release rules apply at approval and again at release — the strictest among the versions those packages carry. A policy can require CI to have passed at every package’s head, read from GitHub at that moment: a failed check, an unfinished one, no checks at all or a result that could not be read all refuse. And it can name organisation reviewer roles the approver must hold, through your studio’s mapping on Human Roles. The DPIA rule above applies whatever the policy says.

A work package whose exception has expired cannot go on a release, or be released on one, until the exception is renewed or its item is met.

The release passport

Once a release is approved, Show the passport reads its evidence record: the readiness check, who approved it, the DPIA it relied on, comms approvals, any rollback, and — for each work package — its approved head, the CI recorded at that head, its exceptions and its controls.

Approving the release also issues a signed passport: that record frozen and signed, for an auditor or a pipeline to verify with the published public key. Reopening and approving again issues the next version. If signing did not complete, the approval stands and the page offers to issue one. Where a pipeline reports them, the release also lists its deployments. See Artefact Passport & Evidence Ledger.

Earlier release packs

Release packs assembled from agent runs, before releases were planned in work packages, are kept read-only on the page.