Every Reused Module Is Untested Until You Run It Against the New Envelope

Mostafa Dhouib·September 3, 2026·6 min read

Every Reused Module Is Untested Until You Run It Against the New Envelope

The short answer. A module's test record is a statement about the environment it ran in, not about the module. Reuse moves the code and leaves the evidence behind. Ariane 5 lost a launcher to a conversion that was safe within Ariane 4's range, and the Therac-25 reused code whose hardware interlock assumption had been removed.

The claim

A reused module carries a correctness argument, and that argument is scoped to the environment it was verified in.

Reuse moves the code. It does not move the argument. What arrives in the new system is the code plus a feeling, and the feeling is the accumulated confidence of everyone who watched it work somewhere else.

The uncomfortable reach of this is that it applies to everything anybody has ever called battle-tested. A library that has served ten million requests has been verified against the distribution of those ten million requests. A model that ran for a year in one plant was verified against that plant's inputs. A driver proven on one board revision is unproven on the next. In every case the confidence is real, transferable to nothing in particular, and least likely to be re-examined at the exact moment of transfer, because that is when it feels safest.

The numeric envelope: Ariane 5

The inertial reference module was reused unchanged from Ariane 4, where it had a flawless record. Inside it, a 64 bit floating point horizontal bias value was converted to a 16 bit signed integer.

Ariane 5's flight profile produced horizontal velocity values roughly five times larger. The value exceeded 32,767, the conversion raised an unhandled Operand Error, and both the active and the backup unit went down within microseconds of each other, because they were the same software processing the same data.

The Inquiry Board's finding is the sentence for this post: the code was used with no specific verification for Ariane 5.

One test, driving the module with the actual Ariane 5 trajectory, forces the overflow on the ground. The trajectory was not a secret. Somebody had computed it in order to build the rocket.

The architectural envelope: Therac-25

The harder version, because there is no number to compare.

The Therac-25 removed the independent hardware interlocks present on the Therac-20 and Therac-6, and reused software from those machines. That software had been written under an assumption: if it commanded an unsafe configuration, hardware would refuse.

The assumption was not in a variable or a range. It was in the architecture, and it had never been written down as an assumption, because to the people who built the earlier machines it was not an assumption. It was how the machine worked.

So the code did not change, nothing in it looked wrong, and a review of it would have found nothing. What changed was the environment its correctness depended on. Six overdoses, three deaths.

Frame this case as the reports do: a system safety and institutional failure, not a missing unit test. The transferable part is narrower and still important, which is that removing a protection silently invalidates every piece of software that assumed it.

What re-verification actually means

Smaller than it sounds, and almost never done.

Write down the envelope it was verified against. Input ranges, rates, timing assumptions, what the surrounding system guarantees it, and what it assumes about the hardware underneath. This document usually does not exist, and its absence is itself the first finding.

Compare it to the new system's envelope, item by item. The gaps are your test list. Ariane's gap was one row: horizontal velocity, roughly five times larger.

Drive the boundaries on the ground. Not the nominal case, which a demonstration already covers. The edges of the new envelope, which nothing covers.

Hunt specifically for assumptions about things that were removed rather than changed. A range that grew is visible if you look for it. A guarantee that another part of the system used to provide, and no longer does, is invisible in the code because it was never written there. That is the Therac-25 class and it is the one that kills.

Delete code that has no purpose here. Ariane's alignment function served no purpose after liftoff on Ariane 5. It was still running, still consuming the processor budget that had motivated leaving the overflow check out, and still holding the fault, for a requirement belonging to a different vehicle.

A note on the last two: property based testing expresses envelope assumptions naturally, because a range is a property rather than an example. If you can state the envelope, you can usually test it.

Where this shows up commercially

Reused code not re-verified to the new envelope is a named red flag in technical due diligence, and it reprices deals. A diligence engineer will ask which modules came from another system and what envelope they were verified against, and the common answer, that it has been running for years, is the wrong shape of answer.

It is also the most frequent form of the "it worked before" objection in an engineering argument. The reply is short: it worked there.

The general argument is in a test that has never failed is a decoration, the two cases in Ariane 5 and Therac-25, and the commercial framing in your test suite is a diligence asset.

FAQ

Is reused code already tested? Its record is evidence about the environment it ran in, not about the module. Moving it to a new system with different inputs, timing or guarantees leaves that evidence behind.

What went wrong when Ariane 5 reused Ariane 4 code? A conversion to a 16 bit signed integer that was safe within Ariane 4's horizontal velocity range overflowed on Ariane 5's roughly five times larger values, and the Board found the code was used with no specific verification for Ariane 5.

How do I re-verify a reused module? Write down the envelope it was verified against, compare it to the new system's item by item, and drive the boundaries of the new envelope on the ground. The gaps between the two are the test list.

What kind of assumption is hardest to catch? An architectural one about a guarantee another part of the system used to provide. It is invisible in the code because it was never written there, which is how the Therac-25 reused software that assumed hardware interlocks it no longer had.

Does this matter commercially? Yes. Reused code not re-verified to the new envelope is a named technical due diligence red flag, and "it has been running for years" is the wrong shape of answer to it.