UM20147, event 055d4a81, 4,796 B, type read as histogram from the 0x0C byte and
decoded as .IDFH on the first try. The chunk walk, the offset arithmetic, the
11-byte chunk prefix and the record-type byte all hold on the Thor firmware
line unchanged. That closes the last BD gap.
The type byte is now 7 events across both firmware lines -- 4 waveform, 3
histogram -- correct every time. Still not a large sample; the fallback stays.
THE FINDING THAT MATTERS: UM20147's first event key is 055d4a81. So is
UM12947's. Different units, different sizes (4,796 vs 4,076 B), different
contents, identical key.
This confirms keys are a sequential counter, and adds the consequence: the
counter starts from the same value on every unit, so a key is MEANINGLESS
WITHOUT ITS SERIAL. Anything that stores, deduplicates or addresses Series IV
events must key on (serial, event_key). A store keyed on the event key alone
silently treats one unit's event as a duplicate of another's, and the failure is
invisible -- the second event is simply never ingested.
Series III has a related hazard the ACH server already handles: its counter
resets after an erase, so keys are reused WITHIN a unit, which is why
ach_state.json tracks max_downloaded_key per serial. Series IV inherits that
and adds cross-unit collision on top.
Incidentally resolved: memory free is a usable signal after all. Run 1 showed
15,000,000 free and no events; run 3 showed 14,799,296 free, idle, with events
stored. The earlier ambiguity was monitoring overhead confounding it, not
memory being meaningless.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL
serversdownandClaude Opus 5
7d1b033a05