Patriot Clock Drift and Battlefield Accountability

Summary

On 25 February 1991, a Patriot battery at Dhahran failed to track and intercept an incoming Iraqi Scud. The U.S. General Accounting Office concluded that a software problem in the weapons control computer produced an inaccurate tracking calculation that worsened with continuous operating time. The Scud struck an Army barracks, and GAO reported that 28 Americans were killed.
The technical mechanism was finite-precision time conversion. The system kept time in tenths of a second and converted an increasingly large integer clock value for range-gate calculations. Its 24-bit registers limited the precision of that conversion. After the Dhahran battery had operated for more than 100 consecutive hours, the accumulated time error was about 0.3433 seconds and the predicted range gate was displaced by about 687 meters.
The error was already becoming institutionally visible. Israeli data received on 11 February showed a significant range-gate shift after eight hours. A compensating software modification was released on 16 February, and a 21 February message warned users that very long run times could shift the range gate. Yet the warning did not define “very long,” officials assumed batteries would not remain on long enough to fail, and the modified software reached Dhahran on 26 February, one day after the attack.
Accountability therefore extends beyond the arithmetic. It follows control over the numeric representation, endurance assumptions, anomaly analysis, operational limits, warning content, restart authority, software distribution, unit configuration and proof that corrective action reached the battery before it was needed. A small computational error became catastrophic because the technical and operational control system did not bound it in the conditions of deployment.

Dhahran Turned Uptime Into a Safety-Critical State

Software uptime is often treated as evidence of reliability. A system that has remained available for days may appear more trustworthy than one that has recently restarted. The Patriot failure at Dhahran exposes the opposite possibility: elapsed time itself can be a growing hazard. If an internal calculation loses accuracy as the clock value increases, continued operation is not neutral. It changes the system’s state even when no component visibly crashes and no operator sees an alarm.

GAO’s February 1992 report established the central event. On 25 February 1991, a Patriot missile defense system operating at Dhahran, Saudi Arabia, failed to track and intercept an incoming Scud. The missile struck a U.S. Army barracks. GAO reported that 28 Americans were killed. Its review was requested to determine whether a software problem was involved, what the problem was and what had been done to correct it.

The report’s answer was direct. A software problem in the weapons control computer led to an inaccurate tracking calculation that became worse the longer the system operated. At the time of the incident, the battery had been operating continuously for more than 100 hours. The accumulated inaccuracy caused the system to look in the wrong place for the incoming target.

That description matters because it distinguishes the case from a total power loss, a frozen display or a conventional crash. The Patriot battery remained a running system. The dangerous degradation existed inside a calculation used to decide where radar processing should look next. A system can therefore be operational in the administrative sense—powered, staffed and available—while becoming operationally unfit for a specific safety function.

The accountability question is not simply why a computer represented a fraction imperfectly. Binary machines routinely approximate quantities that cannot be expressed exactly within a fixed number of bits. The harder question is why the approximation was permitted to accumulate beyond a safe bound in a live defensive mission, and why the organizations controlling software, operations and field support did not convert the known limit into protection for the deployed unit.

What the Official Record Establishes

The GAO report should remain the primary authority for the Dhahran software finding. It was not a retrospective classroom anecdote assembled from folklore. GAO interviewed officials responsible for Patriot software maintenance, reviewed Army analyses, examined architecture and assembly-language material, analyzed the machine instructions associated with the inaccuracy, checked the corrective calculation and participated in a simulation at the Patriot Software Test Facility. The report says officials generally agreed with the facts as presented.

That does not mean the report settles every controversy about Patriot performance during the Gulf War. The system’s broader intercept record became the subject of political, technical and evidentiary dispute. Claims about whether other engagements destroyed incoming warheads involve different evidence, definitions and causal questions. Those debates should not be imported into the Dhahran software case as if they were interchangeable.

For this incident, GAO described a narrower and well-supported chain. The weapons control computer used target information from the radar. A range-gate algorithm calculated an area where the system should next look for a suspected Scud. Data outside that calculated area were filtered out, while information inside it supported tracking, targeting and interception. The prediction depended on the target’s velocity and the time of the last radar detection.

