The code that destroyed Ariane 5 Flight 501 was not wrong. It did exactly what it was written to do. The failure was one level up — in a requirement nobody re-examined, because the module carrying it was labelled "reused," and reused code, the assumption went, doesn't need reviewing again.
Thirty-seven seconds
On 4 June 1996, the European Space Agency's Ariane 5 rocket self-destructed 37 seconds after liftoff on its maiden flight, taking four uninsured Cluster scientific satellites with it — a loss of roughly $370 million. The Inertial Reference System (SRI) software, inherited largely unchanged from the earlier Ariane 4, converted a 64-bit floating-point value representing horizontal velocity into a 16-bit signed integer. Ariane 5's flight profile produced a horizontal velocity value larger than that variable's valid range. The conversion overflowed. The resulting exception was unhandled, both of the (redundant) inertial reference units shut themselves down, and the launcher's guidance system received diagnostic data that it interpreted as valid flight data — commanding an extreme correction that broke the vehicle apart.
The independent inquiry board, chaired by Jacques-Louis Lions and reporting within weeks, traced the fault to its actual origin: the range limit on that variable had been derived from Ariane 4's flight trajectory. Nobody re-verified it against Ariane 5's different, faster-accelerating profile, because the module was carried over as heritage software rather than re-engineered as a new requirement.
What the inquiry board actually foundThe function that failed was not even needed after liftoff on Ariane 5 — it kept running for reasons specific to Ariane 4's launch sequence. Nobody had asked, for the new vehicle, whether that assumption still held.
Reuse is a requirements decision, not a coding shortcut
This is the case people reach for when they say "the code was correct." It was — against the requirement it was written to satisfy. What never happened was requirement engineering for the new context: nobody asked whether Ariane 5's flight envelope still fit inside the assumptions Ariane 4 had established, because reused code inherited a lower level of scrutiny than new code, by convention rather than by any documented risk assessment.
That gap is exactly where most requirement management tools stop being useful. They track that a requirement exists, that it links to a test case, that it's been marked "reviewed." None of that catches an assumption that was valid for a previous system and silently stopped being valid for this one — because nobody re-engineered the requirement, they just re-used the artifact that satisfied it.
Management tracks it. Engineering questions it.
Real requirement engineering means every requirement — new or inherited — is actively decomposed, its assumptions made explicit, and its fitness for the current system checked, not assumed from its pedigree. That is a different job from requirement management, and it's the distinction that mattered on 4 June 1996: not that a requirement existed, but that nobody engineered it for the vehicle it was actually flying on.
It's also, not coincidentally, the gap PES is built to close — AI-assisted review that flags exactly this pattern: a requirement whose range, assumption, or context doesn't match the system it's now attached to, surfaced before flight, not after.
