The short answer

An OTA release is ready to expand only when the team can prove the artifact is trusted, the target is compatible, the first cohort is representative, health is observable, pause criteria are automatic, rollback survives migration, delayed devices have a policy, and an incident owner is available. This checklist keeps those eight controls visible before a rollout widens.

The percentage is a review aid, not a release authorization. One missing control—especially signature verification, compatibility enforcement, health gating, or recovery—can justify stopping even when the other seven are complete.

The eight release controls

  1. Artifact signature verified: the device verifies a trusted signature before installation, with key rotation and revocation considered.
  2. Compatibility enforced: the release targets explicit hardware, bootloader, partition, dependency, and current-version conditions.
  3. Representative canary cohort: early devices reflect relevant hardware, geography, network quality, usage, and operational criticality rather than only friendly lab units.
  4. Boot and application health: telemetry distinguishes download, verification, install, reboot, boot completion, application readiness, and post-update behavior.
  5. Automatic pause thresholds: measurable failure, crash, rollback, latency, battery, or business thresholds stop expansion without waiting for a meeting.
  6. Rollback after data migration: recovery has been tested with changed schemas, configuration, and persistent state—not only a stateless binary swap.
  7. Offline and low-battery policy: late, sleeping, bandwidth-constrained, or power-limited devices receive an explicit eligibility and expiry rule.
  8. Owner and incident channel: a named decision-maker can pause, resume, or roll back, with a live path to engineering and operations evidence.

How the result is calculated

The score is:

checked controls ÷ 8 × 100

All controls are weighted equally so the calculation stays transparent. The result reports how many prompts have evidence; it does not quantify release risk. The summary therefore tells you to keep the authority boundary narrow while gaps remain and, even at 100%, to run a failure exercise before approval.

Worked release review

Assume a team has checked artifact signature, compatibility, canary cohort, application health, offline policy, and incident ownership. Six of eight controls produce a 75% evidenced result. Automatic pause thresholds and rollback after data migration remain open.

That release should not advance simply because most boxes are checked. The team can define a pause threshold—for example, based on a product-specific boot or application failure signal—and demonstrate that rollout orchestration actually stops when the threshold is crossed. It can then update representative devices, migrate persistent state, force a rollback, and verify that both software and data return to a supported condition. The evidence should include device-side state, platform-side rollout state, and the decision log.

Limitations and approval boundary

This checklist does not inspect an artifact, signature, manifest, device, rollout service, telemetry stream, or rollback image. It cannot verify cryptographic trust, measure cohort quality, choose safe thresholds, establish regulatory compliance, or decide whether a particular failure rate is acceptable. It does not cover every concern, such as download authenticity metadata, key ceremonies, anti-rollback rules, secure boot, storage exhaustion, delta-update dependencies, factory recovery, regional capacity, user consent, or safety hazards.

Evidence must be specific to the product. A consumer light, remote industrial controller, and connected medical device cannot share one approval standard merely because they share an OTA mechanism.

Privacy and portable review state

All eight checkbox states are processed locally and encoded as simple flags in the current URL after review. That makes the state easy to reopen or share without a server. The URL contains no artifact name, customer, device ID, incident note, or evidence attachment because the tool does not collect them. Even a completion pattern may be sensitive during an active release, so share it deliberately.

Copy and JSON, CSV, and Markdown exports are generated locally. No checklist state or result is sent to IoT 01.

FAQ

Does every box need to be checked before a canary?

The canary itself is part of gathering evidence, but the canary must still have trusted artifacts, compatibility controls, observable health, a bounded cohort, and a person able to stop it. Do not use production devices to discover that rollback is impossible.

Is automatic rollback always safer?

Not necessarily. A rollback can repeat a failure, corrupt migrated state, or create oscillation. Automatic pause is usually the first invariant; rollback policy needs product-specific evidence.

What counts as representative?

A cohort should cover the hardware, firmware origin, network, power, geography, workload, and operational conditions that could materially change update behavior.

Use Planning a staged OTA rollout to define cohorts, eligibility, health gates, expansion decisions, pause behavior, and evidence for each stage.