Ariane 5 and the Number Conversion That Destroyed a Rocket

What happened in the first 40 seconds

On June 4, 1996, the first Ariane 5 flight lifted off from Kourou. Ariane 5 was a new launcher, designed to carry heavier payloads than Ariane 4. New vehicle, new flight profile, new dynamics. But parts of the software—specifically within the inertial reference system (IRS)—were reused from Ariane 4.

About 37 seconds after liftoff, the IRS software hit a numeric overflow during a conversion from a floating-point value to an integer type that couldn’t represent the larger number. That overflow raised an exception. The exception wasn’t handled the way it needed to be for a live vehicle. The IRS computer shut down. Almost immediately the redundant IRS also failed in the same way, because it ran the same code with the same assumptions. Redundancy did what it was designed to do: it failed over to the exact same failure.

The guidance system, now missing valid attitude data, interpreted diagnostic data as if it were real flight data. The rocket sharply deviated from its intended trajectory. The structural loads skyrocketed. Range safety—seeing a vehicle no longer under control—triggered self-destruction. This part is not melodrama; it’s a safety boundary. When you’re launching over an inhabited planet, you do not get to “wait and see.”

Rockets don’t explode because they’re angry. They explode because we told them to, on purpose, to keep the blast radius from walking into places it shouldn’t.

Interesting facts and historical context

• Flight 501 was Ariane 5’s maiden flight, meaning there wasn’t a long operational history to hide behind—only simulations and assumptions.
• Ariane 5 used two inertial reference systems intended for redundancy, but both ran identical software and were exposed to the same input conditions.
• The failing variable represented a horizontal velocity-related value from alignment/attitude processing—valid for Ariane 4’s flight envelope, not for Ariane 5’s early trajectory.
• The exception occurred during a float-to-integer conversion where the integer type was too small to represent the value, causing an overflow.
• Some IRS functions were running after liftoff even though they weren’t needed for flight, because disabling them was considered risky or not worth changing.
• The guidance computer treated certain diagnostic words as data after the IRS failed, a classic “garbage in, hard turn out” scenario.
• Range safety destruction is a designed feature, not an accident—when guidance is lost and trajectory is unsafe, termination protects people on the ground.
• The incident became a landmark software engineering case study because the failure was deterministic, well-documented, and painfully avoidable.

The technical fault: one conversion, one overflow, two computers

Here’s the core of it, stripped of mythology: the IRS software attempted to convert a floating-point number into a 16-bit signed integer (or similarly constrained integer type in the implementation). The float value exceeded the maximum representable integer range. The runtime raised an overflow exception. That exception triggered a shutdown of the IRS computer. Once it’s down, it’s not providing attitude and velocity references. Guidance is now flying blind.

Why the conversion existed

In a lot of embedded guidance systems, you’ll see mixed numeric representations. Floating point is used for intermediate computations; integers are used for fixed-format messaging, storage, or performance. When systems were designed decades ago, memory and CPU cycles were precious. Even now, determinism matters: fixed-size integer fields in bus messages or telemetry frames are stable, testable, and easy to parse.

So the conversion itself isn’t suspicious. The suspicious part is the assumption embedded in it: “this value will always fit.” That was true under Ariane 4’s flight conditions. It wasn’t true for Ariane 5’s. Ariane 5’s early flight produced a larger horizontal velocity component than Ariane 4 ever did at the same time mark. Same code, new physics.

Why the exception handling was fatal

In safety-critical systems, exceptions are not “bugs,” they’re signals. An overflow is the software equivalent of a pressure relief valve screaming at you. You either handle it in a way that preserves safe behavior, or you let it crash the component and pray redundancy catches you.

They did handle some conversions with protection, because they were known to possibly overflow. But this one conversion wasn’t protected—because it wasn’t expected to overflow. That’s the trap: the most dangerous failures are the ones you “proved” cannot happen based on last year’s system.

What should have happened instead

In a perfect world, the conversion would have been guarded and saturating: clamp the value to min/max and set a status flag, or use a larger integer type, or keep it as float, or disable that computation after liftoff if it’s not needed. Pick one. Any one of these, implemented correctly, is vastly cheaper than rebuilding a rocket and explaining the crater to your stakeholders.

Here’s the dry-funny truth: computers are very literal employees. They don’t “kind of” overflow; they do it precisely and then leave without notice.

One quote to keep you honest: “Hope is not a strategy.” — General Gordon R. Sullivan

Why redundancy failed: the common-mode trap

