Compatibility

Compatibility is the eligibility gate. Even if a device is in a deployment's audience and lands inside the cohort percentage, it will only be offered an artifact whose manifest matches its hardware profile.

Enforced dimensions

The decision engine currently enforces these dimensions on every check:

Dimension	How matched
framework	Exact: arduino ≠ esp_idf.
chip_family	Exact: esp32 ≠ esp32s3 ≠ esp32c3.
board_id	Blank artifact constraint matches anything; otherwise exact.
hardware_revision	Artifact's hardware_revision_min/max range (inclusive). Blank bounds mean no constraint.

Progressive dimensions

These are enforced too, but with a softer rule. On the identity dimensions above, an artifact constraint plus a device that has never reported the dimension is a rejection. Here, a device that has not reported yet is let through.

That difference exists to avoid a bootstrapping deadlock: if a device had to report partition_profile before it could be offered an update, a fleet running firmware that predates the reporting code could never receive the build that would teach it to report.

Dimension	How matched
partition_profile	Blank on either side matches; otherwise exact.
security_mode	Blank on either side matches; otherwise exact.
nvs_schema_version	The device's version must be greater than or equal to the artifact's. Unset on either side means no constraint.

nvs_schema_version is the one comparison that is not equality: an artifact declaring schema 3 is offered to devices reporting 3 or higher, never to a device still on 2, because older firmware may have written an incompatible NVS layout.

Worked rejection example

A device reports chip_family = esp32s3, board_id = freenove-cam. An artifact's manifest declares chip_family = esp32s3, board_id = esp32s3-devkitc-1.

→ Not compatible. board_id mismatch. Even at 100% rollout, this device sees {"update_available": false} for that artifact.