Skip to content
steelabs

Checklist

Release evidence checklist

A compact record of the build, critical journeys, unresolved defects, operational checks and release owner. Make unknowns visible before deciding to ship.

Download editable Markdown

How to use this

Useful for: Product owners and delivery teams preparing a web or API release.

  1. Open one copy for a specific release candidate. Record the commit or build identifier and the environment so the evidence cannot accidentally describe an earlier version.

  2. For each critical journey, link the test result and name its reviewer. A green pipeline with no agreed coverage is insufficient evidence for an untested business workflow.

  3. Review unresolved findings with the decision owner. Record an accepted risk with its impact, expiry and follow-up owner rather than quietly converting a failed check into a pass.

  4. Revisit the checklist after a deployment change or a new build. Close the release with monitoring observations and keep the rollback reference accessible to the person on call.

Scope and limitations: This checklist supports a release discussion. It does not establish legal compliance, replace specialist security testing or certify that the product is safe to release.

Document preview

# Release evidence checklist

## Release identity
- Product / release:
- Candidate build or commit:
- Environment and configuration:
- Scope of change and excluded areas:
- Decision owner / planned release time:

## Evidence to review
- [ ] Critical user journeys listed with business impact and test results.
- [ ] API contracts and failure paths checked against the agreed requirements.
- [ ] Access checks include cross-account and privileged operations.
- [ ] Keyboard, focus and relevant mobile journeys reviewed.
- [ ] Data migration or configuration changes rehearsed where applicable.
- [ ] Automated failures investigated; quarantined tests have owners and expiry dates.
- [ ] AI-assisted changes independently reviewed; generated output is not its own test oracle.
- [ ] Sensitive information removed from screenshots, logs and attachments.

For each item record: status / evidence link / build / reviewer / remaining uncertainty.

## Known issues and exceptions
| Finding | User impact | Evidence | Mitigation | Owner | Review date |
| --- | --- | --- | --- | --- | --- |
| Replace with observed finding | | | | | |

## Operation and recovery
- [ ] Deployment procedure and permissions confirmed.
- [ ] Rollback or forward recovery rehearsed with a named operator.
- [ ] Monitoring signals, alert recipients and observation period agreed.
- [ ] Support or incident contacts know the release window.

## Recorded decision
- Decision: release / hold / release with accepted limitations
- Reason and evidence supporting it:
- Accepted risks, approving owner and review date:
- Follow-up actions and deadlines:
- Post-release observations:

An unchecked item is an open question, not an implied pass. This document records a team decision; it is not a certification.

Read alongside this worksheet

Get help applying itAll resources