Redundancy is not magic; it’s math. Two systems only improve reliability if their failure modes are independent enough. If both systems run the same software, same configuration, same numeric types, and see the same inputs at the same time, you haven’t built redundancy—you’ve built a synchronized failure.

This is called common-mode failure. It shows up everywhere: dual power feeds from the same breaker panel; two Kubernetes clusters sharing the same DNS provider; “active-active” databases that both deadlock under the same query pattern.

Ariane 5 had two IRS units. Both experienced the same overflow at about the same time. There was no graceful degradation, no “one unit switches to a reduced function mode,” no independent implementation, no heterogeneous numeric representation, no diversity that mattered.

Also: failover timing matters. If the redundant unit dies milliseconds after the primary, you didn’t fail over—you just added a delay so short it feels like a glitch in the logs.

Redundancy without diversity is a comfort blanket. It feels warm until the fire reaches it.

A systems view: requirements, validation, and “non-essential” code

The failure wasn’t “a bad cast.” It was a chain of decisions that made the cast fatal. Let’s diagnose the decision points.

1) Reuse without revalidation

Software reuse is good engineering. Blind reuse is gambling. Ariane 4 software was reused in Ariane 5, but the validation didn’t fully cover the new flight envelope. That’s the kind of shortcut that looks responsible in a project plan: fewer changes, fewer regressions, less risk.

Reality: fewer changes can mean less attention. The code becomes “trusted.” Trusted code is where bugs go to retire and then come back as ghosts.

2) Non-essential functions running in flight

Part of the failing computation belonged to alignment logic that wasn’t needed after liftoff. Yet it kept running. Why? Because turning it off required changes and retesting, and leaving it on seemed safe because “it worked before.”

This is an operational anti-pattern: letting non-critical background work run in a critical window because disabling it feels risky. In production systems we call it “harmless cron jobs” that become the loudest consumers during an outage. In rockets, you don’t get to SSH in and kill the process.

3) Exception handling policy that prioritized shutdown

There are cases where shutting down is safer than continuing. But shutdown must be designed as a safe state. For an inertial reference system feeding guidance, shutdown is not safe unless guidance has an alternate verified source and the protocol prevents misinterpretation of diagnostics as truth.

In operations, we say: failing fast is great when you can retry. In a rocket at T+37 seconds, you cannot retry. Your “restart” button is the insurance policy.

4) Verification that missed the real operational envelope

This is the part engineers hate because it’s not a single bug. It’s a mismatch between what was tested and what mattered. You can have thousands of test cases and still miss the one boundary that defines reality: “Can this variable ever exceed 32767?”

And yes, it’s boring. That’s why it kills systems.

Three corporate mini-stories you’ll recognize

Mini-story 1: The incident caused by a wrong assumption

A payments company ran a fleet of services that calculated fraud risk scores. The score was stored in a signed 16-bit integer because it “only needed to represent 0–10,000” when the system launched years earlier. The original model capped the score. Everyone forgot the cap was a cap and not a law of nature.

A new model shipped. It was better—higher recall, fewer false negatives. It also emitted scores above the old ceiling during certain holiday traffic patterns. A conversion deep in a shared library truncated or overflowed values, which then mapped to “ultra-low risk” due to a wraparound. The fraud system didn’t get noisier. It got quieter. That’s the worst kind of failure: the one that looks like success.

The incident lasted hours because the monitoring dashboards tracked average risk score and count of blocked payments. Averages didn’t move much. The tail exploded. It took someone looking at a raw histogram to see that a chunk of transactions had nonsensical negative scores.

Fix was simple: store risk as 32-bit, add explicit bounds checks, and validate model output ranges as part of deployment. The cultural fix was harder: stop treating “we’ve never seen that value” as a guarantee. In a living system, the future is where your assumptions go to die.

Mini-story 2: The optimization that backfired

A storage team “optimized” an ingest pipeline by switching from 64-bit timestamps to 32-bit seconds-since-epoch inside an index, because it cut memory and improved cache hit rate. Benchmarks looked great. The graphs went up and to the right. Promotions happened.

Then they expanded into a region where some devices emitted timestamps far in the future due to a firmware clock bug. Those timestamps overflowed the 32-bit representation. Records were indexed into nonsense time buckets. Queries for “last 15 minutes” occasionally pulled in future data, which the application treated as newest and therefore “most authoritative.” Users saw data teleporting across time.

It took days to unwind because data wasn’t corrupt in storage; it was corrupt in the index. Rebuilding the index required backfilling billions of rows. That meant throttling ingest, which meant falling behind, which meant executives staring at a “data freshness” SLA that suddenly meant something.

