Correct Interfaces Do Not Make a Correct System
Apollo 11 nearly waved off its own landing over a computer alarm — and every interface on the spacecraft was behaving exactly as specified. The rendezvous radar talked to the guidance computer in precisely the language its interface promised. The system still almost failed, because a correct interface between two boxes tells you nothing about how twenty boxes behave when you switch them all on at once.
We build tooling for interfaces, so it is worth saying plainly: a program can define every interface perfectly and still lose the vehicle at integration. Correct interfaces are necessary. They are not sufficient. The bugs that survive good ICD discipline are the ones that live between the interfaces — in the shared resources and the operational timeline, where no pairwise check ever looks.
The 1202 alarm was not an interface bug
Six minutes into powered descent, the lunar module's guidance computer flashed a 1202 program alarm, then a 1201. Both meant the same thing: the executive had run out of room to schedule its work. In Houston, Jack Garman — backing up guidance officer Steve Bales — had these codes on a handwritten list, judged them the recoverable kind, and the landing continued.
The cause was not a broken interface. The rendezvous radar had been left in a mode that fed its angle data to the Apollo Guidance Computer during descent, when the AGC had no use for it. A subtle phase difference between the power supplies feeding the radar and its coupling data units made those units count continuously, firing spurious interrupts that stole roughly an eighth of the computer's cycles. Every component met its spec. The radar produced valid angles. The coupling data units incremented valid counts. The AGC scheduled valid jobs. Composed under one specific switch configuration, those correct behaviors summed to more work than the machine could hold.
What saved the landing was not interface verification. It was margin — an asynchronous, priority-driven executive built so that when the computer was swamped, it shed the low-priority jobs, restarted, and kept flying guidance. The interface was fine the whole time. The system was one checklist item away from an abort.
A correct interface between two boxes tells you nothing about how twenty boxes behave when you power them all on at once.
Pairwise verification is blind to what components share
An ICD is a contract between two parties. It states what producer A emits and what consumer B expects, and if both honor it, that seam is sound. Verify every seam and you have proven that each pair agrees. You have proven nothing about what the pairs share.
Subsystems on a spacecraft do not interact only through their declared interfaces. They share a MIL-STD-1553 bus with finite bandwidth and a fixed major/minor frame schedule. They share a power bus that sags when three loads switch on together. They share a processor, a thermal path, a clock. None of these shared resources appears in any single ICD, because they belong to no single interface. Two components can each stay inside their 1553 message budget and still, together, overrun the frame. The ICD for each is green. The bus is red.
This is the failure mode that survives a disciplined interface process, and it is precisely the one teams keep meeting at integration — not because their ICDs were sloppy, but because ICDs were never the right instrument for it.
The failure lives in the scenario, not the schematic
The Apollo radar bug needed three things at once: a particular switch position, a particular phase relationship, and the workload of a live descent. Remove any one and the alarm never fires. That is the signature of an emergent failure — it exists only in a specific operational scenario, not in the static wiring.
You cannot find it by reading the schematic, because on paper everything is connected correctly. You cannot find it by testing interfaces one at a time, because each one passes. You can only find it by running the composed system through the scenario that provokes it: all subsystems live, on the real timeline, with the real switch positions and the real contention. The bug is a property of the whole in motion, and only the whole in motion reveals it.
The unit of verification is the system, not the interface
This is the uncomfortable part for anyone who sells interface tooling, us included. Getting the ICDs right raises the floor. It does not lift you out of integration risk, because the highest-consequence failures are compositional, and composition is not something you verify one contract at a time.
The instrument that catches compositional failure is software-in-the-loop simulation of the integrated system — every subsystem model running together, on the actual bus schedule, through the actual mission timeline, including the off-nominal switch positions no one meant to leave set. Run the descent with the rendezvous radar in the wrong mode and the processor load spikes in simulation, on a laptop, months before anyone stacks flight hardware. That is a cheap place to meet the 1202 alarm. The integration bench is an expensive one, and orbit is worse.
Most programs treat whole-system simulation as a late milestone, something you assemble once near the end. By then the architecture is frozen and the contention is baked in. Simulating the composed system earns its keep only when it runs continuously, from early in the program, as the routine way you ask a blunt question: if we turn everything on and fly the timeline, does the system hold?
What this changes
If you accept that correct interfaces do not compose into a correct system, then interface verification stops being the finish line and becomes the entry fee. The real question moves up a level — from "does each seam agree?" to "does the assembly behave when it runs as one thing?" That question has no pairwise answer. It has a simulation, and the simulation has to model the shared resources the ICDs leave out: the bus, the bus schedule, the power rail, the processor budget, the clock.
Apollo 11 landed with about an eighth of its computer wasted on a radar it wasn't using, and it landed because someone had built margin for exactly the failure no interface document could predict. Most programs will not have that margin, and will not have a Jack Garman with the right list. What they can have is the scenario, run early, in software, with everything switched on at once. Verify the interfaces. Then go find out what they do together.
