Risk

A Large Margin of Safety

The backup failed first

Take any decision that matters and follow it along its chain:

1. Governancewho decides
2. Riskwhat could go wrong, and what it would cost
3. Compliancewhat must be true
4. Resiliencewhat all three amount to when the thing actually happens

So work a real one through. The example below is thirty-nine seconds in June 1996 — a good one because the organisation was serious, the engineers were competent, the reviews were extensive, and none of that was the point.

The European Space Agency had a programme with named bodies, a decision structure and an inquiry board it could convene within days of needing one — governance. The chain does not get past the second link.

Thirty-nine seconds

On 4 June 1996, Ariane 5 lifted off on its first flight. Thirty-nine seconds later, at an altitude of about four kilometres, it veered off its path, broke up and exploded.

Inside were two inertial reference units, the instruments that tell a rocket which way it is pointing. Two of them, because one might fail: identical hardware, identical software, one active and one on hot standby. That is what redundancy means.

The active unit struck a number it could not hold — a horizontal velocity too large for the sixteen bits allotted to it — and shut itself down, which is what it had been built to do on detecting a fault. The onboard computer reached for the backup.

The backup had died seventy-two milliseconds earlier. Same number. Same conversion. Same result.

Two copies of one assumption

This is the part worth sitting with, because it is not a software story. Two units is not two chances. Two units running the same software on the same inputs is one chance, bought twice — and the price of the second one bought nothing at all.

Redundancy protects against a component failing. It protects against nothing that both components share: not a shared assumption, not a shared supplier, not a shared power feed, not a shared belief about what the numbers could be.

The risk was not missed. It was assessed

The variable that overflowed had been looked at. Seven were examined; four were given protection; three were left unprotected — including this one — because, in the inquiry board's words, further reasoning indicated that they were either physically limited or that there was a large margin of safety, a reasoning which in the case of the variable BH turned out to be faulty.

The reasoning was not careless. On Ariane 4, that value could not get large enough to overflow. The rocket did not fly that way. The margin of safety was real, and it was a property of Ariane 4's trajectory — not of the code, and not of the instrument.

Ariane 5 flew a different trajectory. The code came across; the reasoning stayed behind.

And there is a sentence in the report that should stop any governance professional where they stand. On the trajectory figures that would have shown the difference:

Agreed. Jointly. By competent people, for reasons that were legible at the time. The data that would have revealed the risk was scoped out of the specification — and once it is out of the specification, it is out of everything downstream, because everything downstream tests against the specification.

Why the third link could not catch it

The inquiry found that the reviews and tests carried out across the Ariane 5 programme were extensive. They did not include an adequate test of the inertial reference system against the actual flight profile. There was no conspiracy in that and no corner cut: compliance checks that what must be true is true, and the specification is what says what must be true.

So a risk that has been excluded from the specification is invisible to every control that follows it. It will not appear in testing, it will not appear in review, and it will not appear on a register — and the whole apparatus will report green, accurately, right up until the thing flies.

One more detail, because it is the one people find hardest to believe. The function that was still running, and that computed the doomed value, had no job to do after lift-off. It served a purpose in Ariane 4's launch preparation, allowing a countdown to be restarted quickly. On Ariane 5 it was maintained for commonality reasons, and it computes meaningful results only before lift-off. It was working perfectly. It was doing a job nobody needed, and it was the last thing that worked.

The keep

• A risk assessment has a scope, and the scope does not travel with the component. Reuse carries the code; it leaves the reasoning behind.
• Redundancy that shares a cause is not redundancy. Two of a thing is one chance if both copies share an assumption.
• A risk scoped out of the specification is invisible to every control downstream of it — and the dashboard will be green, correctly.
• “It was jointly agreed not to include” is what an excluded risk looks like at the time. It never looks like negligence. It looks like a sensible scoping decision taken by people under pressure.
• Something can be working perfectly and still be the thing that kills you. Ask what each part is for, not whether it functions.

First move: take one thing in your estate that you did not choose — inherited, reused, bought along with something else, or carried over from the last system — and go and find the assessment that justified it. Then check what that assessment was assessing. If it was assessing a different system, you have just found an assumption that nobody currently owns.

Sources

All quoted phrases are from the ARIANE 5 Flight 501 Failure — Report by the Inquiry Board (Paris, 19 July 1996), chaired by Professor Jacques-Louis Lions. The flight sequence, the altitude and the Board's summary findings: ESA, Ariane 501 — Presentation of Inquiry Board report. No cost figure is quoted here because none was verified. Checked 20 September 2026.

‹ The Second Opinion