The system clock kept time in tenths of seconds as an integer. Tracking calculations required time and velocity to be expressed as real numbers. Because the computer’s registers were 24 bits long, converting the time value introduced a loss of precision. The effect grew with both operating duration and target velocity. Extended operation shifted the calculated range gate away from the target’s actual position.

GAO then connected the calculation to the field outcome. Alpha Battery had run continuously for more than 100 hours. The range gate shifted so far that the battery did not track the incoming Scud and therefore did not engage it. This is the official causal boundary for the software failure. Analysis can draw governance lessons from it, but it should not invent additional battlefield orders, individual motives or undocumented decisions.

The Numeric Error Was Small Per Calculation and Large in Context

The arithmetic is frequently compressed into the phrase “rounding error.” That phrase is directionally true but institutionally incomplete. It suggests a harmless decimal discrepancy or a programmer’s isolated mistake. The actual risk came from the interaction of representation, accumulation, target speed and continuous use.

The system counted time in units of one-tenth of a second. A tenth has no finite exact representation in binary, just as one-third has no finite exact representation in decimal. A computer must store an approximation. The Patriot computer’s architecture constrained the precision available for the conversion used in the tracking calculation. Each conversion was close to the intended value, but not identical to it.

Elapsed time was represented by an integer that increased as the system remained on. When that larger clock count was converted using the limited-precision approximation, the absolute difference between calculated and actual time also increased. The software did not need to become less careful from one moment to the next. The same representation method generated a larger operational error because it was applied to a larger elapsed-time value.

GAO’s appendix quantified the progression. After one hour, the calculated time was about 0.0034 seconds short, corresponding to an approximate seven-meter range-gate shift. After eight hours, the report listed a time inaccuracy of about 0.0275 seconds and a shift of about 55 meters. After 20 hours, the inaccuracy was about 0.0687 seconds and the shift about 137 meters. At 100 hours, the calculation was about 0.3433 seconds short and the approximate shift was 687 meters.

These numbers show why “only a fraction of a second” is the wrong risk frame. A fraction of a second must be evaluated against the speed of the target and the logic that consumes the time value. GAO described Scuds as traveling at approximately Mach 5 in this operational context. A rapidly moving target covers a consequential distance during a short timing interval. The range gate’s job was to restrict where the radar processing looked next. Once prediction error displaced that gate far enough, the real target could fall outside the area being treated as relevant.

The result was not merely a less elegant estimate. It altered what the system could recognize as the target. The calculation helped determine whether an entity was identified, tracked and considered within firing range. A numeric approximation therefore sat inside a decision boundary with direct consequences for engagement.

This is a recurring safety principle. Error magnitude cannot be assessed in isolation from the transfer function between calculation and action. A small time error may be immaterial in a payroll batch and catastrophic in collision avoidance, medical dosing, industrial control or missile tracking. Engineering assurance must translate numeric error into domain effect at the worst credible operating state.

A Design Assumption Became an Undeclared Operating Limit

GAO reported that Patriot was originally designed as a mobile air-defense system. Its earlier operating concept anticipated movement and only a few hours of operation at one location. During the Gulf War, batteries were placed in relatively permanent positions to protect assets, personnel and civilians from Scud attacks. The system was also being used against a target class and flight profile that had not defined its original mission.

This is not proof that adaptation was inherently irresponsible. Deployed systems are often asked to meet changed threats. It is evidence that assurance based on the original operating envelope cannot silently follow the system into a different one. A mobile system expected to restart or relocate every few hours may contain state variables whose long-duration behavior was never treated as safety critical. A battery kept continuously available for days creates a different endurance requirement.

The clock drift was therefore also an interface failure between design assumptions and field doctrine. Software embodied an assumption about how large elapsed time would become. Wartime practice created a much larger value. Neither side alone defines safety. The system is safe only if the deployed operating pattern remains within the validated envelope or if the software and procedures are changed before the envelope expands.

An operating-duration limit that exists only implicitly in arithmetic is not an effective limit. Operators cannot comply with a threshold they were never given. Commanders cannot plan relief, restart windows or overlapping coverage around a number that has not been translated into doctrine. Logistics teams cannot prioritize a software modification if they are not told which units are approaching a hazardous state.

