A product change notice arrives from a component vendor. It states that the new revision is form, fit, and function equivalent to the one you qualified, so no requalification is required. Nobody opens the ICD, because nothing in the ICD is wrong. Fourteen months later a flight unit misses its startup deadline on the bus, and no document on the program can explain why.
This is an ordinary condition of building spacecraft now, not an edge case. A smallsat assembled from commercial and rad-tolerant commercial parts inherits the semiconductor industry's product lifecycle, and that lifecycle is measured in years while your program is measured in decades. The part you designed around goes end-of-life halfway through development. The vendor offers a replacement, a die shrink, a new silicon stepping, or the same part number built in a different fab. Your program does a lifetime buy, or accepts the new revision, and moves on.
The interface documentation does not move, because from a documentation standpoint nothing happened.
"Form, fit, and function" is a claim about the part, not about time
Form, fit, and function equivalence is a real assurance and a useful one. It says the replacement occupies the same mechanical envelope, presents the same pinout, and performs the same logical operation. Procurement needs exactly that claim, and vendors are not being careless when they make it.
But read what it covers. It doesn't say the part responds in the same number of microseconds. It does not describe the power-up ramp, the inrush current, the brown-out threshold, or the order in which internal blocks come out of reset. A die shrink changes propagation delay. A new stepping changes startup timing. A memory module that switches flash suppliers underneath an unchanged part number can change erase time by an order of magnitude while remaining, in every sense procurement cares about, the same part.
Form, fit, and function equivalence promises the part will fit the hole. It promises nothing about when it answers.
Every one of those properties is an interface property. They belong to the timing contract between two components, which is the half of the ICD that tends to be thin to begin with. So the change lands precisely where the program has the least written down.
Your ICD has a revision. The part on the other end does not appear in it.
Open a typical ICD and look at what identifies the parties to the agreement. There is a document revision, an approval block, a change history, and a distribution list. What is usually missing is any field binding the document to a specific build on either side.
The document describes an abstraction. "The star tracker." Not star tracker part number 4471-002, hardware revision C, firmware 3.2.1, as verified on 14 March. Because the abstraction has no version, the two things that need to stay in step — the interface definition and the hardware implementing it — drift on separate clocks with no mechanism that could ever notice.
Ask a program which hardware revision its ICDs were written against and you will usually get a date, or a name, or a pause. The information exists. It is in a configuration management system, in a procurement record, in an engineer's memory of which units were on the bench that spring. It is not in the interface definition, which is the one artifact that both organizations actually read.
A lifetime buy freezes the part number, not the behavior
The standard response to obsolescence is a lifetime buy: purchase enough units to cover the program, put them in a bonded store, stop worrying. It feels like freezing the interface, and it does freeze one variable.
It doesn't freeze the others. Firmware still moves, because vendors ship maintenance releases against their own defects, and those arrive with the same reassurance attached — corrects an internal issue, no functional change. That is the identical claim as the FFF letter, made one layer up, and it is evaluated by the same reflex. Nor does a lifetime buy guarantee a single build: units bought in one order can span multiple lots and wafer runs, and the tail of that store gets installed on flight units years after the head of it was characterized.
So the program has frozen the label on the box. What is inside the box has a distribution.
The qualification campaign is evidence about a specific build
A qualification campaign is the strongest verification artifact most programs own, and it is genuinely strong. It is also evidence about particular units, tested on particular dates, in a particular configuration.
When the build changes, the scope of that evidence narrows. Delta-qualification exists for exactly this reason, and it works. The failure is not in the process — it is in who triggers it. The decision to invoke delta-qual is very often made by someone reading a change notice against a parts list, and that person has no view into which timing margins on which buses were closed using data from the superseded build. Nobody is being negligent. The information required to make the call correctly is in a different system from the notice that prompts it.
An FFF letter is a supply chain document. It gets routed to supply chain people. The engineer who spent three weeks closing a startup timing budget never sees it.
Bind the interface to the build, or stop calling it controlled
The correction is unglamorous. An interface definition should carry the part number, hardware revision, and firmware version it was verified against — on both sides, as fields, not as prose in a footnote. Verification results should be bound to those identifiers rather than to the document revision that happened to be current.
Then a change notice becomes a computable event. It names a part; the part appears in a set of interface definitions; those definitions have verification results attached; and the arrival of a new revision invalidates a specific, enumerable set of those results. Which sims re-run, which bench tests repeat, and which timing budgets need a second look stops being a judgment call made from a parts list and becomes a query. Anyone who has managed dependency versions in software has seen this machinery before; it isn't sophisticated, just applied consistently.
None of this requires the vendor to tell you anything they don't already tell you. The PCN already exists and already names the revision. The program simply has nowhere to put that fact where it will collide with the engineering that depends on it.
The uncomfortable part is what this implies about interfaces a program believes are stable. An interface that has not been edited in two years is not necessarily an interface that has held. It may be one where both sides changed, each change was individually assessed as equivalent, and no artifact in the program was capable of registering the drift. A document cannot notice that the world moved. That is not a failure of diligence in how your program writes ICDs — it is what happens when you ask a document to hold a fact that has a version number.
