22 — Release and Launch Readiness Checklist#

Verify that a new product, service, or significant change is ready for controlled customer exposure, has an explicit go/no-go decision, and can be operated and supported safely after launch. This release-level checklist consolidates sign-offs from deeper reviews rather than duplicating all of their technical tests.

Scope: AI-specific. This file is one part of the 22_Release_and_LaunchReadiness.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.

Review details#

• Project / product:
• Release / version / environment:
• Scope and applicable jurisdictions / markets:
• Launch type / planned window / time zone:
• Source revision / build artifact / change reference:
• Launch owner / approver / on-call contacts:
• Reviewer / owner:
• Review date:
• Decision: Pending / Approved / Approved with documented exceptions / Blocked

How to use#

1. Copy this reusable checklist into project-specific release records; keep the shared template unchecked.
2. Mark [x] only when a check is verified by a current release plan, required domain sign-off, production smoke test, observable metric, deployment evidence, or accountable decision. Document failures, accepted exceptions, and genuine N/A reasons in project notes or an issue tracker keyed by LAUNCH ID.
3. Tailor the checklist to the release scope, customer impact, infrastructure, and jurisdiction. Do not assume every application requires canaries, payment checks, app-store distribution, or public indexing.
4. Complete ## API Checks and ## Frontend Checks separately where the corresponding interface exists. For inapplicable items, document why in project-specific records.
5. Keep the go/no-go decision independent of having ticked all template items: unresolved material risks need authorized acceptance. Coordinate with Testing, Legal, Security, Accessibility, DevOps, Performance, Reliability, Monitoring, and Data checklists.
6. Re-run appropriate checks when the release candidate, deployment window, dependencies, target audience, or known risk materially changes.

Launch scope and ownership#

• LAUNCH-002 Define the user and business outcomes required from the launch, including measurable success and guardrail metrics.

Release gate#

• The release scope, exact artifact, target environment, deployment window, and accountable go/no-go owner are documented and agreed.
• Required technical, operational, security, privacy, accessibility, and business reviews are complete, with no unaccepted release-blocking findings.
• Production dependencies, migration prerequisites, secrets and access, capacity, monitoring, on-call coverage, and customer-support handoffs are ready for the intended launch.
• The rollout procedure has clear steps, audience/exposure controls, health thresholds, stop conditions, and safe recovery options, including treatment of irreversible changes.
• Critical API and frontend journeys are verified in production or an explicitly approved equivalent, with defined follow-up checks after live exposure.
• Stakeholder/customer communication plans, documentation, known limitations, and escalation channels are approved where applicable.
• A designated approver has recorded Go, Go with authorized time-bound exceptions, or No-go against the exact release and its residual risks.
• Post-launch observation, stabilization ownership, completion criteria, and remediation tracking are agreed before the release is declared finished.

Domain-specific approval rule: Block launch when essential user journeys are unverified, required sign-offs are missing, critical dependencies or support coverage are unready, the actual deployed artifact is unknown, or material deployment/recovery risks are unaccepted. A launch approval does not supersede legally required approvals or prove that all risks have been eliminated.

Trusted references and scope#

The following primary sources informed these practical verification questions. Their detailed methods are adaptable rather than mandatory for every organization, and the links are not a claim of any formal launch certification.

• Google SRE — Reliable Product Launches — launch checklists, dependency review, capacity, operations, and coordinated readiness.
• Google SRE — Launch Coordination Checklist — release-day architecture, load, dependencies, reliability, and verification questions.
• AWS Well-Architected — Operational readiness and change management — consistent prelaunch reviews, personnel, runbooks, change decisions, and support planning.
• AWS Well-Architected — Operational Readiness Reviews — tailored readiness checklists, escalation, event handling, and release quality.
• AWS Well-Architected — Plan for unsuccessful changes — recovery, rollback, feature-disablement, and response to failed releases.
• AWS Well-Architected — Mitigate deployment risks — deployment testing, phased exposure, feedback, and rollback.
• Microsoft Azure Well-Architected — Operational Excellence checklist — ownership, operations, monitoring, incident response, and safe deployment criteria.
• Microsoft Azure Well-Architected — Safe deployment practices — progressive exposure, health gates, emergency changes, and rollback planning.
• Google Cloud — Operational readiness and performance — readiness across workforce, processes, tools, governance, and service support.
• GitHub Docs — Deployments and environments — protected deployment environments and approval mechanisms, when GitHub Actions is used.
• OpenAPI Specification — versioned API contracts and interface documentation, when applicable.
• Chrome for Developers — Service worker deployment — caching and compatibility considerations for service-worker-enabled web apps.

Applicability: The depth of review, number of approvals, exposure strategy, and stabilization period depend on customer impact, release type, team size, and applicable obligations. GitHub Actions protections and Workbox service-worker guidance are relevant only when those technologies are used. Reassess the launch plan after any substantial change to the candidate or target environment.

Source review date: 2026-11-12.

Suggested testing tools#

Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.

• Test focus: release smoke suites, security gates, rollback, and post-deploy verification; include model and dataset behaviors where applicable.
• Cross-stack: actionlint + Trivy + Playwright.
• Python: pytest; for pytest-based suites, run python -m pytest -q.
• TypeScript: Playwright + Vitest; for Vitest-based suites, run npx vitest run (or npx playwright test for E2E).
• JavaScript: Playwright + Jest; for Jest-based suites, run npx jest --ci (or npx playwright test for E2E).
• Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.

Suggested AI skills for verification#

These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.

• shipping-and-launch — Review preflight and launch readiness (addyosmani/agent-skills, 116,378 repo stars).
• verification-before-completion — Require test evidence before a release decision (obra/superpowers, 316,578 repo stars).
• github-release — Check GitHub release steps where used (github/awesome-copilot, 41,073 repo stars).

How to check: In a project-specific copy, have the agent audit the AI-specific scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.

Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.

Important warning: reference only#

⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.

Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.