The Dhahran case therefore asks who owned the operating envelope. Software maintainers controlled knowledge of the calculation. The project office could analyze anomaly data and change code. Operational commands knew how batteries were actually being run. Deployed units controlled immediate configuration and restart actions within the authority and threat conditions they had been given. Senior Army leadership controlled the system for distributing warnings and updates. Safety depended on those views being reconciled.

The relevant requirement was not merely “track Scuds.” It was closer to “maintain required tracking accuracy for the longest continuous operating period that wartime deployment may demand.” Had that endurance condition been explicit, numeric error analysis, long-run testing, field instructions and configuration reporting could have been evaluated against the same measurable boundary.

Israeli Data Made the Risk Visible Before the Attack

The defect did not become knowable only after Dhahran. GAO described field evidence received before the incident. On 11 February 1991, the Patriot Project Office received Israeli data identifying a 20 percent shift in the radar range gate after eight consecutive hours of operation. Israeli-controlled systems had used external data recorders, providing information that was useful to the Army’s analysis.

Project Office officials said the system would not track a Scud when the range-gate shift reached 50 percent or more. Because the shift was proportional to operating time, the eight-hour result could be extrapolated. GAO reported that after about 20 hours of continuous use, the inaccurate time calculation became large enough for the radar to look in the wrong place.

That sequence is a classic anomaly-escalation test. Evidence existed, but evidence does not protect a system until it is converted into a controlled decision. The initial 20 percent shift could be described as degraded margin rather than immediate failure. Yet its significance depended on the trajectory of the error. A growing error with a known failure threshold requires projection, not merely observation.

GAO reported that Army officials initially believed the Israeli experience was atypical. They assumed other users were not running systems for eight hours or more at a time. That belief was an operational assumption, and it was wrong for Alpha Battery at Dhahran. The unit ultimately remained in continuous operation for more than 100 hours.

The governance failure was not that officials ignored all evidence. They analyzed the data, confirmed a loss of accuracy and made a software change. The gap was that the anomaly did not produce a complete, field-enforceable safety response before the fix reached every exposed unit. GAO said officials did not use the Israeli data to determine how long Patriot could operate before the inaccurate calculation rendered the system ineffective.

That distinction matters. Corrective development and interim risk control are separate obligations. Once a patch is being prepared, organizations may act as though the problem is on a path to closure. A deployed unit remains exposed until the corrected configuration is installed or an effective mitigation is in force. The time between defect confirmation and fleetwide installation is itself a managed hazard interval.

The Warning Did Not State the Threshold Operators Needed

On 21 February, the Patriot Project Office sent a message to users stating that very long run times could shift the range gate and offset the target. The message also said a software change was being sent to improve targeting. GAO identified a decisive weakness: the message did not specify what counted as “very long.”

Qualitative language can communicate concern without enabling action. “Very long” may mean eight hours to a software analyst, a day to a commander or several days to a crew operating under constant threat. An operational warning must connect the hazard to a measurable state and a required response. It should say when risk becomes unacceptable, what the unit must do, who may authorize the action and how compliance is recorded.

Army officials told GAO they presumed users would not run batteries continuously for periods long enough to fail, so they did not believe more detailed guidance was necessary. That presumption illustrates why warning design cannot rely on the same assumption implicated in the hazard. If field practice is uncertain, the warning process should verify it. Acknowledgment should include the unit’s current uptime, software version and planned mitigation, not merely confirmation that a message was received.

The Dhahran battery’s actual state—more than 100 hours of continuous operation—was not a subtle edge around the projected 20-hour loss-of-tracking point. It was far beyond it. A control system capable of matching warnings to unit state should have identified Alpha Battery as urgent.

This is where accountability becomes evidentiary. It is not enough to show that headquarters transmitted a general message. The relevant proof is whether the exposed unit received an intelligible limit in time, understood its consequence, had authority and opportunity to act, and reported completion. Transmission logs prove only the beginning of that chain.

Warnings for safety-critical software should be versioned operational directives. They need a defect identifier, affected configurations, observable trigger, maximum safe state, mitigation, responsible role, deadline, receipt confirmation and closure evidence. When the threshold is time-dependent, the warning should also require reporting of current uptime. Otherwise the central risk variable remains invisible to the organization trying to control it.

Rebooting Was a Mitigation, but Not a Complete Control System

