"It's flight-proven, just use it again."
This sentence has ended more hardware than almost anything else you can say in a design review, and it is spoken in good faith every time. The part flew. It came back. It works. Why would you re-test it?
Because "it flew" and "it is qualified for this" are different claims, and only one of them is about the flight you are planning.
Proven and qualified are not the same claim
Flight-proven is a statement about history. This part was on a vehicle, and the vehicle did not fail in a way attributable to it.
Qualified is a statement about a boundary. This part has been demonstrated to work within a specific envelope: a pressure range, a temperature range, a vibration profile, a cycle count, a duration. It is trusted inside that envelope and not outside it.
The gap between them is where the failures live. A pressure transducer that flew on a vehicle running at 25 bar is flight-proven. It is not qualified to 40 bar. Nothing about the first flight tells you anything about the second, and "it's flight-proven" is a true statement that answers a question nobody asked.
The reason this is dangerous rather than merely imprecise is that proven is a sticky, portable label and qualified is a conditional one. "Flight-proven" travels through conversations and slide decks unchanged. The envelope stays behind in a test report nobody opens.
There is a subtler version too. A part can survive an environment without being qualified for it, and surviving once is not evidence of margin. If a seal saw 45 bar on a flight where it was only ever qualified to 25, the correct conclusion is that you got away with it, not that the envelope is bigger than you thought. Teams routinely draw the second conclusion, because the first one requires someone to say out loud that a flight was riskier than they realised.
Four ways reuse actually goes wrong
The envelope moved and nobody re-checked. The new vehicle runs hotter, or higher, or longer. The part is the same part. Its qualification is unchanged, which now means it does not cover the mission. This is the common case and it is almost never a decision. It is an omission, because nobody held the old envelope next to the new requirement.
The margin was consumed and never reset. The part is qualified for 50 pressure cycles. It has done 38. It is still qualified, for twelve more. If nobody tracks accumulated life, the label says "qualified" right up until the part fails inside its own stated envelope, which is the worst version of this because the paperwork was correct the whole way down. Cycle counts, thermal cycles, hours under load, and shelf life for anything elastomeric all behave this way.
The qualification was inherited from a different unit. Serial number 003 was tested. Serial 007 is the same design, from the same batch, and is treated as covered. Sometimes that is legitimate, because batch qualification is a real thing, and sometimes it quietly isn't. The question worth asking is what actually makes two units equivalent. Same drawing is not enough. Same drawing, same material lot, same machine, same operator, same process parameters, and same inspection is a defensible claim. Student-team hardware is largely hand-made, and hand-made means the operator is a process variable whether you record them or not.
The parent spec changed underneath it. The part is unchanged and its qualification is unchanged, but the requirement it was qualified against has been revised. It is now qualified against a spec that no longer exists. This is the one that is genuinely impossible to catch by hand, because nothing about the component changed at all. It is parameter drift wearing a different hat.
Why a spreadsheet column cannot fix this
The instinct is a "Qualified" column. Tick it, filter on it, done.
That column is a claim with nothing behind it. It cannot tell you what envelope the tick refers to, which test produced it, which spec version it was tested against, or how much life the part has left. It records the conclusion and throws away every input, and the inputs are the entire content of the claim.
Worse, a boolean makes the failure modes above invisible by construction. There is no cell where "qualified to 25 bar, mission needs 40" can live as a contradiction. The tick is a tick.
What a component record has to carry:
- The envelope it was qualified for, as actual bounded values with units, not prose.
- The evidence: which test, which report, which date, which serial.
- The spec version it was qualified against.
- Accumulated life against whatever the limit is measured in.
- Its current lifecycle state, which is distinct from its qualification.
- The caveats, which is the field everyone omits and everyone later needs.
Once those exist as structured fields rather than a column, the check stops being a memory exercise. Reuse becomes a comparison: this envelope against those requirements. A machine can do that comparison, and a machine will do it every time, including the Tuesday in October when everyone is tired.
What to record at test time
The cheapest moment to capture qualification data is while the test is happening. The most expensive is eighteen months later from memory. These take about ten minutes at the bench and they are what makes reuse decidable:
- The actual conditions achieved, not the target. If you aimed for 40 bar and the rig topped out at 37, the envelope is 37.
- The duration and cycle count, even where they were not the point of the test. That number becomes the life baseline.
- Which unit, by serial. "One of the batch" is not a record.
- The spec version the test was written against.
- What nearly went wrong. The fitting that wept slightly at 35 bar and was retightened is exactly the detail that vanishes with the person who saw it, and exactly the detail that matters when someone proposes running to 40.
That last one is why a text field for caveats earns its place. Structured data captures what the test proved. Caveats capture what the operator suspected, and suspicion is often the more valuable signal.
What good reuse looks like
The workflow that works is boring and has three steps.
- State the new operating envelope before you go shopping. Not after you have found a part you want to use. The order matters, because a stated requirement is a test the candidate either passes or fails, and a requirement written afterwards is a rationalisation.
- Compare envelopes, not labels. The question is never "is this flight-proven". It is "is this qualified for at least what I need, against a spec version that is still current, with enough life left".
- If it doesn't cover the mission, say what would. Usually a delta qualification: one test to extend the envelope to what you need, rather than full re-qualification.
That third step is the payoff, and it is why this is not a bureaucratic exercise.
Delta qualification, and why precision pays
Suppose the transducer is qualified to 25 bar and the mission needs 40. Full re-qualification means the whole environmental sequence: vibration, thermal, pressure, life cycling. Days of rig time and a unit you may destroy.
A delta qualification asks a narrower question. The part's qualification is short in exactly one dimension, so you test that one dimension: a pressure ramp to 40 bar with margin, on a representative unit, against the current spec. An afternoon, one unit, and a report that extends one bound.
You can only do that if you know precisely which bound is short. A team with its envelopes written down can point at the single number that fails and design a test around it. A team without that data cannot scope a delta test, because it cannot say what is already covered, so its only options are re-test everything or trust everything. Both are bad, and under time pressure everyone picks the second one.
So the counter-intuitive result is that the team with rigorous qualification data reuses more aggressively, not less. Rigour is what lets you tell the difference between a part that is genuinely fine and a part that needs one afternoon on a test bench.
The handover problem
For student teams there is a version of this that compounds. Qualification data has a shelf life measured in personnel, not years. The person who ran the test knows what the envelope really was, including the caveats that never made it into the report. When they graduate, the part keeps its label and loses its context.
Three years later, "flight-proven" is a piece of folklore attached to a part in a cupboard. Nobody can produce the test, name the envelope, or say how many cycles it has done. And nobody wants to be the person who says the team's trusted component is undocumented, because that sounds like an accusation about people who are no longer there to defend themselves.
This is worth naming plainly, because it changes what the data is for. Writing down an envelope is not paperwork for your own benefit. You already know what you tested. It is a message to somebody who has not joined the team yet, about a part they will be asked to trust. That is an unglamorous thing to spend an afternoon on, and it is the single highest-leverage habit a team with annual turnover can build.
The practical fix is that the envelope has to live on the component record from the first test onward, not in a report filed in a folder, and not in a person. It only happens reliably when the tool makes it the path of least resistance.
Prototype holds qualification envelopes as structured bounds on the component record, checks a reuse against the new operating conditions, and flags a component when the spec it was qualified against gets revised. See how it works, or read about parameter drift, which is the same failure in a different form.