The two forced-outage captures used a temporary validation build that made the packet writer report failure while acquisition kept running. That injection was removed before production firmware was built and flashed.

forced_outage_3s.trk — SHA-256 01482816cdaa668e4681c33c8baa1df331d733b9bbcbc4f448ece25e88185ad6. It contains 2,144 contiguous samples, sequences 0 through 2,143, with no reported drops, overruns, or timestamp saturation.
forced_outage_7s.trk — SHA-256 2ea8a5742944bdebc13bec2ccdbceba75f0bb71e48c856b0f86285878e190cd3. It contains 1,840 delivered samples. The sole sequence gap is 511 to 650: 138 samples were dropped after the 512-entry queue filled, the cumulative drop count reached 138, and the corresponding timestamp delta is exactly 1,390,000 us.
direct_usb_stall.trk — SHA-256 40f874b7eaa7f705524ecdd75f832e8a724252366633116ac015fc75dfd16558. This came from the direct USB driver build after leaving the enumerated USB endpoint without a serial reader long enough to overflow the acquisition queue. It contains 864 samples. The retained block ends at sequence 511, delivery resumes at 1,706, and both the sole 1,194-sample gap and the device's cumulative drop counter equal 1,194. There are no packet gaps, CRC failures, loop overruns, trailing bytes, or timestamp-saturation flags.

The first captured sample is sequence 8 because the flashing process still had the endpoint open long enough to drain sequences 0 through 7 before the capture application opened. That is deliberate evidence of the remaining distinction: USB endpoint drain is observable, but application receipt requires the planned acknowledgement/replay layer.
direct_usb_3c95f3d.trk — SHA-256 f495486f094a758bb785e145026e3934d60b52dd5083aef7f5d896195d967869. This is the validated-frame output from the final exact-commit smoke capture: 1,680 contiguous samples, sequences 0 through 1,679, with zero packet/sample gaps, resets, CRC failures, reported drops, loop overruns, trailing bytes, or timestamp saturation.
direct_usb_3c95f3d.wire — SHA-256 3bdaeadff7962c6eac48c4ebeda285c8eb359e439d5e1728104add2009122c03. This is the byte-for-byte wire side of the same capture. It contains 563 bytes of startup text before the valid frames. That text includes the literal TRK1, producing one rejected candidate header as designed. Extracting all valid frames reproduces direct_usb_3c95f3d.trk byte-for-byte.
direct_usb_73e5680.trk — SHA-256 fd34bb3bf8f92a64960024f1287e553c03076ff3714fe629ec629bec81ddf821. This exact firmware-hardening capture contains 1,184 contiguous samples, sequences 0 through 1,183, with zero packet/sample gaps, resets, CRC failures, reported drops, loop overruns, trailing bytes, or timestamp saturation.
direct_usb_73e5680.wire — SHA-256 82d6d17bbf0729e9bfc53f337ec9adf70bcb5e5898b039685eda5dfa19cf4eea. This is the byte-for-byte --reset --wire capture corresponding to the validated file above. Its 3,589 skipped startup bytes and one candidate-header rejection are deterministic, and extracting its 151 valid frames reproduces direct_usb_73e5680.trk byte-for-byte.
ble_reconnect_483ace3.trk — SHA-256 c4a0d795cdf9d490acaca0144c3ad33f85bbfb2214d3f7abdfe515c4e5f25398. This is the resumed half of a real macOS receiver interruption against exact firmware commit 483ace3. It contains 2,576 contiguous samples, sequences 1,992 through 4,567, with zero packet/sample gaps, resets, CRC failures, reported drops, loop overruns, trailing bytes, or timestamp saturation. The final status records one disconnect and one deliberate frame replay, with zero notification failures or invalid ACKs. It validates that the 10.24-second queue covered the measured resubscription interval without permanent loss.

tests/test_trikke_protocol.py verifies the hashes, parses the captures in fragmented chunks, and asserts these signatures so the hardware evidence remains executable regression data. To inspect a file manually:

python3 tools/decode_binary.py tests/fixtures/forced_outage_3s.trk /tmp/outage.csv