GAO reported that rebooting the Patriot system every few hours could eliminate significant range-gate shifts by reinitializing the computer clock to zero. It described the restart as taking approximately 60 to 90 seconds. In purely technical terms, that was a simple mitigation for accumulated elapsed-time error.

Operationally, “just reboot” is not self-executing. An air-defense battery exists to provide continuous protection. Even a short interruption may need to be coordinated against current alerts, coverage from other batteries, command authority and crew workload. The same report noted that installing software modifications required systems to be shut down for at least one to two hours, a much longer interruption with obvious planning implications.

This does not establish that a restart at a particular moment was impossible or that operators refused an available order. The public evidence in the source set does not support that claim. It shows why a mitigation must be translated into doctrine before it can be credited as a control.

A credible restart control would identify a maximum uptime below the dangerous threshold, warn as that limit approaches, specify who orders the restart, coordinate temporary coverage, verify that the clock has reset and record the new start time. If continuous protection makes restart unacceptable, the organization must provide overlapping capacity or accelerate installation of corrected software. The hazard cannot be managed by hoping field crews infer a procedure from an imprecise warning.

The existence of a technically easy mitigation can sometimes weaken institutional response. Decision-makers may assume that someone near the system can solve the problem informally. That assumption transfers responsibility without transferring instructions, authority or evidence. In a safety case, a mitigation counts only when it is feasible under operational conditions and demonstrably implemented.

The Software Fix Existed Before the Attack but Arrived After It

After analyzing the Israeli data, the Patriot Project Office developed a software change to compensate for the inaccurate time calculation and allow extended run times. GAO reported that the modified version was released on 16 February 1991. It arrived in Dhahran on 26 February—the day after the fatal attack.

Army officials attributed the distribution delay to the time required to arrange air and ground transportation to all Patriot locations in a wartime environment. That context is relevant. Delivering physical software media, technical support or controlled configuration changes across a theater of operations is not equivalent to distributing a routine consumer update. But operational difficulty does not erase exposure. It defines the logistics requirement that the safety process must manage.

The nine-day interval between release and the Dhahran incident should be treated as a configuration-risk window. During that window, some units remained on software known to have a duration-sensitive tracking problem. A mature process would maintain a live inventory of affected batteries, their software versions, current uptime, mission criticality, update shipment status and interim mitigation.

Priority should follow risk, not merely a standard distribution sequence. A unit already beyond the projected safe operating duration would warrant immediate attention. If a corrected version could not arrive quickly, the command system would need to enforce a restart schedule or another approved measure. Each unit should move through explicit states: affected, warned, mitigated, update dispatched, update received, installed, functionally checked and closed.

The Dhahran case predates network-delivered software operations as they are now commonly understood, but the accountability problem remains current. A vendor or project office may release a fix while the installed base remains vulnerable. “Patch available” is not the same as “risk removed.” Organizations responsible for high-consequence systems need evidence at the last mile.

The same logic applies to hospitals, industrial plants, public-safety networks and critical infrastructure. Corrective code sitting at headquarters does not protect a remote system. Safety depends on distribution time, local authority, installation opportunity, compatibility testing and proof of the resulting configuration.

Limited Performance Recording Weakened Learning

GAO also described an evidence constraint. Patriot did not have an embedded internal data recorder that retained detailed performance information. Portable external recorders were available, but U.S. commanders decided not to use them because of concern that the recorders might cause an unanticipated system shutdown. Israeli commanders used recorders and supplied data that helped reveal the range-gate anomaly.

The decision presents a real safety tradeoff. Adding instrumentation to a live weapons system can create its own risk. A recorder that might disrupt operation cannot be treated as harmless. Yet declining to collect data also has a cost: degradation may remain invisible, anomaly analysis becomes slower and post-event reconstruction becomes less certain.

Accountable engineering requires that this tradeoff be made explicitly. If the preferred recorder is too risky for routine use, an alternative evidence path is needed. That could include independently validated passive instrumentation, scheduled diagnostic collection, laboratory replay using representative long-duration states, redundant recording on selected batteries or a formal plan for capturing anomaly data without interfering with engagement.

