ReleaseProof: Firmware Migration Assurance

Industrial sensor OEMs must keep installed devices updatable for years. Migrating firmware signatures to post-quantum ML-DSA can produce an image that boots perfectly, yet is rejected by the bootloader already in the field. The result is a stranded fleet or costly site visits.\n\nReleaseProof verifies the migration path before rollout. An engineer picks a pinned device/bootloader profile and a change. Google Gemma on AMD Token Factory plans the verification from a registered test catalog; required tests cannot be dropped. Isolated runners on an AMD EPYC host build the real bootloader and images, sign them with ephemeral keys, and boot and update them in Renode, including tampered-image, wrong-key and cross-generation tests. Every artifact is SHA-256 hashed. A deterministic engine, never the LLM, issues separate candidate, transition and migration verdicts. Gemma then explains the result citing evidence IDs and proposes alternatives; evaluating one creates a new, linked run.\n\nMeasured on the public demo with nRF52840 + wolfBoot: the ML-DSA-87 candidate is COMPATIBLE but the transition is INCOMPATIBLE. It was found in 127 s with 7/7 tests and 57 hashed artifacts. With MCUboot/Zephyr, the pinned imgtool refuses ML-DSA (6/6 tests, 45 artifacts). Both runs pass a 27-gate acceptance check, including deployed-source identity and validated AMD planning and reporting.\n\nEach result ships with a portable evidence pack and a CI release gate that blocks unless every verdict is COMPATIBLE. Interrupted-update recovery is not emulated, so it stays UNKNOWN and nothing passes without evidence. ReleaseProof sits between inventory scanners and OTA platforms and answers one question: can the deployed fleet actually get there?