They reverted to 64-bit, added input validation, and implemented a quarantine path: records with out-of-range timestamps still landed, but were marked, isolated, and excluded from default queries. The lesson was blunt: optimization that changes numeric boundaries is not optimization; it’s redesign.

Mini-story 3: The boring but correct practice that saved the day

A mid-size SaaS provider ran a multi-tenant database with heavy batch jobs. Nothing exciting—until an upstream library upgrade changed a serialization format. Most teams discovered it in production with a bang.

This team didn’t. They had a painfully boring practice: every dependency bump triggered a replay test against a captured production traffic sample, and they stored “golden” artifacts for compatibility checking. The replay environment was not perfect, but it was faithful enough to catch boundary mismatches.

The test flagged a subtle issue: a numeric field previously serialized as 64-bit integer was now decoded as 32-bit in one consumer due to a schema ambiguity. Under normal ranges it worked. Under rare large values, it overflowed and tripped a retry loop. That retry loop would have become a thundering herd against the database.

They fixed the schema, pinned versions, and shipped. Nobody outside the team noticed. That’s the point. Reliability work is often invisible. If your reliability practice is glamorous, you’re probably doing incident response, not engineering.

Practical tasks: commands, outputs, and decisions

The Ariane 5 failure is a numeric boundary problem wrapped in a verification and operational discipline problem. Here are concrete tasks you can run in real systems to prevent the same class of failure. Each task includes: a command, sample output, what it means, and the decision you make.

1) Find integer narrowing conversions in C/C++ builds (compiler warnings)

cr0x@server:~$ make CFLAGS="-O2 -Wall -Wextra -Wconversion -Wsign-conversion" 2>&1 | head -n 8
src/nav.c:214:23: warning: conversion from ‘double’ to ‘int16_t’ may change value [-Wfloat-conversion]
src/nav.c:215:18: warning: conversion to ‘int16_t’ from ‘int’ may change the sign of the result [-Wsign-conversion]
...

Output meaning: The compiler is telling you exactly where you might overflow, truncate, or flip sign.

Decision: Treat these warnings as release blockers for safety or money-path code. Add explicit range checks or widen types. If you must narrow, document the bound and enforce it.

2) Hunt for risky casts in a repo (fast grep)

cr0x@server:~$ rg -n "(\(int16_t\)|\(short\)|\(int\))\s*\(" src include
src/irs/align.c:88:(int16_t)(h_velocity)
src/irs/align.c:131:(short)(bias_estimate)

Output meaning: Explicit casts are where intent and danger meet.

Decision: Review each cast: what range is expected, what happens when it’s exceeded, and whether it runs in a critical window.

3) Identify unhandled exceptions/crashes via systemd logs

cr0x@server:~$ journalctl -u navd --since "1 hour ago" | tail -n 12
Jan 22 10:11:04 stage navd[1827]: converting float to int16: value=40211.7
Jan 22 10:11:04 stage navd[1827]: FATAL: SIGABRT after overflow trap
Jan 22 10:11:04 stage systemd[1]: navd.service: Main process exited, code=killed, status=6/ABRT
Jan 22 10:11:04 stage systemd[1]: navd.service: Failed with result 'signal'.

Output meaning: A numeric conversion triggered a trap, taking down the service.

Decision: Decide whether the service should fail-stop or degrade. For critical control loops, design a safe mode; for stateless services, implement retries and circuit breakers.

4) Verify kernel/CPU traps for overflow-like crashes (core dump enabled)

cr0x@server:~$ coredumpctl list navd | tail -n 3
TIME                            PID   UID   GID SIG COREFILE  EXE
Jan 22 10:11:04                 1827  1001  1001  6 present   /usr/local/bin/navd

Output meaning: There is a core dump you can inspect instead of guessing.

Decision: Pull the core, identify the exact conversion and input range, and add a regression test for that boundary.

5) Measure whether your “redundant” services fail together (correlated failure)

cr0x@server:~$ awk '$3=="ERROR" {print $1,$2,$6}' /var/log/irs-a.log | tail -n 5
2026-01-22 10:11:04 overflow value=40211.7
2026-01-22 10:11:04 shutdown reason=exception

cr0x@server:~$ awk '$3=="ERROR" {print $1,$2,$6}' /var/log/irs-b.log | tail -n 5
2026-01-22 10:11:04 overflow value=40212.1
2026-01-22 10:11:04 shutdown reason=exception

