Readiness

Release readiness

Judge the proposed use and consequence, not the polish of the preview. This is a scoped readiness review, not a security certification or authorization to launch.

Work

• Identify the artifact, intended audience, data sensitivity, exposure, and claimed readiness. Recover intent from the brief, code, or user context; missing documentation does not prevent inspecting obvious risks.
• Verify the primary task and its critical failure paths. Distinguish real behavior, mocks, and unverified integration.
• Assess data persistence and recovery, server authorization and tenant isolation, input validation, secrets, async writes, accessibility, deployment, observability, and rollback as applicable.
• Use pass, fail, unverified, or not applicable with reasons and evidence. Do not average away a blocker or mark authentication as proof of authorization.
• Name must-fix items for the intended use. A real-data pilot still requires access enforcement and a data recovery decision.
• Record accepted risk only when an actual authorized person accepted it. Otherwise label it a proposed deferral with owner and revisit condition to resolve.

Deliver

Lead with the supported use or blocking conclusion. Follow with area → evidence/status → impact → required action, then checks performed and unknowns. Keep the review focused on the existing product promise.

## Readiness review

**Artifact:**
**Stated use:** demo | pilot | production
**Supported use:**
**Promise still true?** yes / no — [one line]

### Score
| Area | Demo | Pilot | Production | Notes |
|---|---|---|---|---|
| Data & persistence |  |  |  |  |
| Auth & permissions |  |  |  |  |
| Gap states |  |  |  |  |
| Security (UI-owned) |  |  |  |  |
| Tests & preview |  |  |  |  |
| Observability & rollback |  |  |  |  |

### Must fix before treating this as [level]
- [item]

### Accept explicitly
- [risk] — accepted by [who] — revisit when [signal]

### Next artifact

Do not publish, message stakeholders, alter permissions, or claim compliance as a side effect of review. Use $states for targeted recovery work and $craft when visible quality also needs evaluation.

Worked example

Readiness review

Artifact: https://preview.example.com/dashboard Stated use: production (client asked to "just launch") Supported use: pilot Promise still true? Partially — primary job works; billing and invites are stubs

Score

Must fix before treating this as pilot

• Enforce server-side permission on delete and admin routes; hidden UI is not enforcement
• Add empty and error states to the project list with retry that preserves input
• Name the use to the client: pilot, not launch

Accept explicitly

• EN-only — accepted by PM — revisit at first EU customer
• No backups — proposed deferral, owner eng lead — revisit before paying customers

Next artifact

$states on dashboard and project list; then a written client note on pilot limits.

Gotchas

• Let one blocker decide the level; do not average a fail away across passing areas.
• Treat login as identity only; it proves nothing about authorization — verify server enforcement on every consequential action.
• Treat hidden UI as no enforcement; probe the endpoint directly as an unauthorized identity.
• Record accepted risk only with a named authorized person and revisit signal; otherwise log a proposed deferral with owner.
• Remember rollback leaves stored changes and external effects in place; name the recovery decision explicitly.
• Stay inside the review scope; do not publish, message stakeholders, or claim compliance as a side effect.

Boundaries

• Do not use when nothing is runnable — use $slice to build one real path first.
• Do not use when the question is only visual drift or token/component divergence — use $system instead.
• Do not use when the question is only missing states — use $states instead.