The important point is not that commanders should always choose more telemetry. It is that a high-consequence system adapting to a new target and new operating pattern needs a defined learning system. During Desert Storm, software was modified repeatedly as operational experience accumulated. GAO reported six software modifications between August 1990 and February 1991. Rapid adaptation increases the importance of trustworthy performance evidence and configuration traceability.

Without good records, organizations depend more heavily on user reports, assumptions and isolated observations. That makes it easier to dismiss an anomaly as atypical and harder to determine whether a change worked across the fleet. Evidence collection is therefore part of the protection system, not merely a resource for historians after failure.

Accountability Follows Practical Control

No single role controlled every link in the Dhahran chain. That is precisely why a systems-accountability model is necessary. Distributed responsibility should not become diluted responsibility.

Software and hardware engineering controlled the representation choices, knowledge of 24-bit limitations, corrective algorithm and verification of the modified calculation. Their obligation was not to guarantee mathematical perfection. It was to identify the error bound across the credible operating range and show that tracking remained within required tolerance.

The Patriot Project Office controlled anomaly analysis, software maintenance and important parts of warning and distribution. Once Israeli data showed degradation, the office was positioned to convert the observation into an operating limit, corrective version and prioritized field action. GAO’s account shows that it did develop a fix and communicate a warning. Accountability analysis asks why those actions did not amount to timely protection at Dhahran.

Operational leadership controlled doctrine and knowledge of how batteries were actually being used. If systems were remaining continuously active for days, that fact needed to reach the people evaluating endurance assumptions. Commands also controlled whether restarts, update downtime and overlapping protection could be planned.

The software distribution and theater-support chain controlled the movement of the modified version to deployed locations. In a wartime environment, transportation delays may be understandable, but they remain part of the system’s risk. Logistics performance should be measured against hazard urgency.

Unit leadership and operators controlled local actions within the orders, information and authority available to them. They should not be assigned sole blame for failing to infer an unstated threshold. Conversely, a safety process must define what unit-level evidence is required: uptime logs, warning acknowledgment, restart record, installed version and functional check.

Army and defense leadership controlled the larger governance system: readiness criteria, reporting channels, fielding authority, independent review and the balance between availability and corrective downtime. Institutional accountability sits at this level because local teams cannot create fleetwide configuration visibility or rewrite warning policy on their own.

The manufacturer’s role should also be bounded by evidence. The reference supports discussion of software maintenance and technical correction, but it does not justify treating one programmer or company as the complete cause. The operational failure emerged from a technical defect interacting with system architecture, changed mission conditions, assumptions about uptime, incomplete warning content and delayed deployment of the correction.

This layered allocation is more demanding than naming a culprit. It requires each owner to produce evidence for the control it held. Engineering produces error analysis and test results. The project office produces hazard decisions and release records. Command produces operating doctrine and unit-state visibility. Logistics produces delivery evidence. Units produce configuration and mitigation confirmation. Oversight verifies that the chain closes before exposure continues.

The Case Is Not a Verdict on Every Patriot Engagement

Patriot’s broader Gulf War effectiveness was contested. GAO testimony, technical policy analysis and later public reporting questioned official success claims and examined the difficulty of establishing warhead kills. Other parties defended the system’s performance. Those debates are relevant context for evidence quality, but they are not needed to inflate the Dhahran clock-drift finding.

The specific case has its own official record: one battery failed to track and engage an incoming Scud because an inaccurate timing calculation had grown during extended operation. Keeping the boundary narrow improves accountability. It prevents a documented software failure from becoming a rhetorical proxy for every claim about the weapon system.

The same discipline applies to casualty reporting. GAO’s Dhahran report states that the Scud hit an Army barracks and killed 28 Americans. That figure can be attributed to GAO. The article should not add a precise injury count, a detailed sequence inside the barracks or claims about individual response actions unless equally reliable evidence supports them.

Nor does the record establish intentional wrongdoing. The evidence supports findings about assumptions, calculation limits, warning specificity and update timing. It does not support claims of sabotage, criminal conduct or a deliberate decision to expose the unit to a known fatal outcome.

It is also important not to describe every finite-precision calculation as a defect. Approximation is inherent in computing. The defect lies in using an approximation whose accumulated error exceeds the system’s tolerance under credible operating conditions without effective detection or control.