Output meaning: Same timestamp, same reason: common-mode failure.

Decision: Introduce diversity: different implementations, different validation, different thresholds, or at least staggered behavior (one clamps, one alarms).

6) Validate numeric ranges at the boundary (runtime guardrails)

cr0x@server:~$ python3 - <<'PY'
import math
MAX_I16=32767
vals=[120.0, 32766.9, 40000.1]
for v in vals:
    ok = -MAX_I16-1 <= v <= MAX_I16
    print(f"value={v} fits_int16={ok}")
PY
value=120.0 fits_int16=True
value=32766.9 fits_int16=True
value=40000.1 fits_int16=False

Output meaning: You can detect overflow conditions before converting.

Decision: Enforce guards at interfaces: if out-of-range, clamp, drop, or route to a safe-mode path with alarms.

7) Confirm your telemetry isn’t “garbage interpreted as truth” (schema checks)

cr0x@server:~$ jq -r '.frame_type, .attitude.status, .attitude.roll' telemetry/latest.json
DIAGNOSTIC
FAIL
-1.7976931348623157e+308

Output meaning: A diagnostic frame is being parsed as an attitude frame, and a sentinel value is leaking through.

Decision: Make message types explicit and validated. Refuse to consume frames that don’t match the schema and state.

8) Spot saturation/clamping events (you want to see them)

cr0x@server:~$ grep -R "SATURAT" -n /var/log/navd.log | tail -n 5
41298:WARN SATURATION h_velocity=40211.7 clamped_to=32767
41302:WARN SATURATION h_velocity=39880.2 clamped_to=32767

Output meaning: The system encountered values outside expected range but stayed alive.

Decision: Investigate why the range is exceeded. Decide whether the clamp is acceptable or hiding a real modeling/physics change.

9) Validate that “non-essential” jobs are not running in the critical window

cr0x@server:~$ systemctl list-timers --all | head -n 12
NEXT                         LEFT     LAST                         PASSED    UNIT                         ACTIVATES
Wed 2026-01-22 10:12:00 UTC  32s      Wed 2026-01-22 10:07:00 UTC  4min ago  rotate-alignment.timer       rotate-alignment.service
Wed 2026-01-22 10:15:00 UTC  3min 32s Wed 2026-01-22 10:00:00 UTC  11min ago logrotate.timer             logrotate.service

Output meaning: Timers are firing during your critical period.

Decision: Disable or reschedule non-critical tasks during launch/peak windows. “Background” work is only background until it isn’t.

10) Confirm failover actually works under load (health and readiness)

cr0x@server:~$ kubectl get pods -n guidance -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP           NODE
irs-a-7c6b9f9c7b-2m8qk   1/1     Running   0          3d    10.42.1.12   node-1
irs-b-7c6b9f9c7b-q9d2p   1/1     Running   0          3d    10.42.2.19   node-2

cr0x@server:~$ kubectl describe svc irs -n guidance | sed -n '1,30p'
Name:              irs
Namespace:         guidance
Selector:          app=irs
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.43.128.10
Endpoints:         10.42.1.12:9000,10.42.2.19:9000

Output meaning: You have two endpoints, but this does not prove they fail independently.

Decision: Run chaos tests that inject the specific failure (overflow path) and verify the consumer rejects invalid data and continues safely.

11) Detect correlated restarts (a sign of common-mode)

cr0x@server:~$ kubectl get events -n guidance --sort-by=.lastTimestamp | tail -n 10
10m   Warning   BackOff     pod/irs-a-7c6b9f9c7b-2m8qk   Back-off restarting failed container
10m   Warning   BackOff     pod/irs-b-7c6b9f9c7b-q9d2p   Back-off restarting failed container
10m   Normal    Pulled      pod/irs-a-7c6b9f9c7b-2m8qk   Container image pulled
10m   Normal    Pulled      pod/irs-b-7c6b9f9c7b-q9d2p   Container image pulled

Output meaning: Both replicas are crashing for the same reason at the same time.

Decision: Stop assuming replicas equal resilience. Introduce independent versions, feature flags, or staggered rollouts with canaries.

12) Inspect numeric boundaries in message schemas (protobuf example)

cr0x@server:~$ rg -n "int32|int64|sint32|sint64|fixed32|fixed64" schemas/attitude.proto | head -n 20
12:  int32 roll_millirad = 1;
13:  int32 pitch_millirad = 2;
14:  int32 yaw_millirad = 3;
18:  int32 h_velocity_cm_s = 7;

