Re-read GAO/IMTEC-92-26 to verify verbatim the Patriot Dhahran time-drift mechanism and Feb 11-26 warning/patch timeline
Method note (source resolution)
This capture answers question-verify-patriot-gao-imtec-92-26-mechanism-and-timeline. The two existing claim-notes cite the report only via a third-party mirror (cs.nyu.edu). This pass located the original GAO venue: https://www.gao.gov/assets/imtec-92-26.pdf. That direct URL returned HTTP 403 Forbidden to both extract_pdf and archive_page — consistent with the other gao.gov known-blocked routes already logged in 00-meta/specs/sources.md (there for NSIAD-92-340; this adds IMTEC-92-26 as a second gao.gov report number that blocks tooling). The text actually read is a Wayback Machine capture of the same gao.gov asset (web.archive.org/web/2020id_/https://www.gao.gov/assets/imtec-92-26.pdf), fetched via extract_pdf, TLS verified, sha256 recorded above. This is the primary document's own text, not a transcription — the PDF's pdftotext extraction is used as source data. As a cross-check, the pre-existing cs.nyu.edu mirror (archived this session, sha256 b4ec6ad2d27e3fd984a5c9d2b07fdc9117504b2842a30aa02e5a4ca4ffae5465) was also re-fetched and its text matches the gao.gov extraction word-for-word wherever compared.
Extraction artifact, noted for the auditor: the gao.gov PDF's pdftotext output splits several quoted sentences with hyphenated line-breaks, inline footnote markers, and page-header interpolations (e.g. "calcula-\ntions", "registers4 ... 24\n[footnote text][page header]bits.6", "199 1" for "1991", "How-\never"). Every quote below was confirmed against the raw extracted text with quote_check (grounded: true) in its literal, artifact-including form before being cleaned up for readability here; the cleaned form is what the vault's two existing notes already carry, and it now has independent verbatim confirmation rather than resting on the original hop capture alone.
Claim: The mechanism explanation — 24-bit registers forcing imprecise time conversion — is verbatim-confirmed against a second, independent fetch of the primary
[Verified — Tier 1, technical-mechanism claim] The GAO's own explanation of the defect reads exactly as previously recorded: "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." A footnote (footnote 4 in the original) clarifies: "The precision of a computer's calculations depends on the number of bits in its registers. Since the Patriot's registers are only 24 bits long, precision beyond 24 bits is not possible unless the software is specifically written to adjust for such hardware limitations. Computers built today have registers that contain as many as 64 bits, permitting calculations with far greater precision." The report states time was "kept continuously by the system's internal clock in tenths of seconds but is expressed as an integer or whole number," and that both time and a target's velocity had to be converted to real numbers for the range-gate calculation — the conversion step is where the 24-bit truncation bit the system. This directly re-confirms the load-bearing quote in claim-patriot-dhahran-1991-clock-drift-from-24-bit-truncation-of-tenths against an independently fetched copy of the primary, closing the re-check that note's audit_status had left open.
Claim: Appendix II's table quantifies the drift at 0.3433 seconds and a ~687-meter range-gate shift after 100 hours, with the full progression from 1 to 100 hours
[Verified — Tier 1, quantitative claim] Appendix II ("Effect of Extended Run Time on Patriot Operation") gives a table of calculated time inaccuracy and resulting range-gate shift at six run-time points, confirmed verbatim in the extracted text:
| Hours running | Seconds elapsed | Calculated time (seconds) | Inaccuracy (seconds) | Range-gate shift (meters) |
|---|---|---|---|---|
| 0 | 0 | 0 | 0 | 0 |
| 1 | 3600 | 3599.9966 | .0034 | 7 |
| 8 | 28800 | 28799.9725 | .0275 | 55 |
| 20 | 72000 | 71999.9313 | .0687 | 137 |
| 48 | 172800 | 172799.8352 | .1648 | 330 |
| 72 | 259200 | 259199.7528 | .2472 | 494 |
| 100 | 360000 | 355999.6667 | .3433 | 687 |
Table footnotes: the 20-hour row is marked "Continuous operation exceeding about 20 hours — target outside range gate"; the 100-hour row is marked "Alpha Battery ran continuously for about 100 hours." This directly re-confirms the figures in claim-patriot-dhahran-1991-clock-drift-from-24-bit-truncation-of-tenths (0.3433 s / 687 m at 100 hours) and additionally supplies the full progression, which that note did not carry — the drift is not linear-looking by coincidence, it is stated by GAO as directly proportional to elapsed run time, matching the mechanism claim above.
Claim: The Feb 11 Israeli-data warning quote is verbatim-confirmed, and it names a specific 20%/8-hour figure, not merely "some loss in accuracy"
[Verified — Tier 1, quantitative + historical claim] Confirmed verbatim: "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." The report adds the extrapolation Army officials drew from it: "Patriot Project Office officials said that the Patriot system will not track a Scud when there is a range gate shift of 50 percent or more. Because the shift is directly proportional to time, extrapolating the Israeli data (which indicated a 20 percent shift after 8 hours) determined that the range gate would shift 50 percent after about 20 hours of continuous use." This directly re-confirms the source_quote already recorded in claim-patriot-dhahran-1991-known-bug-patch-arrived-one-day-late and sharpens it: the 20-hour "target outside range gate" threshold in the Appendix II table above is this same extrapolation, not an independent figure.
Claim: The Feb 11-26 timeline has two intermediate, previously uncaptured dates — a Feb 16 software release and a Feb 21 warning message — between the Israeli warning and the fatal Feb 25 engagement
[Verified — Tier 1, historical/quantitative claim] The two existing claim-notes record only the Feb 11 warning and the Feb 26 patch arrival. The primary document's own timeline has two more dated events in between, both confirmed verbatim in this re-read:
- Feb 16, 1991 — a software version correcting the time-conversion inaccuracy was released, but it only enabled longer safe run times; it did not tell users how long was still safe: "This change allowed for extended run times and was included in the modified software version that was released on February 16, 1991. However, Army officials did not use the Israeli data to determine how long the Patriot could operate before the inaccurate time calculation would render the system ineffective."
- Feb 21, 1991 — the Patriot Project Office sent a message to users warning of the general risk without operational specifics: "On February 21, 1991, the Patriot Project Office sent a message to Patriot users stating that very long run times could cause a shift in the range gate, resulting in the target being offset. The message also said a software change was being sent that would improve the system's targeting. However, the message did not specify what constitutes very long run times."
- Feb 25, 1991 — Alpha Battery, "in operation for over 100 consecutive hours," failed to track the incoming Scud; 28 U.S. soldiers were killed. Confirmed verbatim: "killing 28 Americans" (letter) and "killed 28 American soldiers" (body).
- Feb 26, 1991 — verbatim-confirmed, matching claim-patriot-dhahran-1991-known-bug-patch-arrived-one-day-late: "On February 26, the next day, the modified software, which compensated for the inaccurate time calculation, arrived in Dhahran." The logistics attribution is also confirmed verbatim, in full (the existing note's quote elides a clause): "the delay in distributing the software from the United States to all Patriot locations was due to the time it took to arrange for air and ground transportation in a wartime environment" (bolded clause not present in the previously recorded, slightly shortened quote).
The fuller timeline changes the shape of the institutional-failure argument slightly: it was not "warned once, then silence for two weeks." A corrective software version existed by Feb 16 and a general warning went to users by Feb 21 — four days before the fatal engagement — but neither specified a safe run-time limit, so a battery already running continuously had no way to know it had crossed into danger. This is a refinement of, not a contradiction to, claim-patriot-dhahran-1991-known-bug-patch-arrived-one-day-late's framing.
Further leads
- Rebooting the Patriot "takes about 60 to 90 seconds" and "reinitializes the computer's clock, setting the time back to zero" — direct primary-source confirmation of the reboot-resets-drift mechanic that claim-patriot-dhahran-1991-clock-drift-from-24-bit-truncation-of-tenths's commentary already inferred. GAO/IMTEC-92-26, Tier 1.
- "During the conflict the Patriot's software was modified six times. Patriots had to be shut down for at least 1 to 2 hours to install each software modification" — a second logistics-cost figure (deployment friction, not just transport time) that could extend claim-patriot-dhahran-1991-known-bug-patch-arrived-one-day-late's "deployment latency as a safety property" point. GAO/IMTEC-92-26, Tier 1.
- U.S. commanders declined to use available external data recorders "because they believed the recorders could cause an unanticipated system shutdown," while Israeli commanders did use theirs and supplied that data to the U.S. Army — a specific reason the diagnosis came from an ally rather than from American units' own telemetry. GAO/IMTEC-92-26, Tier 1.
- GAO's review period was "June 1991 to January 1992," and GAO independently re-derived the Army's fix by "performing the key calculations needed to account for longer run times" and by running a live intercept simulation at the Patriot Software Test Facility, Huntsville — evidence the 24-bit mechanism claim isn't merely relayed from the Army but independently checked by the auditor. GAO/IMTEC-92-26, Tier 1.
- Report addressed to Rep. Howard Wolpe (Chairman, Subcommittee on Investigations and Oversight), signed by Ralph V. Carlone (Assistant Comptroller General), GAO control number B-247094 — bibliographic/provenance detail not yet in the vault's entity layer for this cluster.
- The two existing claim-notes'
source_urlstill points at the cs.nyu.edu mirror; this capture found and verified the actual gao.gov original (via a Wayback Machine capture, since gao.gov 403s to tooling directly) — worth a promotion-time update to cite the primary venue per the public-shelf "cite the original, not a mirror" rule, with the archived copy's sha noted as the read-of-record since the live URL itself will not serve tooling.
Entity candidates
- Israeli commanders / Israel Defense Forces (Patriot units in Israel) — concept/entity — the FOUNDATIONAL source of the corrective data: GAO states plainly that Israeli units used external data recorders the U.S. Army chose not to use, and "provided this data to the U.S. Army," which is what let the Army diagnose the drift at all. The report's whole timeline (Feb 11 onward) rests on this earlier, uncredited-by-name data-collection work — flag first, per the known blind spot.
- Howard Wolpe — person — Chairman, House Subcommittee on Investigations and Oversight, whose request produced GAO/IMTEC-92-26; the report's addressee and the reason it exists.
- Ralph V. Carlone — person — GAO Assistant Comptroller General who signed the report; distinct from entity-richard-davis-gao (a different GAO official, Director of Army Issues, tied to the separate NSIAD-92-340 report in the effectiveness-rate cluster) — worth keeping these two GAO figures from being conflated.
- Michael Blair, Sally Obenski, Paula Bridickas — persons — GAO's named major contributors (Assistant Director, Evaluator-in-Charge, Computer Scientist) to IMTEC-92-26; the report's actual working authors, distinct from its signatory.
- Patriot Project Office (Huntsville, Alabama) — concept/entity — the Army unit that wrote and distributed the corrective software; the organizational actor at the center of the Feb 11-26 timeline.
Safety flags
None. No page encountered during this session showed addressed-to-AI language, override language, claimed authority, tier self-assignment, file-system instructions, credential requests, or urgency framing. The gao.gov direct-fetch failures were ordinary HTTP 403 responses, not adversarial content.
Source
claude-sonnet-5 · Batch capture, 2026-08-26, answering [[question-verify-patriot-gao-imtec-92-26-mechanism-and-timeline]] — re-fetch and verbatim re-check of GAO/IMTEC-92-26, independent of the 2026-07-09 hop capture that first sourced [[claim-patriot-dhahran-1991-clock-drift-from-24-bit-truncation-of-tenths]] and [[claim-patriot-dhahran-1991-known-bug-patch-arrived-one-day-late]]. · raw markdown