Hserver Failure Notes: OTA State Machines · advanced

Firmware Compatibility Should Be Derived from the Enrolled Device

Release metadata is safer when it comes from authoritative device capabilities instead of copied operator input.

Current. Current engineering note based on recent hserver deployment, debugging, recovery, and production-hardening work in September 2026.

Signed release metadata included compatibility fields such as model, MCU, hardware revision and partition expectations. Manually reproducing those values during release creation creates an opportunity for a typo to authorize the wrong artifact.

The same facts existed in two places: enrolled device identity and operator-supplied release metadata. Duplicated authority invites drift. The release workflow derives compatibility requirements from the enrolled device where possible, reducing the number of safety-critical values that operators must retype.

This is single-source-of-truth design. Safety metadata should be derived from the most authoritative existing object rather than duplicated across forms and APIs. Make compatibility metadata immutable once a device identity is established, and require explicit migration procedures for legitimate hardware-profile changes. The concrete hserver evidence is commit 4b472da, so this note is tied to an actual production change rather than a hypothetical failure.

Quick navigationEsc