Output meaning: You’re encoding velocity in int32 centimeters/second. Good. But you must confirm maximum values with margin.

Decision: Write down the max physically possible value (plus safety factor), then confirm the type can represent it across all mission modes.

13) Enforce property-based tests for numeric ranges (boundary fuzzing)

cr0x@server:~$ pytest -q tests/test_numeric_bounds.py -k "int16_guard"
1 passed, 0 failed, 0 skipped

Output meaning: You have automated coverage that tries values near and beyond boundaries.

Decision: Require these tests for any code that converts types or serializes telemetry/control words.

14) Verify that safe-mode behavior is reachable (feature flag / mode switch)

cr0x@server:~$ curl -s localhost:9000/status | jq
{
  "mode": "SAFE_DEGRADED",
  "reason": "overflow_guard_triggered",
  "attitude_valid": true,
  "velocity_valid": false
}

Output meaning: The component didn’t crash; it entered a degraded mode and clearly marked what’s valid.

Decision: Prefer explicit degradation over implicit failure. Make downstream consumers honor validity flags or refuse invalid fields.

Second short joke (and last one): If your range checks are “to be added later,” congratulations—you’ve invented a rocket-powered TODO list.

Fast diagnosis playbook

When a system suddenly veers into nonsense behavior—hard turns in control loops, garbage telemetry, cascading restarts—don’t start by rewriting code. Start by finding the bottleneck and the boundary. Here’s a practical triage order that works for rockets and web services.

1) Confirm the failure mode: crash, wrong output, or wrong interpretation

• Crash: processes exit, pods restart, systemd reports signals. Look for traps, aborts, exceptions.
• Wrong output: service stays up but emits impossible values (negative where impossible, NaNs, extreme floats).
• Wrong interpretation: consumer mis-parses frames or treats diagnostics as data.

2) Check for common-mode failure across redundancies

If primary and backup fail within seconds of each other, assume shared cause: shared binary, shared config, shared dependency, shared input pattern. Redundancy is not your root cause; it’s your clue.

3) Identify the boundary that changed

Ask: what value got bigger, smaller, or shifted units? New trajectory, new load, new customer tier, new model, new locale, new hardware. This is where Ariane 5 lived: a new flight envelope fed into old numeric assumptions.

4) Validate the data contract at interfaces

Most catastrophic failures happen between components: serialization, schema drift, unit mismatch, endian issues, or silent truncation. Confirm the message type and the numeric ranges at the boundary.

5) Only then optimize or refactor

Optimization tends to remove safety margin (smaller types, fewer checks, faster paths). During diagnosis, you want more observability and more checks, not fewer. Get it correct first; make it fast second; make it cheap third.

Common mistakes: symptom → root cause → fix

Symptom: “It worked in simulation, fails in production conditions”

Root cause: The simulated envelope didn’t include worst-case ranges (or used Ariane 4-like values).

Fix: Expand test vectors to include extreme but physically possible values; add property-based tests; require range proofs for any narrowing conversion.

Symptom: Both primary and backup fail almost simultaneously

Root cause: Common-mode failure: identical software/config seeing identical inputs.

Fix: Add diversity (different implementation or version), stagger behavior (one clamps, one shuts down), and validate failover under the specific failure injection.

Symptom: Downstream makes wild decisions after an upstream component fails

Root cause: Diagnostic or invalid data is interpreted as valid due to weak contracts.

Fix: Add explicit frame types and validity flags; reject invalid data; fail closed for control decisions; avoid “best effort” parsing in safety paths.

Symptom: “Non-essential” background task triggers incidents during critical windows

Root cause: Unnecessary computation still running in the critical phase, consuming CPU or hitting rare code paths.

Fix: Disable or gate non-essential tasks after state transitions; use mode-aware scheduling; prove that post-liftoff (or peak) code paths are minimal.

Symptom: A tiny code change causes massive instability

Root cause: You changed numeric representation, units, or saturation behavior; the system relied on undocumented assumptions.

Fix: Treat numeric type changes as interface changes. Version the contract. Add compatibility tests and traffic replays.

Symptom: Monitoring shows “normal averages” while reality is broken

Root cause: Tail failure (rare overflow) hidden by averages; missing histograms/percentiles.

Fix: Monitor distributions, not just means. Track min/max, percentiles, and count of clamped/invalid values.

Checklists / step-by-step plan

Checklist: Prevent numeric overflow failures in safety or money-path code

