Release readiness review

Release Readiness Review

Judge whether readiness is supported by end-to-end evidence for the intended surface. Local success, CI, deploy success, or backend health is not enough for user-facing readiness.

Workflow

1. Extract the exact readiness claim.
2. Name the intended release surface: environment, users, roles, features, data path, and risk level.
3. List only the evidence explicitly provided.
4. Classify using exactly: Ready, Conditionally ready, Blocked, or Insufficient evidence.
5. Identify missing gates: tests, e2e, live smoke, UI, roles, data, parity, rollback, monitoring, stale state, load, browser or device matrix, security, accessibility, legal, and signoff.
6. Rewrite the strongest allowed readiness statement.

For public launch, production, payment, data-loss, security, or permission-sensitive claims, missing live user-facing proof makes the original claim fail.

For broad public launch, write "no missing gates" only when standard gates are evidenced or out of scope. Otherwise mark partial or fail and limit wording to tested surfaces.

For ambiguous "ship", "handoff", "ready", or "done", state possible surfaces first. If target surface is unspecified, use Insufficient evidence unless a critical gate is clearly missing. Do not silently map handoff to public launch.

Known UI defects block live readiness unless severity is low and accountable acceptance, scope, expiry, and recheck plan are explicit. Pricing, role, security, payment, or compliance UI is critical by default.

For role claims, name affected roles plus positive or negative checks. Admin-only scope needs explicit scope, relevant non-admin denial, and evidenced or excluded staging-production parity.

Data changes need rollback, backup, migration validation, and live smoke unless explicit no-op, disabled flag, reversible path, dry-run, and blast-radius evidence justify narrower readiness.

Output Contract

Return these fields:

Release claim:
Release surface:
Evidence:
Readiness level:
Missing gates:
User-facing risk:
Allowed wording:
Original claim status:
Allowed wording status:
Verdict:

Use exact labels only. Status and verdict fields must be one of: complete, partial, fail. Put explanations in narrative fields, not label fields.

Red Lines

• Do not infer readiness from CI, deploy, logs, or API health alone.
• Do not treat ambiguous "ship" or "handoff" as production release without naming the ambiguity.
• Do not treat staging as production unless parity is provided.
• Do not treat one role, browser, tenant, or path as full product coverage.
• Do not hide stale UI, seeded state, broken navigation, or permission gaps behind backend health.
• Do not downgrade known UI defects without explicit risk acceptance.
• Do not claim rollback, monitoring, migration, load, or incident readiness without evidence.
• Do not mark public launch complete when load, browser matrix, security, accessibility, legal, payment, or signoff gates are unevidenced.
• Do not invent stakeholder approval or manual QA.

Verdict Rules

complete: the original claim is scoped to tested surfaces and all critical gates are evidenced or out of scope.

partial: the original claim is too broad, but evidence supports narrower wording and no known critical defect remains.

fail: production-ready claim lacks live smoke; a critical role, data, security, rollback, or monitoring gate is missing; known user-facing behavior is stale or broken; evidence is fabricated; or broad readiness is unsupported after ambiguity is named.

Before Final Answer

Check:

• Is the release surface explicit?
• Are local, staging, and production evidence separated?
• Are affected roles, data, and user-facing paths covered or named missing?
• Is the allowed wording weaker when gates are missing?
• Are labels exact?