Most interfaces get a second chance. Run the bus wrong at integration, find it, fix it, run it again. A separation bolt fires once, a deployment hinge swings once, and the interface between a landing leg and the flight software reading it executes exactly one time, in the only configuration that ever mattered.
Every program has a list of these. Fairing separation. Spacecraft separation from the adapter. Solar array release. Antenna boom extension. Propulsion priming. First RF acquisition. The list is short, everyone on the program knows what's on it, and almost every item is treated as a mechanism problem: a release device, a hinge, a damper, a pyro. It goes to the mechanisms team, gets qualified, and comes back with a report showing twenty clean actuations.
What comes back is a qualified mechanism. What nobody produced is a verified interface.
Qualification tests the mechanism. The interface is someone else's problem.
A deployment qualification test runs on a qualification article, hung in a zero-gravity offload rig, released by a test controller, instrumented by a data acquisition system that is not the flight avionics. The mechanism actuates. Strain gauges and high-speed video confirm it. The report is honest, and it is a report about a hinge.
Meanwhile the flight software holds a state machine that consumes a discrete from that mechanism. During integration the discrete gets exercised by a breakout box. Someone closes a relay, the software sees the bit, the state machine advances, and the interface verification matrix gets a signature. The discrete was tested. What was never tested is the discrete as the mechanism actually produces it: a real sensor on a real harness during a real actuation.
The Mars Polar Lander review found exactly this gap, and then found something worse. A systems test existed that could have caught the loss. The touchdown sensors were incorrectly wired for that test because of a design error, so the test saw nothing unusual. The wiring was corrected afterward. The test was never repeated.
One-shot interfaces carry the most state nobody wrote down
Mars Polar Lander's landing legs deployed at roughly 1,500 metres. The Hall-effect sensors on those legs saw the same hyperextension at deployment that they would see at touchdown, and produced a transient indistinguishable from the real event. Someone had anticipated this. The system requirement said the flight software must not use touchdown data above 40 metres, written precisely to protect against failed sensors and transients.
The requirement stopped there. It never said what to do with a transient that arrives before the gate opens. The Touchdown Monitor needed two consecutive positive readings to declare touchdown. It got them at 1,500 metres and stored the result in a variable. At 40 metres the gate opened onto a bit that had been true for a minute. The descent engines shut down and the lander fell.
Nothing in that interface was wrong in the static sense. Signal name, source, type, sense, debounce depth: defined, reviewed, correct. What the interface never carried was its own behaviour during the one event both sides knew was coming.
A qualification test proves the hinge swings. It says nothing about the software watching it swing.
An interface definition that takes one-shot events seriously has to say more than what the field means:
The first five fields appear in every ICD on every program. The last three are the ones that decide whether the spacecraft lands.
The failure was not imagination. It was opportunity.
There is a familiar argument that losses like this come from nobody thinking of the failure mode. That argument doesn't fit here. Somebody thought of it. The 40-metre gate exists in the requirements because an engineer sat down and reasoned about spurious touchdown signals during descent. The idea made it into the document, into the review, into the design.
What was missing was any way to run it. A breakout box cannot produce the transient, because a breakout box does not model the electrical behaviour of a Hall-effect sensor on a hyperextending joint. The deployment qualification test cannot produce it either, because that test does not include the flight software. Exactly one rig could produce it, exactly once, and that rig was miswired.
Anywhere else on the program that would have been survivable. You find it at AIT, or in thermal vacuum, or during the day-in-the-life run, or in the first week of commissioning. One-shot interfaces have none of those phases downstream of them. The first execution is the last, and it happens 1,500 metres above the Martian south pole.
What it looks like when a program takes this seriously
JWST launched with 344 single-point failures on the books, and roughly 80 percent of them sat in the post-launch deployment sequence. The primary mirror alone carried 178 release devices. The full sequence ran on about 140 release mechanisms, 70 hinge assemblies, eight motors, 400 pulleys, and a quarter mile of cable, a million miles from anyone who could reach it.
What Webb's team did about that is worth copying, and most of it isn't a budget line. The deployment was built as a commandable procedure the ground could pause, hold, and resume, step by step, and it was rehearsed until the sequence itself was the article under test, not just the hardware inside it. The team took an event that happens once and turned it into something they could run again.
That move is available to programs operating on a fraction of Webb's budget, because it is a modelling decision before it is a hardware decision. Model the sensor's transient, not just its steady-state value. Run the real flight software against that model, through the real deployment timeline, in the real system modes. Then run it again with the transient one sample longer, with the sensor stuck high, with the altitude gate opening early. Each of those runs costs minutes. The rig costs one wiring error.
So the interface definition has to change, in what it holds and in where it lives. A signal exercised by a one-shot event needs its transient behaviour recorded in the same artefact as its type and its units, with the consumer's rule for that transient written beside it. That is not something a mechanisms team and a software team can each hold half of and reconcile by email. It has to be one definition, versioned, that both sides build from and that a simulation can execute, which is a different object from a PDF that both sides read.
Every program knows which of its interfaces run once. Those are the ones we test least, because there's no bench where they can fail cheaply. Building that bench in software is not extra rigour. It is the only rehearsal those interfaces will ever get.
images:
filename: TO BE SOURCED - solar-array-offload-rig.jpg
alt: A spacecraft solar array held partly open on a zero-gravity offload rig during a ground deployment test.
caption: A deployment qualification test proves the mechanism. The flight software is usually not in the room.
source: TO BE SOURCED (NASA/ESA image libraries carry suitable public-domain deployment-test photography)filename: TO BE SOURCED - mars-polar-lander-legs.jpg
alt: Mars Polar Lander in the clean room with its three landing legs stowed against the body.
caption: The Hall-effect sensors on those legs could not tell deployment from touchdown.
source: TO BE SOURCED (NASA/JPL image library)
