Defense Made Open Interfaces the Law. Space Made Them Optional.
In 2019, open interfaces became a legal requirement for major U.S. defense programs. A fighter's mission computer now has to accept a new radar the way a laptop accepts a new monitor: through a published, standards-based interface a competitor is allowed to build against. Commercial space, which slips more programs at integration than at any other phase, still treats that same discipline as a favor one vendor does for another.
The gap has little to do with budgets or talent. It comes down to whether the interface between two boxes is a governed object with rules, or a private arrangement two engineers reach over email and rediscover, in the clean room, the week the hardware arrives. Defense picked the first answer and wrote it into statute. Most of the space supply chain is still living with the second.
A law, not a best practice
The Modular Open Systems Approach is not a whitepaper. Section 805 of the FY2017 National Defense Authorization Act made it binding, and it took effect for major defense acquisition programs in January 2019. The FY2021 NDAA widened the requirement to reach all defense acquisition programs. The statute, codified in Title 10, tells programs to design systems with modular components and "major system interfaces," and to make those interfaces conform to widely accepted, consensus-based standards.
The law does not ask a program to document its interfaces well. It asks the program to define them as standard, published boundaries that a component can be added, removed, or replaced across, for the life of the platform. A radar, a mission computer, an electronic-warfare box: each is expected to meet an interface someone else could design to. The interface is the deliverable. The box is the thing that happens to satisfy it.
Space, by contrast, has standards for the physical layer and almost nothing above it. MIL-STD-1553 tells you how bits move on the bus. It does not tell you what the attitude-control vendor means by "quaternion," in what order, in what frame, updated how often. Two vendors settle that agreement per program, per pair, in a document, and the document is where the trouble starts.
What "optional" costs on the floor
A satellite prime today manages somewhere between eighty and three hundred interface control documents. Each one is a treaty between two companies, and most of them live as PDFs and spreadsheets that were correct on the day they were signed. A comms vendor and a guidance vendor agree on a telemetry frame in a call, transcribe it into two separate documents, and go build for six months. Neither document is wrong, exactly. They just drift: a field widens here, an endianness assumption flips there, a unit stays in degrees on one side and becomes radians on the other.
You find out at integration. The boxes are in the same room, the schedule is already tight, and a mismatch that would have taken a morning to resolve in design now costs weeks, because fixing it means touching flight hardware and re-running qualification. This is the moment every program manager dreads and every integration engineer has lived. We have sat in that room. It is not caused by bad engineers. It is caused by treating the interface as documentation rather than as a contract with teeth.
An open interface is not a courtesy to your integrator. It is the clause that lets them replace you, which is why it makes the whole program faster.
An interface standard is a market, not a constraint
The space industry keeps getting this backward. Defense did not mandate open interfaces because open is tidier. It mandated them to break vendor lock-in. If the interface to the radar is standard and published, the government can buy the next radar from a second source and bolt it on. The interface is a market mechanism. It turns a sole-supplier box into a competitive one.
The closed interface does the opposite, and it usually protects the incumbent rather than the mission. When only the original vendor understands how their box really talks, the integrator is captured. Every change is a negotiation, every replacement is a redesign, and the program pays a tax on its own inflexibility. Space has convinced itself that guarded interfaces protect intellectual property. Mostly they protect margins, and they do it by making the whole spacecraft harder to assemble.
For component builders, the open interface is the competitive move, not the vulnerable one. The vendor who ships a clean, verifiable interface is the vendor an integrator can design in without fear, and design in again on the next bus, and the one after that.
You can't mandate what you can't verify
There is a reason space can't simply copy the statute and move on. A law that says "conform to a consensus-based standard" is only as strong as your ability to check conformance. Defense can lean on decades of interface standards and a verification culture built around them. If your interface lives in a document, conformance is a review meeting: someone reads the PDF, someone else nods, and both sides hope their code matches what they signed.
Hope is not a verification method. The reason software stopped shipping interface bugs at this rate is that its interfaces became executable. An API contract is a schema a machine can check, on every commit, before the two systems ever meet. The equivalent for a spacecraft is an interface defined in code, from which the document, the message definitions, and the simulation model are generated, so that "does this box conform" becomes a test that runs automatically, not a conversation that happens once. Mandate an interface you can only inspect by hand, and you have written an aspiration. Mandate one that a simulation checks on every change, and you have written a rule.
What changes if you accept this
If open interfaces are a market mechanism, and if verification is the thing that makes them real, then the space industry's ICD problem was never a documentation problem. A better template, a shared drive, a stricter naming convention: none of it touches the actual defect, which is that the interface is neither a contract with consequences nor a test that can fail. Defense fixed the first half with a statute. The second half, the verification half, is available to any program willing to move its interfaces out of documents and into code.
The space supply chain likes to say it holds itself to a higher standard than ordinary software because the consequences are higher. On integration, that claim inverts. Software made its interfaces executable and checkable a decade ago; space still negotiates each one by hand and discovers the disagreements when the hardware is already on the bench. The Pentagon decided a handshake was not good enough and made the interface the law. The rest of the industry is still waiting for a reason it can't argue with, and integration keeps supplying one, program after program.




