Put the interface in one schema that both sides build against, and you have solved the easy half of the problem. The hard half arrives the first time someone has to change that schema, eighteen months into a program, with four vendors already generating code against the version they were handed. A shared source of truth does not tell you who breaks when it moves.
We have spent a lot of words arguing that the interface belongs in code. The message definition, the telemetry layout, the command dictionary, all of it in a schema that lives in version control and generates the documents instead of the other way around. Teams that adopt this stop losing weeks to ICDs that no longer match the firmware. Then the program runs long enough for the schema to change, and a second problem surfaces that the first fix never touched.
A real interface is not written once. The power team finds it needs two more bits of telemetry. A late thermal requirement adds a field. A vendor discovers their scale factor was wrong in the third decimal place. On a program that spans years and a dozen suppliers, the schema is edited hundreds of times, and most of those edits are made by someone who cannot see every system that reads the result.
A change board is not a build
Aerospace already has a process for changing an interface. It is the configuration control board: an engineering change request is filed, a board reviews it, the affected parties are notified, and the ICD is reissued at a new revision. The machinery is thorough and it is slow, and it produces a document, not a verdict. The board confirms that the interface changed. It says nothing about the fault-management software two vendors away that parsed the old field width and will keep doing so until someone reads revision G and connects it to their own code.
The gap is between announcing a change and proving who it breaks. A board operates on paper and in meetings. The breakage operates in running code on benches in four buildings. The notification reaches a distribution list; the consequence reaches a parser nobody on the board has ever opened.
Software changes interfaces with versions, not meetings
The rest of software hit this problem a decade ago and answered it with versioning. Semantic versioning is a contract: a change to the first number means I broke something you depend on, a change to the last means I did not. Protocol buffers push the discipline into the format itself. You never reuse a field number and you never change a field's type. You add new numbered fields and mark the retired ones reserved, so a consumer built against last year's schema keeps working against this year's.
Consumer-driven contract testing goes one step further. Tools like Pact let every consumer of an interface publish the subset it relies on, and the producer's build fails if a change would violate any registered consumer. The producer learns at commit time, not at integration, that widening a field orphaned a team downstream. That is the capability a configuration control board cannot offer, because the board has no executable record of who reads what.
A change board tells you the interface moved. It cannot tell you who fell off.
The breaking change is the one you can't see from your side
Take the smallsat case we keep coming back to. The power team widens a battery-telemetry field from eight bits to sixteen and updates its own decoder the same afternoon. From inside their repository the change is clean and their tests pass. The same edit is additive to them and breaking to the fault-management team, who allocated two bytes for two fields and now read one. Whether an edit is safe or breaking is not a property of the edit. It is a property of who consumes the field, and that's the information a schema sitting in a repository doesn't carry on its own.
This is why generating the ICD from code, by itself, is half an answer. A clean generated document still describes one side's view of the interface at one moment. It says nothing about the set of systems bound to the previous version. Until the schema knows its consumers, every change is a guess about blast radius, and the guess is made by the one person least able to see the whole graph.
Reuse is a version change nobody recorded
The most expensive interface change is the one no one believed they were making. On 4 June 1996, Ariane 5 flight 501 reused an inertial reference platform and its software from Ariane 4. The inherited code carried an assumption about horizontal velocity that held on the slower vehicle and failed on the faster one. The value overflowed a 16-bit conversion, both inertial units shut down within milliseconds, the guidance computer read their diagnostic output as flight data, and the rocket tore itself apart thirty-seven seconds after launch.
No one edited that interface. That was the trap. The team inherited the flight software intact because reuse felt safer than a rewrite, and no one revalidated the inherited contract against the new vehicle it now described. Reusing a component across a program boundary is a version change to its interface, whether or not a single line moves. Treat it as less than that and the revalidation that should have failed on a bench fails on the pad instead.
The discipline already has the formats it needs
None of this asks for a new standard. The formats exist, from XTCE for telemetry to the message tables on a MIL-STD-1553 bus. What a program has to add is the habit of treating the schema as a versioned artifact with registered consumers. Classify each change as additive or breaking by who reads the field. Fail the build when a breaking change lands without the downstream side acknowledging it. Keep a deprecation window so a field retires on a schedule rather than in an incident. The board can still meet. It should be ratifying a result the build already produced, instead of mailing a document and hoping someone acts on it.
Treat interface change as a versioned contract and the integration calendar stops absorbing surprises. The breaking edit shows up as a red build the week it is made, owned by the engineer who made it, with the affected consumer named in the failure. The discovery that used to wait for two boxes to meet on a bench happens while the change is still cheap to reverse. The change board stops being the place interface risk is managed and becomes the place it is recorded.
We told you to put the interface in code. That was the easy advice. The harder discipline is admitting that an interface is never finished, that every program will change it under schedule pressure with half the consumers out of view, and that the moment of change is exactly when a static document protects no one. The schema is not the deliverable. The schema, plus a build that breaks the instant someone violates it, is the deliverable.