Finally, the case should not be reduced to operator error. GAO reported that officials presumed users would not run batteries for very long periods, while the field reality at Dhahran was more than 100 hours of continuous operation. That mismatch is an institutional interface problem. Operators are part of the system, but they cannot enforce a limit that engineering and command have not made explicit and actionable.

What a Stronger Control System Would Require

The most useful lessons from Dhahran are concrete. “Use more precision” is one repair, but it is not a complete governance program.

Define Numeric Tolerance in Operational Terms

Requirements should state the maximum permitted prediction error at the longest credible uptime and highest relevant target velocity. They should identify the point at which the range gate no longer provides required tracking probability. A bit-width decision becomes reviewable only when translated into physical effect.

Engineers should calculate worst-case accumulated error, not only error per conversion. Tests should exercise clocks near and beyond endurance limits. If software uses elapsed time in multiple functions, each path needs an error budget.

Make the Operating Envelope Explicit

The validated envelope should include continuous operating duration, target characteristics, restart assumptions, software version and environmental conditions. When deployment changes from mobile, short-duration use to fixed, continuous readiness, the change should trigger a formal reassessment.

An uptime limit belongs in technical orders, operator displays, readiness dashboards and command planning. It should not remain discoverable only through later analysis of assembly instructions.

Instrument Uptime and Margin

The system should expose the safety-relevant state. Operators and support commands need an accurate measure of continuous runtime and a clear indication of remaining tracking margin. Warnings should escalate before the limit, not after the calculation becomes ineffective.

Instrumentation must itself be tested for non-interference. If recording creates unacceptable risk, the program needs another validated evidence mechanism. Choosing not to record cannot mean choosing not to learn.

Separate Corrective Development From Interim Mitigation

When a permanent software change is in progress, an interim hazard control still needs an owner. The mitigation may be scheduled rebooting, reduced maximum uptime, overlapping coverage, restricted mission mode or another engineered measure. It needs documented feasibility and completion evidence.

The risk remains open until every affected unit is protected, not merely until code is released.

Use Quantified Warnings

Safety messages should replace phrases such as “very long” with thresholds. They should identify affected versions, state the consequence, require specific action and name the authority responsible for that action. If the threshold depends on current state, units should report that state with their acknowledgment.

A message is not closed when it leaves headquarters. Closure requires receipt, comprehension, action and verification.

Maintain Fleet Configuration Visibility

Program and operational leaders should know which software version each battery is running, when it last restarted, which warnings it has acknowledged and whether the corrective change passed a local functional check. That inventory should be current enough to prioritize risk during fast-moving operations.

Configuration records also prevent a common failure mode in which organizations assume a published fix has removed exposure everywhere.

Plan Safe Maintenance Windows

Restarting or installing software may interrupt protection. That creates a legitimate operational problem, not an excuse to leave the hazard unmanaged. Commands should plan overlapping coverage, phased maintenance or another continuity measure. Authority to accept the brief maintenance risk versus the growing calculation risk should be explicit.

Test the Mission Actually Being Performed

Endurance testing should reflect continuous wartime operation, not only the shorter sessions imagined in the original concept. Target models should reflect the speed and behavior of the threats the system is assigned to engage. Testing must cover the interaction of runtime, numerical representation and range-gate logic.

GAO reported that an endurance test was later conducted to ensure extended run times did not create other system difficulties. The durable control is to make that class of testing routine before deployment conditions expose the limit.

Preserve Independent Verification

Safety-critical corrections should be independently checked against the stated error bound and operational scenario. GAO itself recalculated the correction as part of its review. Programs should not need a post-failure audit to discover whether long-duration arithmetic has been evaluated.

Independent review should also assess warning adequacy, field distribution and configuration closure. Software verification alone cannot show that the corrected version reached the exposed system.

Counterfactuals Clarify Controls but Do Not Rewrite History

Several counterfactuals help identify missing controls. If the timing conversion had maintained adequate precision at 100 hours, the specific range-gate displacement described by GAO would not have developed in the same way. If the battery had been restarted within an enforced safe interval, the internal clock would have returned to zero and the accumulated error would have been reduced. If the modified software had arrived and been installed before 25 February, the compensating calculation may have addressed the known problem.