1. Inventory numeric conversions (float-to-int, int-to-smaller-int, unit conversions). If you can’t list them, you can’t control them.
2. Define expected ranges with margin for each value, including “new mission modes” (new vehicle, new region, new model, new customer class).
3. Make conversions explicit and guarded: range check, clamp/saturate, and log a structured event.
4. Standardize units in interfaces. If you must convert, do it once at the edge and record the unit in the schema.
5. Decide failure policy: crash, degrade, clamp, or reject. For control systems, prefer safe degradation with clear validity flags.
6. Test beyond the envelope: not just “max expected,” but “max plausible,” plus adversarial values (NaN, infinity, negative, huge).
7. Verify redundancy independence: different version, different compiler flags, different code path, or at least different behavior on overflow.
8. Require contract tests between producer and consumer, including schema, units, and value bounds.
9. Observe clamping: dashboards for “saturation events” and “invalid data rejected.” These should be near zero and investigated.
10. Run a game day that injects the exact overflow scenario and proves the system stays safe (not just “up”).

Checklist: Reuse code without importing old assumptions

1. List every reused module and its original operational envelope.
2. For each module, write down what changed in the new system (inputs, ranges, timing, units, performance).
3. Re-run verification against new envelopes; do not accept “already qualified” as an argument.
4. Delete or disable logic not needed in critical phases. Less code running means fewer surprises.
5. Document the rationale for any unprotected conversion: why it can’t overflow, and what enforces that.

FAQ

1) Was the Ariane 5 failure “just an integer overflow”?

No. The overflow was the trigger. The failure was systemic: reuse without revalidation, non-essential code running in flight, exception handling that shut down a critical component, and consumers misinterpreting invalid output.

2) Why didn’t the backup inertial reference system save the rocket?

Because it failed the same way, for the same reason, at the same time. That’s common-mode failure. Redundancy only helps when failures are sufficiently independent.

3) Why was a float-to-int conversion used at all?

Fixed-size integer fields are common for messaging, telemetry formats, and deterministic performance. The conversion is normal. The lack of a guard for out-of-range values is what made it dangerous.

4) Couldn’t they just “catch the exception” and continue?

They could have handled it, but “continue” must mean “continue safely.” Options include clamping with a validity flag, switching to a degraded mode, or disabling that computation post-liftoff.

5) Why did guidance respond so violently after the IRS failed?

Guidance needs attitude and rate information. When it received invalid data (or diagnostics treated as data), it computed incorrect control commands. In closed-loop control, bad inputs can produce aggressive outputs fast.

6) What’s the SRE lesson here?

Assumptions are production dependencies. If you reuse components, you must revalidate assumptions under new load patterns. Also: monitor for boundary events, not just uptime.

7) Is “fail fast” bad?

Fail fast is great when you can retry or route around the failure. In systems where you cannot retry (control systems, safety systems, irreversible actions), you need safe degradation and strict data validity rules.

8) How do I prevent “diagnostics interpreted as data” in distributed systems?

Use explicit message types, schema validation, versioned contracts, and defensive consumers that refuse to act on invalid or unexpected frames. Treat parsing errors as security-grade events.

9) Does adding more tests fix this class of problem?

Only if the tests include the right boundaries. Ten thousand “happy path” tests won’t catch one missing overflow guard. Focus on envelope tests, fuzzing near numeric limits, and contract tests across interfaces.

10) What’s the right kind of redundancy?

Redundancy with independence: different implementations, different versions, different compilers, different sensor modalities, or at least different failure behavior. If both sides share the same bug, you bought two tickets for one crash.

Next steps you should actually take

Ariane 5’s lesson isn’t “don’t make mistakes.” It’s “stop trusting assumptions that aren’t enforced.” A rocket is just a very expensive production deployment with fewer rollback options.

1. Inventory numeric conversions in your critical systems this week. If you don’t know where they are, you can’t defend them.
2. Turn on strict compiler warnings and make narrowing conversions a review gate.
3. Add runtime guards at interfaces: range checks, clamping with flags, or reject-with-alarm behavior.
4. Prove redundancy independence with failure injection. If both replicas die together, call it what it is: one system duplicated.
5. Kill non-essential work in critical windows. If it’s not needed after liftoff, don’t run it after liftoff.
6. Monitor distributions and boundary events (saturation counts, invalid frames rejected), not just averages and uptime.

Do those, and you won’t just avoid an Ariane 5 moment. You’ll also ship faster, sleep more, and spend fewer mornings explaining to leadership why the graphs looked fine while reality was on fire.