Release Candidate & Gate Evidence Matrix
Connects every material gate to its failure mode, applicability rationale, requirement, evidence, status, owner, blocker and bounded exception.
Release Readiness Decision Ledger
Release Checklist Builder
Build a candidate-specific readiness ledger with applicable gates, evidence, blockers, rollout/recovery criteria and an explicit GO or HOLD decision. The goal is not to finish the longest checklist; it is to make the release decision inspectable.
Candidate
Name the exact build, environment or artifact being reviewed.
Applicable gates
Let the actual change and risk surface determine which failure modes matter.
Evidence
Record what each proof item demonstrates, its result and candidate context.
Decision
See HOLD, GO WITH BOUNDED EXCEPTION or GO without claiming universal safety.
No login. Autosaves in this browser's local storage. Share URLs can contain internal release details; review them before sharing.
Current ledger state
HOLD
Core candidate/scope readiness is incomplete and cannot be waived inside this tool.
Candidate: Candidate/environment not fully identified
Open gate issues: 13
Bounded exceptions: 0
1. Candidate & change surface
Evidence only has meaning against the candidate that will actually ship.
2. Release risk surface
These inputs drive gate applicability. They are not converted into an authoritative numerical risk score.
3. Rollout & recovery contract
Rollout stages
No stages defined yet. A canary/gradual label is not a rollout plan by itself.
Recovery strategy
Rollback is only one option. Disable, forward-fix, restore/replay, fail over or contain when those reflect the real system.
4. Post-release verification contract
GO is not the end of the workflow.
5. Blockers & bounded exceptions
Accepted risk is attached to exact gates. One exception never clears another blocker.
Open blockers
No explicit blockers recorded.
Bounded exceptions / accepted risk
No bounded exceptions recorded.
6. Human decision record
CraftUp derives HOLD from the ledger. Your team may record its human decision, but contradictions stay visible.
Stakeholder summary
Release readiness Decision: HOLD Candidate: Candidate/environment not fully identified Ships: -, Open blockers: - Release candidate identified: Target environment plus candidate/build/artifact reference is missing. - Change scope confirmed: What ships and impacted surfaces are not both defined. - Critical journeys verified: At least one gate-linked task is not Done. - Critical journeys verified: Decision-relevant evidence is missing; a URL by itself is not proof. - Data / migration readiness: Data-migration impact has not been assessed. - Payment / money path verified: Payments/money impact has not been assessed. - Security / privacy review: Security/privacy applicability is not fully assessed. - Health signals ready: Operational risk surface has not been fully assessed. - Advance / hold / recover conditions defined: At least one gate-linked task is not Done. - Recovery strategy ready: Operational risk surface has not been fully assessed. - Support readiness: User-visible impact has not been assessed. - Release communication decision: User-visible impact has not been assessed. Bounded exceptions: - none Rollout: gradual · 0 stages Owners: - Next check: -
Readiness checks
- FAIL · Release candidate or target environment is not fully identified. Record the environment and at least one build/version/artifact reference.
- FAIL · What ships and impacted surfaces are not both defined. Record explicit shipped scope and affected surfaces; do not infer scope from checklist task titles.
- FAIL · Release candidate identified: Target environment plus candidate/build/artifact reference is missing. Complete the gate condition and add evidence describing what it demonstrates for the current candidate.
- FAIL · Change scope confirmed: What ships and impacted surfaces are not both defined. Complete the gate condition and add evidence describing what it demonstrates for the current candidate.
- FAIL · Critical journeys verified: At least one gate-linked task is not Done. Complete the gate condition and add evidence describing what it demonstrates for the current candidate.
- FAIL · Critical journeys verified: Decision-relevant evidence is missing; a URL by itself is not proof. Complete the gate condition and add evidence describing what it demonstrates for the current candidate.
- FAIL · Data / migration readiness: applicability is unknown. Assess the relevant change surface or record an explicit applicability decision.
- FAIL · Payment / money path verified: applicability is unknown. Assess the relevant change surface or record an explicit applicability decision.
- FAIL · Security / privacy review: applicability is unknown. Assess the relevant change surface or record an explicit applicability decision.
- FAIL · Health signals ready: applicability is unknown. Assess the relevant change surface or record an explicit applicability decision.
- FAIL · Advance / hold / recover conditions defined: At least one gate-linked task is not Done. Complete the gate condition and add evidence describing what it demonstrates for the current candidate.
- FAIL · Recovery strategy ready: applicability is unknown. Assess the relevant change surface or record an explicit applicability decision.
- FAIL · Support readiness: applicability is unknown. Assess the relevant change surface or record an explicit applicability decision.
- FAIL · Release communication decision: applicability is unknown. Assess the relevant change surface or record an explicit applicability decision.
- FAIL · Infrastructure / config change readiness: applicability is unknown. Assess the relevant change surface or record an explicit applicability decision.
- FAIL · Post-release verification ready: At least one gate-linked task is not Done. Complete the gate condition and add evidence describing what it demonstrates for the current candidate.
Export & share
No login. This workspace autosaves in this browser's local storage. Local storage is not encryption.
Share privacy: The share URL contains the release workspace, including internal release details and evidence references. Anyone with the URL can inspect them. Remove sensitive details or use an export instead when appropriate.
Synthetic examples
Synthetic demonstration, release details, evidence, metrics, owners and references are fictional.
Workflow
Candidate → gates → evidence → decision
- 01
Identify the exact candidate, environment, shipped scope and impacted surfaces. Then assess the change/risk surface instead of accepting a template as policy.
- 02
Review the Release Candidate & Gate Evidence Matrix. Decide applicability, complete gate-linked tasks, and record evidence that says what it demonstrates, its result and which candidate it applies to.
- 03
Resolve blockers, define rollout/recovery and post-release verification, then inspect the derived HOLD / GO WITH BOUNDED EXCEPTION / GO state before recording the human decision.
Why this tool is different
A checklist becomes useful when each gate maps to a real failure mode
Generic release checklists can tell you to test, monitor, communicate and roll back. This tool adds the decision trace: why a gate applies to this candidate, what evidence supports it, what remains unresolved, which bounded risk was explicitly accepted, and what should happen during and after rollout.
Release Readiness Decision Ledger
Keeps candidate, shipped scope, risk drivers, gate matrix, blockers, exceptions, rollout/recovery contract, human decision and post-release verification in one reusable artifact.
Common high-consequence gates, and when they apply
Recovery
Applies when a failed release needs containment or recovery. That can mean rollback, disable/kill switch, forward fix, restore/replay, failover or containment, not always literal rollback.
Health signals
Applies when release health cannot be inferred safely without active signals. A dashboard URL alone is insufficient; the team needs signal meaning, baseline/failure context, watcher and action.
Communication
Applies when affected people need advance or actionable information. The right choice may be external, targeted, internal-only or no proactive communication, with rationale.
Support readiness
Applies when user-facing behavior, known issues or escalation risk make support involvement plausible. Low-impact internal changes do not need a giant support plan.
Security / privacy
Applies when auth, permissions, sensitive data or external data sharing changes. CraftUp surfaces unresolved review; it does not certify a release as secure or compliant.
Post-release verification
Applies to the release decision lifecycle because deploy success is not proof of user/system health. Define first check, signals, recover trigger and follow-up decision.
Release readiness is narrower than launch planning
This tool owns
Whether one specific software/product candidate is operationally ready to begin or continue release, based on its actual risk surface, evidence, blockers, controls and recovery path.
Product Launch Plan owns
Audience, GTM coordination, enablement, launch communication, broader launch sequencing and post-launch coordination. One launch can contain several releases.
Changelog Generator owns
The finished user-facing or internal release communication artifact. This ledger hands off confirmed change facts; it does not turn task titles into release notes.
Practical release-readiness rules
- Identify the exact candidate and environment before treating evidence as release evidence.
- Use templates as starting configurations; let the actual change surface decide which gates apply.
- A link is a reference, not proof. Record what the evidence demonstrates, its result, candidate and environment.
- Rename tasks freely. Semantic gate identity is stable and does not depend on human-readable wording.
- For staged rollouts, predefine what makes you advance, hold or recover instead of deciding under pressure.
- Use recovery rather than assuming literal rollback is always possible; disable, forward-fix, restore or contain when appropriate.
- Attach risk acceptance to the exact unresolved gate. One bounded exception never clears an unrelated blocker.
- Keep GO as a human decision informed by the ledger. CraftUp reports current evidence; it does not certify production safety.
Common failure modes in release checklists
A long checklist looks complete but irrelevant items dominate.
Cause: Row count is being treated as readiness.
Fix: Cover applicable failure modes and remove filler; explicit N/A with rationale is valid.
Renaming a task changes policy behavior.
Cause: Policy is coupled to display strings.
Fix: Bind tasks to stable semantic gate keys and evaluate the gate independently of title.
A critical task is Done but readiness still lacks proof.
Cause: Task status and evidence were collapsed into one signal.
Fix: Record what evidence demonstrates for the current candidate and its result.
High risk is selected but the same standard gates remain.
Cause: Risk tier is decorative.
Fix: Use risk/change-surface inputs to activate recovery, monitoring and stop-condition gates.
One override turns several blockers green.
Cause: Risk acceptance is global instead of bounded.
Fix: Create a separate accepted-risk record tied to the exact gate/blocker, authority, review time and next action.
A dashboard URL is treated as monitoring readiness.
Cause: The signal and decision response are undefined.
Fix: Record what is watched, baseline/failure context, watcher and the action the signal triggers.
Release notes inherit B2B audience or content type from risk.
Cause: Communication facts are being inferred from operational readiness fields.
Fix: Hand off explicit audience, change, benefit, action and version facts only.
GO ends the workflow.
Cause: Post-release verification is modeled as a named task instead of a contract.
Fix: Define first check, signals, critical flows, recover trigger and follow-up decision.
Release Checklist Builder FAQ
What is the Release Readiness Decision Ledger?
It is a candidate-specific record of what is shipping, which readiness gates apply, what evidence supports them, which blockers or bounded exceptions remain, how rollout/recovery will work, and which GO/HOLD decision the current record supports. It is not a universal certification that production is safe.
Why are there fewer than 40 default tasks?
Because checklist length is not a quality signal. The builder starts from failure-mode-based semantic gates and editable implementation tasks. A small reversible copy change can require far fewer gates than a payment migration, while still being more rigorous because every applicable risk is explicit.
What is the difference between a gate and a task?
A gate is a stable readiness condition such as recovery or candidate verification. A task is an editable way to implement that condition. You can rename, duplicate or reorganize tasks without changing policy. Deleting the only task for an applicable gate leaves that gate unresolved rather than silently disabling it.
Does Done mean a critical gate is ready?
Not necessarily. Evidence-required gates also need decision-relevant evidence that says what was checked, the result, and which candidate/environment it applies to. A URL alone does not become a Pass. Rejected sign-offs, failed evidence, wrong-candidate evidence and open blockers remain visible.
How do bounded exceptions work?
An exception attaches to specific gates or blockers and records the reason, known consequence, mitigation, accepting authority, review time and next action. It never clears unrelated blockers. If every remaining unresolved issue has a complete bounded exception, the ledger shows GO WITH BOUNDED EXCEPTION rather than ordinary GO.
Do all releases need rollback, monitoring, comms and support plans?
No. These are common high-consequence gates whose applicability depends on the actual change. Recovery matters when failure needs containment; monitoring matters when health cannot otherwise be inferred safely; communication matters when people need actionable information; support readiness matters when escalation is plausible.
How is a canary or gradual rollout represented?
The rollout contract records stages or cohorts, intended exposure, observation context, health signals, advance condition, hold condition, recovery condition and owner. The word canary by itself is not treated as a rollout plan. All-at-once is also valid when its risk context and rationale are explicit.
Where is release data stored and what happens when I share it?
No login is required. The workspace autosaves in this browser's local storage. A share URL embeds the workspace snapshot; anyone with that URL can inspect its internal release details and evidence references. Large workspaces fail safely and should be exported instead. Local storage and URL compression are not encryption.
Continue the workflow
Freshness & change history
Last updated: 2026-09-18
- 2026-09-18: Rebuilt the tool around a candidate-specific Release Readiness Decision Ledger and semantic gate matrix.
- 2026-09-18: Removed artificial 40-item padding, title-string policy checks, global override and the N/A ratio heuristic.
- 2026-09-18: Added structured evidence, risk-driven applicability, recovery/rollout/post-release contracts, blockers and bounded exceptions.
- 2026-09-18: Added v2 storage/share migration, privacy warning, share-size guard and candidate-safe changelog handoff.