checklist
What Evidence Proves a Change Is Safe to Release?
'Safe to release' is not a feeling after green CI; it is four pieces of evidence that exist and connect: focused tests for the changed path that were capable of failing, review findings raised and resolved on the record, a build result tied to the exact artifact you intend to ship, and a written recovery path if the change misbehaves. Anything less is confidence wearing evidence's clothes. BuildDocket keeps these four together per change and refuses to mark any of them green without the recorded proof. Code changes require repository review and testing. Production deployment remains a separate authorized action. You can open these pages and sign in to the workspace today. That does not mean your repositories are connected, and it does not mean the product has formally launched.
Why green pipelines lie
A full-suite pass proves the suite passes — not that today's change is covered by it. Changes ship with bugs their tests never approached because coverage of the new path simply did not exist, and the green checkmark said nothing either way. The unit of evidence that matters is narrower: tests aimed at this change, demonstrably able to fail (break the code, watch them go red), passing now.
The subtler gap is provenance drift. The build that passed at 2pm and the artifact deployed at 4pm are frequently different builds — rebuilt between times, maybe with different inputs. Until a build result is tied to the specific artifact shipping, the pipeline's blessing applies to a stranger. Release safety is chain-of-custody, and most teams cannot produce the chain when asked.
What to bring
Bring the change's docket or equivalent record: specification, branch, and the focused test commands for each touched module.
Bring skepticism about your own suite: which of these tests have you seen fail? A test that has never failed is indistinguishable from a test that cannot.
Step 1: Prove the tests can fail
For each focused test covering the change, break the underlying code deliberately and watch it go red, then restore. This mutation check takes minutes and converts assumed coverage into demonstrated coverage.
Step 2: Resolve review findings on the record
Every reviewer concern gets one of two endings: fixed, or explicitly declined with reasoning. Silent non-resolution is how known risks board the release train. Code changes require repository review and testing. Both words do real work.
Step 3: Bind the build to the artifact
Record the build result alongside its artifact identifier, and verify the thing you intend to deploy is that artifact — not a rebuild, not a sibling. BuildDocket keeps this pairing explicit so the question 'was this exact thing tested?' has a yes.
Step 4: Write the rollback before you need it
Recovery notes written during calm name the exact revert command or flag flip and who executes it. Notes improvised during an incident are hope with a timestamp.
Step 5: Separate deployment authorization from readiness
All four artifacts ready means the change is eligible to ship. Production deployment remains a separate authorized action. That is a distinct decision, recorded as such, by whoever owns that gate. Conflating readiness with permission is how unauthorized releases happen inside polite processes.
Verification
Audit your last five releases against the four-evidence standard: mutation-checked tests, resolved-on-record reviews, artifact-bound builds, written rollbacks. Most teams find zero of five complete. Then fix the next release, not the process document — one release done right teaches the standard better than any policy page.
Limits that stay with you
Evidence raises confidence; nothing abolishes risk. Tests cover what they cover, review catches what reviewers catch, and production retains its capacity to surprise. Code changes require repository review and testing. The requirement holds regardless of how good the automation looks.
The checklist also governs eligibility only. Production deployment remains a separate authorized action. No density of evidence substitutes for the human who owns that call.
What BuildDocket does in this workflow
BuildDocket holds the four evidence types together per change and enforces their honesty: test results appear as recorded, including failures; review findings stay open until resolved on the record; build results bind to artifact identifiers; rollback notes live beside the change they recover. Ask 'is this safe to ship?' and receive the evidence inventory, gaps included.
It will not declare readiness from partial evidence, and it will not confuse eligibility with authorization. The discipline is the difference between a release process and a release ritual.
FAQ
Questions this guide is for
Isn't CI already my release evidence?
CI proves the pipeline ran. The four-evidence standard asks narrower questions — can these tests fail, was this exact artifact built — that generic green checks never address.
Who performs the production deployment?
Whoever is authorized — outside this workspace. Production deployment remains a separate authorized action, and the docket records that boundary instead of eroding it.
Does this work without connecting our repos?
You bring the specs, branches, and results you want bound. That does not mean your repositories are connected, and it does not mean the product has formally launched.
Start in the workspace
Demand real evidence
Sign in, put your next change on a docket, and hold it to the four-evidence standard before it ships.