The ICD Stopped Being True When It Became a Deliverable
Ask an integration engineer where the interface actually lives and they will not point at the ICD. You get a header file, a spreadsheet with a date in the filename, and the name of someone at the vendor who answers email quickly. The ICD is still on the data requirements list, still signed, still under revision control, and it stopped describing the hardware a long time ago.
The usual explanation is discipline. Someone was lazy, someone skipped a step, the program was busy. We've heard that in a dozen post-mortems and we no longer believe it. The people on these programs are careful, and they're careful about everything else on the same program. The ICD is not stale because nobody cares about it. It is stale because it is the most expensive document on the program to change.
That expense has almost nothing to do with engineering. It is procedural, and it was designed in on purpose.
Changing an interface is a contract action
MIL-HDBK-61A, the configuration management guidance much of the defense and space supply chain inherits, classifies a change as Class I when it affects the form, fit, function, or interface characteristics of a configuration item. Class I changes go to a configuration control board. The board's decision is recorded in a directive that instructs the contracting activity to incorporate the change into the contract.
Read that as an engineer rather than as a process document. Every change to an interface is, by definition, the class of change that reaches the contract. Add a field to a telemetry packet and you have touched interface characteristics. Discover that a housekeeping rate is 8 Hz rather than 10 Hz and you have touched interface characteristics. The technical work is twenty minutes. The administrative work is a proposal, a board, a cost impact assessment, and a contract modification.
The cheapest change in the system is procedurally the most expensive one, and everybody on the program works that out within a month of arriving.
The industry's answer to this problem is a meeting
The mechanism programs use to cope is the Interface Control Working Group. NASA documents it as standard interface management practice: technical representatives from each of the interfacing activities, meeting to define interfaces and resolve issues, usually reporting into a larger change board.
It works, and it is the wrong shape for the load. An ICWG's throughput is measured in meetings per month. The engineering that needs its decisions moves in days, and it does not stop while the group convenes. Between two ICWGs, both sides keep building against something, and what they build against is not the last approved revision. It is whatever the two lead engineers agreed to last Thursday.
The gap never announces itself. Nothing fails at the moment the document falls behind. It fails months later, at integration, when one side implemented Thursday's agreement and the other implemented the revision.
The interface migrates to whatever is cheap to change
The ICD is a compliance artifact. The header file is the interface. Only one of them is under change control, and it is the wrong one.
Every program we have worked on ends up holding two interface definitions. One is the controlled document: signed, baselined, in the data pack, accurate as of some date in the past. The other is the working definition, and it lives wherever engineers can edit it without opening a contract action. A C header. A shared spreadsheet. A message schema in a repo, or a thread of emails ending in "confirmed, thanks."
The working definition is accurate, because it has to be. Code is written against it and the code either runs or it doesn't. It is also invisible to everyone who was not on the thread. The controlled document is the one handed to the vendor who joins in year three, to the operations team writing procedures, to the test engineer building the SCOE, and to the next program that reuses the box.
This is why interface archaeology is a real job on real programs. The information was written down. The accurate copy was never the official one.
Bind the contract to a version, not to a document
The answer is not looser change control. Interface changes carry real cost to the other party and genuinely need consent. The answer is to stop conflating two things a PDF forces into one artifact: the definition of an interface, and the contractual commitment to a particular state of it.
Define the interface in a machine-readable form, in version control, where a change is a commit with an author and a diff. Let the contract reference an immutable tag of that definition rather than a document number and a revision letter. Generate the PDF for the data pack from the tag, so the deliverable is a rendering of the truth instead of a competing copy of it.
Change control then gets to be about meaning rather than edits. A tool can decide mechanically whether a change breaks anyone: a field removed, a type narrowed, a rate changed, an enum value reassigned. Non-breaking changes flow without a board. Breaking changes go to the ICWG, which is what the ICWG was built for, and that list is far shorter than the one it processes today.
GPS has run a version of this for decades. The GPS interface specification was pulled out of the procurement and published. IS-GPS-200 sits on a public site, proposed changes circulate as interface revision notices with a 45-day review, and civil users hold a seat at the board. An entire receiver industry builds against it without being party to any contract. The honest half of that example is the 45 days. Publishing an interface fixes who's allowed to read it, not how fast it can move. A specification that changes once a year can afford 45 days. A component ICD in the last eighteen months before launch cannot.
If you accept this, the first thing to fix is not the ICD. It is where the ICD comes from. As long as the authoritative interface is a document, its revision cadence is set by contract administration rather than by engineering, and the engineers will keep routing around it, correctly, one field at a time. When the authoritative interface is a versioned definition and the document is generated from it, the customer still gets a baseline, the board still rules on breaking changes, and the accurate copy and the official copy stop being two different files.
Nobody on your program decided to let the ICD go stale. Somebody decided, correctly, that a two-week contract action was not worth one field name. Then they made the same correct decision four hundred more times.
