Concept vs Detailed Design, Qualification
Boundaries between concept, preliminary and detailed design, verification, validation, qualification and certification, and what each stage proves.
"Designed," "verified," "validated," "qualified," "certified", vendors use these words as if they were synonyms, and the confusion is worth real money to whoever benefits from it. Each stage answers a different question, produces a different kind of evidence, and proves a different thing. Buying the wrong stage, or believing a claim made from the wrong one, is how programs end up with beautiful analyses of aircraft that cannot be built, or built hardware that cannot be sold.
Here is what each stage actually proves, in plain English, and a table to keep by you when the vocabulary starts to blur.
Concept design proves that a point exists
Concept design turns a mission into requirements and closes a design point against them inside a declared model: the cycle, the geometry it implies, the mass budget, the checks against thresholds frozen before the run. What it proves is narrow and valuable: within the model's stated basis, a configuration exists that meets the brief. What it does not prove: that the configuration can be manufactured, that it survives its environment, or that any regulator will accept it.
The Orion release is a concept-stage artefact and presents itself as exactly that: a closed cycle, generated geometry, nineteen checks against declared thresholds, deterministic replay, and a published model basis stating which conservation laws and efficiency relations the numbers rest on. The declared basis is part of the evidence. A concept claim without one is asking to be believed rather than checked.
Preliminary and detailed design create a controlled build definition
Preliminary design turns the concept into a structural and systems architecture; detailed design turns that into a production definition: stress substantiation, tolerances, joints, drawings and parts lists a shop can cut from. The evidence looks like analysis reports, drawing packages and design reviews, not cycle decks. What these stages produce is a controlled build definition: the aircraft as defined, substantiated by structural and systems analysis. What they do not prove: actual manufacturability and production conformity, which require fabrication, inspection and their evidence later, and they do not prove that the built article performs, because no article exists yet. This is also where most concept-stage optimism gets its first honest audit: the mass budget meets real brackets and wiring.
Verification and validation are different verbs
The two words are spent interchangeably and mean opposite directions of checking. Verification asks whether you built the thing right: does the design, the analysis or the article meet its specification, measured against declared thresholds. Validation asks whether you specified the right thing: does the result actually serve the mission need it was commissioned for. A design can pass every verification check and fail validation completely, if the brief it verified against described the wrong aircraft. When a seller says "validated," ask which verb they mean and against what document.
Qualification proves survival, on hardware
Qualification is the first stage in this list that requires representative hardware: qualification articles, which need not be metal. Representative articles are subjected to declared environments (temperature extremes, vibration, humidity, altitude, shock) and must function through and after them. The methods are standardized: MIL-STD-810 for environmental engineering in defense programs, DO-160 for airborne equipment in civil ones, always tailored to the life-cycle the article will actually see. What it proves: this hardware survives and functions in its declared envelope. What it does not prove: airworthiness approval. A qualified component is a component with test reports, not a certified aircraft part.
Certification is a regulator's finding, not a vendor's word
Certification is a demonstration of compliance with airworthiness standards, made to an authority and accepted by it: 14 CFR Part 33 for aircraft engines under the FAA, CS-E under EASA, with the airframe standards alongside them. Compliance is shown with analysis and test evidence the authority finds acceptable, and only the authority issues the type certificate. Two practical consequences. First, "certification-ready" is not certification: a vendor can sell you evidence that may support a future application, but behind any "certified" claim a buyer should ask for the exact authority approval, the certificate itself, and the approved type-design scope it covers. Second, certification evidence is built upward from every earlier stage, which is why the rigor of the concept stage is not bureaucratic taste but compound interest.
The decision table
| Stage | Question it answers | Evidence it produces | What it does not prove |
|---|---|---|---|
| Concept design | Does a configuration exist that meets the brief? | Closed model, check matrix, sealed release | Buildability, durability, approval |
| Detailed design | Is there a controlled, substantiated build definition? | Drawings, stress substantiation, parts lists | Manufacturability, production conformity, hardware performance |
| Verification | Does it meet its specification? | Test and analysis against declared thresholds | That the specification was right |
| Validation | Does it serve the actual need? | Mission-level demonstration | Specification compliance |
| Qualification | Does the hardware survive its declared environment? | Qualification test reports | Airworthiness approval |
| Certification | Does the authority accept it? | Type certificate | Anything about your program's economics |
Where the boundary matters to a buyer
The practical discipline is one question, asked of every claim you are shown: which stage is this from, and what is the artefact? A thrust figure from a closed cycle model is concept-stage evidence and can be excellent of its kind: thresholds declared, checks published, package replayable. It becomes misrepresentation only when it is allowed to sound like a row further down the table.
Genesis Ventures sells the first row: fixed-scope concept design and analysis packages, executed to an audit standard, as laid out on the packages and method pages. Not engines, not flight hardware, not qualification, not certification, and the deliverables guide explains what is actually in the box. If your program needs the later stages, a well-evidenced concept package is the input those stages consume, not a substitute for them. The verification habits that make the first row trustworthy are the subject of what "nineteen checks, nineteen passes" actually means.
Next step: locate your program on the table, then buy the stage you are actually at: no earlier, no later.