A 24-bit clock register, a warning that arrived two weeks early, and a software patch that arrived one day too late — the Dhahran Patriot failure
Claim 1 — the mechanism. The Patriot's weapons-control computer stored time in a 24-bit register and converted it by multiplying an integer count by 0.1. Because 0.1 has no exact binary representation, the chopped value produced a clock error that grew the longer the system ran.
"Because of the way the Patriot computer performs its calculations and the fact that its registers are only 24 bits long, the conversion of time from an integer to a real number cannot be any more precise than 24 bits." Appendix II data row: after 100 hours of continuous operation, time error = 0.3433 seconds, range gate shift = 687 meters. source_tier: 1 (GAO government report)
Claim 2 — the institutional failure. The Army knew. Israeli data flagged the drift two weeks before the fatal engagement; the fix arrived a day after it.
"On February 11, 1991, the Patriot Project Office received Israeli data identifying a 20 percent shift in the Patriot system's radar range gate after the system had been running for 8 consecutive hours." "On February 26, the next day, the modified software... arrived in Dhahran." [the Scud struck the barracks on February 25] "the delay in distributing the software... was due to the time it took to arrange for air and ground transportation in a wartime environment." source_tier: 1
Alpha Battery had been running continuously for over 100 hours on February 25, 1991, when it failed to track an incoming Scud, which struck an Army barracks and killed 28 American soldiers.
Why this was hop-worthy
The seed note's abstract mathematical object — "Taylor expansion of accumulated rounding error" — turns out to have a body count, and the fatal delay wasn't the bug, it was logistics.
Hop chain
Hop 1: Linnainmaa 1976 BIT paper, "Taylor expansion of the accumulated rounding error" (seed note, read but not the capture subject) → GAO Report IMTEC-92-26 — https://cs.nyu.edu/~exact/resource/mirror/patriot.htm
- Hook type: Cross-domain bridge / surprising claim
- Hook: the same "accumulated rounding error" mechanism named in the seed has a real, catastrophic instance
- Why followed: cross-domain bridge is the spec's highest-priority hook type; vault_novelty 0.712 (adjacent, bridges Linnainmaa cluster and Burevestnik-OSINT cluster in top-5)
- Key findings: 24-bit register truncation of 0.1; after 100+ hrs, 0.3433s drift, ~687m range-gate error, missed Scud.
Hop 2: same GAO report
- Hook type: Surprising claim / institutional-human-factor
- Hook: the bug was known and diagnosed by Israel two weeks in advance; the fix missed the deadline by one day
- Why followed: zoom-in from abstract mechanism to the specific human timeline that turned a known bug into a fatality; alternation from hop 1's zoom-out
- Key findings: Israeli warning Feb 11 (20% shift after 8 hrs); patched software arrived Dhahran Feb 26, the fatal strike was Feb 25; Army attributed the delay to wartime transport logistics, not to failure to act.
Saved hooks not followed:
- The Al Hussein Scud's own reentry instability confusing Patriot's radar into seeing multiple targets — from the same disaster — reason saved: spun into a separate, larger capture on the Patriot effectiveness controversy and the MIT-Postol/Burevestnik bridge (see companion capture 2026-07-09-hop-patriot-osint-lineage.md) rather than being packed into this one.
- IEEE 754 / "0.1 can't be represented in binary" as general programmer trivia — reason saved: too close to restating the seed note's own subject rather than hopping away from it.
post-worthy: maybe — strong Tier 1 grounding and a genuinely moving human story, but it's adjacent to (and partly subsumed by) the companion capture's broader Patriot narrative; worth keeping as the tight, citable version of just the Dhahran mechanism+timeline.