launch-readiness-review

name

launch-readiness-review

description

Produce or audit one cross-domain launch admission verdict for an app, game, SaaS, desktop product, developer tool, marketplace, major release, beta, or campaign. Integrate exact product, quality, performance, security/privacy, payments, distribution, analytics, support, marketing, legal/authority, rollback, and post-launch evidence into go, conditional-go, hold, or no-go gates. Use when launch-day decision ownership is the artifact; use specialist skills to create missing domain evidence.

Launch Readiness Review

Produce a Launch Admission Record that makes a proportional release decision from exact evidence rather than a ceremonial checklist.

Atomic boundary

Own the final cross-domain evidence graph, blocker classification, decision, conditions, launch watch, authority, and recovery drill. Consume sibling facts by ID/version/digest; do not recreate product design, store submission, payment, marketing, security, or support artifacts.

Use the shared product artifact envelope when composing with repository product artifacts. Missing required evidence is a blocker or explicit handoff, never an invented pass. Do not require an envelope for a standalone review with no such upstream contract.

Resource guide

• Read references/launch-readiness-patterns.md for proportional domain gates, decision classes, conditional-go exceptions, and recovery authority.
• Read references/release-health-watch.md when the candidate needs a canary, staged rollout, release-health dashboard, first-week operating thresholds, or post-release closeout.

Workflow

1. Identify exact commit/build/content/config/model/policy/migration digests, launch type, audiences/age modes, channels/territories, blast radius, decision owner, change window, and irreversible harm boundaries.
2. Read the applicable references above. Select only gates applicable to the declared candidate, audience, channel, data, money, regulation, and blast radius. Record why a domain is applicable or not applicable.
3. Classify each gate pass, watch, blocked, or not-applicable-with-proof. Separate construction, proof, exposure, and external authority. Do not turn an unknown into N/A.
4. Verify exact-candidate artifacts, provenance/signatures where applicable, canary/staged rollout, data/backward compatibility, migrations/replay, feature/config kill switches, rollback/forward-fix, derived-state/cache recovery, and restoration drills.
5. Define the smallest launch watch appropriate to the risk: telemetry and countermetrics, alert ownership, exposure caps where useful, pause/withdraw, communications, and live readback. For staged or high-change releases, produce the release-health row schema, baseline/segment/sample rules, expansion/hold/rollback predicates, and closeout evidence.
6. Issue go, conditional-go, hold, or no-go. Every condition needs an owner, deadline, exact proof, and consequence; it is not a vague promise.

Source verification

Retrieve current platform/store, privacy/consent, accessibility, security, payment/refund, advertising/promotion, child/age, legal/regulated-category, regional, certification, and partner authority. External approval remains an explicit floor and may not be self-attested.

When not to use

• Use product-lifecycle-architect to build the multi-domain program graph and produce the sibling artifacts, not merely decide one launch candidate.
• Use software-distribution-readiness for channel submission, reviewer, certification, rollout, and live-store evidence.
• Use game-soft-launch-review for a multi-cohort game learning/exposure program rather than final cross-domain admission.
• Use a domain specialist when only one missing artifact is being designed or audited and the overall launch decision is not reopened.

Guardrails

• Marketing readiness never substitutes for product, authority, support, payment, migration, security, or recovery readiness.
• Do not call an open high-impact item “post-launch” without a bounded exposure, explicit risk acceptance authority, expiry, countermetric, and automatic stop.
• No launch of paid, personal-data, child, destructive, migration, or irreversible flows without authoritative state, support, compensation, and recovery.
• A green workflow exit is not live proof. Verify deployed/released identity and user-visible or telemetry readback.
• Do not add unrelated gates merely for checklist completeness; proportionality must never erase a requirement that is actually applicable.

Output contract

Return one typed Launch Admission Record with:

1. exact candidate/authority identities, scope, audiences/channels, decision owner, change window, and ruin boundaries;
2. dependency/evidence graph and pass/watch/blocked/N-A gate matrix;
3. blocker records with owner, exact proof, deadline, and automatic consequence;
4. canary/staged exposure, migration, rollback/forward-fix, cache/derived-state, and restoration drill evidence;
5. proportionate launch watch, including any release-health dashboard rows, baseline/segment/sample rules, pause/withdraw, communication, and live-readback plan;
6. go | conditional-go | hold | no-go verdict with machine-readable reasons;
7. post-release live-readback and closeout evidence.

State unresolved external authority and manual decisions explicitly. Do not call the launch complete until the exact released candidate has live readback.