Your Launch Provider Wrote the Only ICD That Works
Every interface on your spacecraft was negotiated except one. The launch provider published a document, declined to discuss it, and told you to prove your payload fits the envelopes printed inside. That is the one interface on your program that has never slipped.
The payload user's guide is a public PDF. Falcon 9's, Ariane 6's, Electron's: download any of them right now, without an NDA and without a meeting. Each carries a revision number and a date. The document governing the most violent ten minutes of your spacecraft's life is the least private and least argued-over artifact on the program.
It is also the one that holds. Payloads built to the guide fit the fairing, survive the ride, and separate. The ICD between your avionics box and your power board, private and bilateral and negotiated across three months of meetings, is the one that finds you in the high bay at two in the morning. Rockets being serious does not explain that gap. The launch interface has three properties any interface on your program could have, and most of yours lack all three.
Publication beats negotiation
A launch provider writes one guide for every customer on the manifest. No room exists in which all those payloads sit, so the provider publishes: one definition, one revision number, many readers. You do not get a change board. You get a document and a date.
Your internal ICDs invert that. Two teams meet, argue, converge, and export a PDF each side files separately. One interface now has two copies, and from that morning forward the copies are free to disagree. Nobody publishes, because publishing implies an audience larger than the room.
Aerospace is not missing the machinery to do better. We have had the schema formats for years and treat them as export targets, something you generate on the way out of a tool rather than something two organizations read. The launch provider's advantage has nothing to do with the format. It refuses to hold the meeting.
The requirement ships with its proof
Read a user's guide as an engineer and the structure is the point. Requirements arrive attached to the method that proves you met them. Mass properties are measured and reported to a stated tolerance. The payload envelope arrives as a drawing, and you demonstrate clearance against it with your dynamic deflections included. Shock comes as a response spectrum at the separation plane. RF compatibility comes with an analysis and a test. The requirement and its proof sit in the same paragraph.
Now open your internal ICD. The field is a 16-bit unsigned integer, milliradians per second, at 10 Hz. Correct, unambiguous, and silent on every question that matters next: who proves it, how, against what, and what happens when the proof comes back wrong. A different team invents the verification months later, reading the same document a second time. Two readings of one document is how you get two systems.
The launch interface holds because nobody on your program was allowed to negotiate it.
The gate is a simulation that can return a failing number
The coupled loads analysis is the strongest part of the arrangement. You build a structural model of your spacecraft, reduce it to a manageable set of boundary degrees of freedom, and hand it over. The provider couples your model to the launch vehicle's, runs the transient events (liftoff, max-Q, staging, separation), and sends back load factors. You do this once early against a preliminary model, then again later against the as-built one.
You cannot sign your way past that. No systems engineer initials a box and thereby makes the spacecraft fit. The model runs, the numbers come back, and you either clear the envelope or you go redesign a bracket.
Notice what the analysis never asks for: your drawings, your source, your internal models. A reduced model is enough to couple two structures built by companies that will never show each other anything else. The interface crosses the boundary and the implementation stays home. Every vendor who has told you their models are proprietary already does this once per launch.
The equivalent event inside your program is a meeting. Two teams present, everyone nods, someone takes an action item. Nothing runs, and nothing can fail. The artifact is a date in a slide deck.
Nobody forces the rest of your program to work this way
The launch provider operates under a constraint you have engineered your way out of: it cannot fix your mistake. Once the fairing closes there is no field service, no patch, no walking over to someone's desk. It also faces a manifest of customers at once, so per-payload accommodation does not scale. Publication, versioning, and a hard analytical gate are what those two facts force.
Inside your program, anyone can call a meeting. When the comms team reassigns an APID, they walk over and mention it, and mostly that works. The one time it doesn't, your ground system sorts telemetry into the wrong bin for six weeks of a thermal vacuum campaign, and you find out from a plot that looks strange. The ability to renegotiate is what hollows out the interface. A specification you can talk your way around is an opening position.
This is why generating ICDs from code, which we argue for constantly, is necessary and not sufficient. A generated document that two engineers can renegotiate over coffee has better provenance and the same authority as the one it replaced.
Copy the form your launch provider imposed on you. One definition both sides read rather than two copies they each own. A revision number that means something. The verification method attached to the requirement instead of deferred to whoever writes the test plan. A simulation standing in front of the gate, allowed to come back with a number you don't like. Your program already runs all of it, once, for the single interface where somebody else set the rules.
The launch provider never asked your opinion about the ICD, and that is why it is still true on launch day. Every other interface on your program remains a negotiation, and a negotiation is only true until someone reopens it.




