Make a release decision with evidence

State the decision precisely

A green pipeline is evidence from a set of checks. It is not a complete description of the release decision. The owner needs to know what will change, where it will change, and what consequences remain.

For a fictional customer export, identify the accepted commit and the artifact produced from it. Name the target environment. Link the relevant tests, review, and any approved exception. Include the data or infrastructure changes that accompany the application.

NIST’s SSDF provides secure development practices, while SLSA provenance helps describe how an artifact was produced. Neither removes the need to decide whether this release is appropriate for this service. NIST SSDF, SLSA provenance.

Separate three events

Merge places a source change into a branch. Deployment places an artifact into an environment. Feature exposure makes behavior available to users. These events can coincide, but they are not necessarily the same event.

A service can deploy an inactive feature and expose it later. A database migration can affect production before a visible feature appears. Define the actual sequence rather than assuming that a PR merge describes every consequence.

For the export, a feature flag may limit initial exposure. It does not automatically protect a new endpoint or reverse a schema migration. Verify the control at the point where the consequence occurs.

Review a compact evidence record

Use a record that another responsible person can inspect:

• Purpose and affected users.
• Commit and artifact identity.
• Relevant behavior, security, and compatibility checks.
• Target environment and execution identity.
• Remaining exceptions with owners and expiry conditions.
• Monitoring, recovery method, and response owner.

Keep claims specific. “Tests passed” is weaker than a link to results for the release commit with a clear coverage description. “Rollback available” is weaker than a tested procedure with stated limits.

Decide how to stop

Define release conditions before execution. For the fictional export, stop if cross-organization access succeeds, if the artifact differs from the accepted digest, or if recovery is unavailable. These are illustrative conditions, not a universal checklist.

After deployment, inspect the signals that matter to users. Compare error behavior and response times with the service’s accepted targets. A healthy process does not prove that the user workflow works.

If a condition fails, use the agreed response. This can mean disabling exposure, rolling back compatible code, or recovering data. Choose the action that addresses the failure without creating a larger one.

Preserve the decision after release

Record the actual deployed artifact and outcome. If execution differs from the plan, make the difference visible. Feed incidents and unexpected work into the next release design.

An automated delivery system should make this record easier to inspect. It should not require a reviewer to reconstruct the release from disconnected chats, logs, and screenshots. Clear evidence lets teams automate routine work while retaining accountable decisions.