Verification vs. Validation: What They Actually Mean and Why Hardware Teams Keep Getting Them Wrong
Walk into a design review at almost any hardware program and ask the team to define the difference between verification and validation. You will hear confident, contradictory answers. Some engineers will say they are essentially the same thing. Some will reverse them. A few will give technically correct definitions but describe processes their program does not actually run. This confusion is epidemic, and it carries real consequences: when a certification authority or quality auditor asks for validation evidence, a folder full of test reports that only address requirements compliance will not satisfy them. When a safety review board asks whether the system meets user needs, a passed test matrix is not the answer they are looking for.
The terminology is not pedantic. Each activity answers a fundamentally different question. Getting them wrong—or treating them as one thing—leaves a category of risk entirely unmanaged.
The Core Distinction
Verification answers the question: Did we build the system right? It is a comparison between the system as built and the requirements that were specified for it. Verification asks whether outputs at each stage of development conform to the inputs for that stage. A unit test that confirms a sensor driver returns values within the specified accuracy band is verification. An inspection that confirms a weld meets the dimensional tolerance in the drawing is verification. The reference document is always the requirement.
Validation answers the question: Did we build the right system? It is a comparison between the system’s behavior and the actual needs of the people and missions it is meant to serve. Validation asks whether those needs are satisfied—regardless of whether any written requirement captures them accurately. A flight test where a pilot determines that the cockpit display layout does not support the workload of a degraded-mode approach is a validation activity, even if every display specification was met exactly. The reference for validation is not the requirement; it is the operational reality.
The cleanest illustration of why both are necessary: imagine a requirement that reads “the system shall filter noise above 500 Hz.” The signal processing team writes code and runs verification tests. The filter is implemented correctly; all test points pass; the requirement is met. But the original system engineer made an error: the actual environmental noise the system needs to reject starts at 200 Hz. Verification passed. Validation—had it been performed rigorously against real-world operational data—would have caught the problem before the product shipped.
This scenario is not hypothetical. It repeats across programs wherever validation is treated as a checklist item rather than a substantive activity, or wherever teams assume that a verified system is automatically a valid one.
What IEEE 1012 Says
IEEE 1012, Standard for System, Software, and Hardware Verification and Validation, is the foundational reference. It defines both activities with precision and specifies that they are complementary, not redundant.
IEEE 1012 frames verification as the evaluation of products of a given development phase to confirm they satisfy the conditions imposed at the start of that phase. This is explicitly intra-phase: does the output match the input? It frames validation as the evaluation of the software or system during or at the end of development to determine whether it satisfies specified requirements and fulfills its intended use.
That phrase—intended use—is the tell. Intended use is not the same as written requirements. If the requirements incompletely or incorrectly capture intended use, verification can pass while validation fails. IEEE 1012 requires V&V planning to address both dimensions separately, with distinct objectives, methods, and acceptance criteria. Programs that merge their V&V plans into a single “test and verification” document are, almost by definition, not running the validation side seriously.
ARP4754A and the Systems Layer
ARP4754A, Guidelines for Development of Civil Aircraft and Systems, is the authoritative process standard for civil aircraft systems development. It structures the entire development lifecycle around a hierarchy of requirements—from aircraft-level through system-level to item-level—and it treats verification and validation as activities that must both occur at each level.
ARP4754A Section 5.5 distinguishes them this way: verification confirms that the implementation satisfies the requirements allocated to it; validation confirms that the requirements at each level correctly capture the higher-level intent passed down to that level. Requirements themselves must be validated upward—not just the implementation validated against them.
This is a more demanding view than most programs operate under. It means that when you write a system-level requirement, you are not done. You must also confirm that the requirement is a correct and complete expression of the aircraft-level need it is supposed to serve. If that validation step is skipped or superficial, requirements errors propagate downward and manifest as system failures that no amount of lower-level testing will prevent.
ARP4754A also distinguishes validation methods: analysis, inspection, simulation, demonstration, and test—each appropriate to different types of requirements at different maturity levels. Not all requirements can be validated by test. Some must be validated by analysis against operational scenarios, by simulation against environment models, or by structured reviews with operators and end users.
DO-178C and the Software Dimension
DO-178C, Software Considerations in Airborne Systems and Equipment Certification, applies the same distinction to software. It requires that software requirements be verified for correctness, consistency, completeness, accuracy, and verifiability—the last meaning that you can actually test or analyze them. It also requires that the high-level requirements from which software is derived be shown to correctly capture system-level intent.
The certification liaison process under DO-178C involves the certification authority reviewing evidence for both dimensions. A software accomplishment summary that documents exhaustive structural coverage but cannot show that the requirements being covered were themselves valid against operational needs is an incomplete submission. Certification authorities have become more explicit about this over the past decade. Programs that treat DO-178C as a test coverage exercise and skip the requirements validation work are increasingly encountering findings late in the certification process.
A System Can Pass Verification and Still Fail
The most important operational reality is this: verification success does not imply validation success. The two activities can and do decouple.
Consider a ground vehicle fire suppression system. The requirement specifies that the agent shall be discharged within 500 milliseconds of a fire detection signal. The system is designed, built, and tested. Every test run confirms discharge in under 500 milliseconds. Verification passes at every level.
In operation, the detection sensors are mounted in positions that generate false positive signals during high-vibration maneuvers. The suppression system activates during normal operation, discharging into an occupied compartment. No requirement was violated. Every specification was met. But the system did not do what the users needed it to do: protect the crew from actual fires without creating new hazards during normal operation. Validation—specifically, validation of the detection architecture against real-world operational scenarios—would have surfaced the sensor placement problem. Verification had nothing to say about it because it was never captured in a requirement.
This is the category of risk that validation is designed to catch: the space between what was specified and what is actually needed.
How Modern Tools Should Support Both
The tooling problem for most hardware teams is that their requirements management environment does not structurally support the distinction. A traditional DOORS database stores requirements and links them to test cases. That supports verification traceability. But it has no mechanism for linking requirements upward to the stakeholder needs and operational scenarios they are intended to satisfy, and no mechanism for marking that upstream linkage as validated or not.
Teams end up doing validation as a disconnected activity—a Word document, a separate meeting, a review that generates comments but does not update the requirements model. The result is that validation evidence is untraceable, and when an auditor asks for it, the team has to reconstruct it from meeting notes.
This is where tools built on a connected, graph-based requirements model have a structural advantage. Flow Engineering, built specifically for hardware and systems engineering teams, maintains requirements as nodes in a graph that can carry relationships in both directions: downward to verification evidence—test results, analysis reports, inspection records—and upward to the stakeholder needs and operational use cases the requirements are supposed to satisfy.
In Flow Engineering, a requirement node is not just a text string linked to a test case. It carries provenance: where did this requirement come from, what need does it satisfy, and has that upstream linkage been reviewed and approved? When a requirement changes, the system can flag whether the change affects the validation status of the upstream stakeholder need, not just the verification status of the downstream test.
This means that when a certification authority asks “how do you know this requirement correctly captures the user’s need?”—the answer is not “we had a review meeting six months ago.” The answer is a traceable, timestamped record showing the stakeholder need, the derived requirement, the person who validated the derivation, and any open questions that remain.
Flow Engineering also supports validation planning directly: requirements can be tagged with validation methods, assigned to validation activities (operational scenario reviews, simulation runs, prototype trials), and tracked for closure. This keeps validation from becoming the activity that happens once at the end and produces a document nobody can find during the audit.
Practical Starting Points
If your program is conflating verification and validation today, the correction is not to add more test cases. It is to answer two structural questions.
First, for every requirement in your database, can you trace it upward to the stakeholder need or operational scenario it is supposed to satisfy? If not, you have unvalidated requirements—specifications that may or may not reflect what anyone actually needs.
Second, for every stakeholder need in your system, can you trace it downward through the requirements hierarchy to the verification evidence that shows the need is met? If not, you have gaps in your verification coverage that are invisible until something fails in operation.
The V and V in V&V are not interchangeable. They are two different lenses on the same system, each capable of catching what the other misses. Running only one is not a resource-saving optimization. It is a risk transfer—from your review process to your field operation.
Hardware AI Review covers AI-native tools and practices for hardware and systems engineering. This article reflects the editorial staff’s independent assessment.