These are control-oriented propositions, not claims that any single change would certainly have prevented every consequence of the attack. Interception is a complex physical and operational process. The public evidence establishes why Alpha Battery did not track and engage this Scud; it does not warrant a guarantee about the result of a hypothetical engagement.

Another counterfactual concerns warning content. A quantified directive issued on 21 February, matched to the current uptime of every affected unit and backed by restart authority, would have made the risk more actionable. Whether it would have been executed at Dhahran depends on facts not fully established here. The lesson is that the actual qualitative warning did not provide the threshold operators needed.

The purpose of counterfactual analysis is to connect each failure point to a testable control. It should not be used to create certainty after the fact or to erase the constraints of wartime operations.

Modern Systems Still Accumulate Invisible Time Risk

The architecture in the GAO report reflects its era, but the risk pattern is contemporary. Long-running systems accumulate state: counters grow, clocks wrap, leases expire, certificates age, offsets drift, queues deepen and numerical approximations compound. A service can pass short tests and still fail after days or months of uptime.

Modern hardware offers wider registers and greater precision, but width alone does not guarantee safety. Software still converts among time units, clock domains and numeric types. Distributed systems combine wall clocks, monotonic clocks and remote timestamps. Embedded devices may conserve memory or processing power. Safety depends on analyzing the actual representation and mission duration.

Operational assumptions also continue to change faster than systems. A platform designed for intermittent use may become continuously available infrastructure. A backup tool may become a primary service. A regional deployment may become global. A system built for one workload may be exposed to a faster or more variable environment. Each change can invalidate an implicit limit.

The warning-chain problem is equally current. Security and safety teams routinely publish advisories while remote operators remain on vulnerable versions. Dashboards may show that a patch exists without proving installation. Messages may describe risk qualitatively without stating a deadline or affected state. Dhahran demonstrates why last-mile evidence matters.

The deepest lesson is that time must be governed as data. Its unit, precision, epoch, maximum value, reset behavior and conversion path are interface requirements. Uptime is an input to the safety case. If error grows with time, every operating hour consumes margin.

Questions for Oversight and Leadership

Leaders responsible for high-consequence software should be able to answer a compact set of questions.

What is the longest credible continuous runtime, and has the system been tested beyond it? Which calculations accumulate error with elapsed time? What physical or service effect follows from the worst-case error? Where is the maximum safe duration documented?

Who receives anomaly data from the field, and who decides whether it changes the operating envelope? When a hazard is confirmed, who owns the interim mitigation while a permanent fix is developed? Can that person order a restart or service interruption?

Does a warning contain a measurable threshold, affected versions and required action? Does acknowledgment report the unit’s actual state? Is there evidence that the action occurred?

Can leadership identify every deployed configuration, current uptime and update status? How long does corrective software take to reach the most remote site? Is distribution priority tied to exposure?

What evidence is collected during operation? Has instrumentation been tested for non-interference? If direct recording is unsafe, what alternative supports anomaly detection and independent reconstruction?

Who independently verifies not only the code change but also the field closure? What condition changes the status from “fix released” to “risk removed”?

These questions turn a famous software story into an accountable operating model. They ask for artifacts, owners and thresholds rather than confidence statements.

Conclusion

The Patriot failure at Dhahran was caused by a software timing problem, but “rounding error” is too small a description of the institutional failure. Limited precision created an error that grew with uptime. Changed deployment conditions pushed the system far beyond the operating duration assumed by officials. Field data exposed the degradation. A software correction was released, and a warning was sent, but the warning lacked a usable time threshold and the corrected version arrived at Dhahran after the attack.

GAO’s record supports a disciplined allocation of responsibility. Engineering owned the numeric behavior and its verification. The project office owned anomaly conversion, warning and correction. Operational leadership owned doctrine and visibility into continuous use. Logistics owned delivery of the changed configuration. Deployed units needed explicit authority and instructions for mitigation. Senior leadership owned the evidence system connecting those controls.

The durable lesson is not that computers must avoid approximation. It is that organizations must bound approximation under the conditions that matter. Elapsed time, software version, warning receipt and corrective action must become visible control entities. In a system protecting human life, a safety limit cannot remain hidden in the binary expansion of a fraction.

Patriot made clock drift a battlefield-software accountability test