Build one satellite and integration is a project: a room, a schedule, a team that works the problem until the spacecraft passes. Build eight hundred and that project has to run eight hundred times, identically, on a line that cannot stop to do archaeology on a PDF. The constellation era did not make integration bigger. It changed what integration is, and most of the industry is still tooling for the version that no longer exists.
For most of the history of spaceflight, integration was a place you went once. A science probe, a weather bird, a national security payload: each was bespoke, built in low single digits, and integrated by a standing army of engineers who assembled the vehicle, argued over the interfaces, and signed the paperwork when it flew. The Interface Control Document survived that world because it only had to be interpreted a handful of times. When a human reads an ICD once, at a bench, with the vendor on the phone, the fact that it is a document a person interprets is a tolerable inefficiency.
Then OneWeb put a line in Florida designed to turn out up to two satellites a day, SpaceX began building Starlink units at a rate no traditional prime attempts, and the old arithmetic broke. The interface did not get harder. It got repeated.
A production line has no room for interpretation
The defining feature of a production line is that every step is a repeatable operation with a pass or fail, not a judgment call. You do not staff a line with engineers who read a specification and decide what it means. You staff it with a process that checks each unit against a fixed standard and stops when the unit does not conform.
An integration step that depends on someone reading an ICD and applying experience is, by that definition, not a production step. It is a bottleneck and a source of variance. That was fine when you interpreted the interface once. It becomes a liability when you have to prove, five hundred times, that unit 473 was integrated against the same interface as unit 1, and verified the same way. A document cannot make that guarantee. A check that runs the same way every time can.
In serial production, the failure is drift
In a one-off program, the thing that keeps you up is that the design is wrong: a units mismatch, a reference-frame error, a missing timing assumption. Those are real, and the industry has spent decades and several lost missions learning to hunt them.
Serial production moves the fear somewhere most tooling never looks. When you build the same spacecraft hundreds of times, the design is fixed and reviewed to death. The risk is no longer that the interface is wrong. It is that one unit differs: a harness populated to an older revision, a firmware image one rev behind, a calibration value off by a decimal, the error that doomed the 1999 Milstar launch. None of that shows up at a design review, because the design is fine. It shows up as the one satellite in the plane that behaves differently, months after launch, when the fix costs a deorbit instead of a rework.
A PDF can describe an interface. It cannot run a production line.
You catch drift only if every unit is checked against a machine-readable definition of the interface, before it leaves the floor. When a constellation loses a batch, the post-mortem rarely reads "the design was wrong." It reads "these units were not the units we thought we verified." That sentence indicts the verification method. The engineers did their jobs.
At two units a day, the interface has to live in code
We have argued before that interfaces belong in code and that the ICD should be a generated artifact. At a volume of one, that is a preference you can debate over coffee. At two units a day, it is the only arrangement where the numbers work.
Consider the rate. A line finishes a spacecraft every few days. Each spacecraft carries dozens of internal interfaces: the MIL-STD-1553 bus, the SpaceWire links, the power and thermal handshakes, the harness continuity map. The verification system has to confirm hundreds of interface facts per unit, every few days, with no human in the loop for each one. A person authoring and reading documents cannot hold that pace. The only way every unit gets the identical check is to generate the check from the same source the design comes from. Software-in-the-loop follows the same logic: a per-unit simulation gate on the line is not exotic when the interface model is structured enough to produce the simulation. It is one more station.
The interface becomes the tool the line checks against
Put those together and the interface changes job. It is no longer the document you produce so the review board has something to approve. It is the executable standard the line checks against, the way a machined part is checked against a spec instead of against a memo describing the spec. The document still exists, and a human still needs to read it. But the authority moves from the page to the check, and the check runs on every unit whether or not anyone is watching.
This is the shift the constellation forces and the milestone model hides. When integration happens once, you can get away with the interface living in a document and the truth living in an engineer's head. When integration happens every day, the interface has to live somewhere a machine can read it, because a machine is what enforces it at rate.
None of this makes the one-off programs wrong. A flagship science mission with one build and a decade of margin can carry the document-and-judgment model to the pad and fly. But the industry's growth is not in flagships. It is in planes and shells and refresh cycles, in a component a builder ships to five different integrators expecting each one to plug it in the same way. That world does not run on interpretation. It runs on conformance, checked by machine, one unit after another.
A document was a fine way to describe an interface when you integrated once. It is a dangerous way to guarantee one when you integrate every day. The constellation did not only multiply the spacecraft. It multiplied every place the document was allowed to lie.
