Verification confirms you built the product right, that outputs meet the specified requirements. Validation confirms you built the right product, that it meets the needs of its intended use. In ISO 9000 terms, verification checks specified requirements; validation checks fitness for a specific intended use. Both demand objective evidence, not opinion.

The two words get swapped constantly, and the confusion is expensive: a part can pass every dimensional check and still fail in the customer's hands, because it was built exactly to a specification that was wrong. Verification would have said yes; validation would have caught it. This guide pins down the ISO definitions, gives concrete manufacturing and design examples, shows how the two fit together in the V-model, and walks through planning both so nothing falls through the gap between them.

What is the difference between verification and validation?

The cleanest way to hold them apart is two questions: verification asks "did we build the thing right?" and validation asks "did we build the right thing?" Verification compares your output against the specification you were given. Validation compares the finished product against what the user actually needs. You can pass one and fail the other, which is exactly why both exist.

Verification versus validation: two different questionsTwo questions, two kinds of evidenceVERIFICATION“Did we build it right?”OUTPUTSPECIFIEDREQUIREMENTScompare to the specdimensions, tests, inspection,calculation, first articleVALIDATION“Did we build the right thing?”PRODUCTINTENDEDUSEconfirm fitness for real usetrials in actual conditions,user acceptance, field use
Verification measures the output against the spec you were handed. Validation measures the product against the need it is supposed to serve. Different reference, different evidence.

What does verification mean?

ISO 9000:2015 defines verification as "confirmation, through the provision of objective evidence, that specified requirements have been fulfilled." In plain terms, verification is checking your work against the spec. It happens throughout production and design: incoming inspection against the drawing, a first article inspection against the print, a calculation reviewed against inputs, a test that a dimension is within tolerance.

The reference point for verification is always an internal, stated requirement. Did the shaft measure 10.00 ± 0.02 mm? Did the weld penetration meet the drawing callout? Did the code do what the requirements document said? None of those questions asks whether the requirement was correct, only whether it was met. That is verification's strength and its blind spot: it is rigorous about conformance and silent about whether conformance is enough. Note that verification is also the everyday word for a lighter check on equipment; the distinction between a full recalibration and a quick verification check is its own topic, covered in calibration vs verification.

What does validation mean?

ISO 9000:2015 defines validation as "confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled." Validation is checking against reality, the real conditions, the real user, the real application. It is the step that catches a product that meets its spec but not its purpose.

A worked contrast makes it land. Suppose the spec for a bracket calls out a material and a hole pattern, and the part is built and verified perfectly to that spec. Validation puts the bracket on the actual assembly under real vibration and load, and if it cracks, validation fails even though verification passed, because the specification underestimated the load. The failure is not in the building; it is in the requirement. Manufacturing formalizes validation as process validation: proving a process reliably produces conforming product under real operating conditions, often through the IQ/OQ/PQ sequence and a formal design review that confirms the design intent before launch. The reference point for validation is the intended use, and that is what makes it harder to fake.

The same split shows up outside the machine shop. A packaging line can seal every pouch to the verified force spec, yet if the seal fails a drop test after a cold shipping leg, validation exposes it, the intended use includes the cold chain the spec forgot. A software feature can pass every unit test written against the requirements (verified) and still be the wrong feature for the operator on the floor (not validated). Wherever the requirement can be right or wrong, you need validation to check the requirement itself, not just conformance to it.

How do verification and validation work together?

They interlock in what engineers call the V-model: as you decompose a need into requirements, design, and build on the way down, each level is verified against the level above, and the finished product is validated against the original user need at the top. Verification runs at every stage; validation closes the loop at the end.

The V-model: verification at each level, validation across the topThe V-model: where each check livesUSER NEEDSREQUIREMENTSDESIGNBUILDACCEPTANCE(validation)SYSTEM TESTUNIT / PART TESTVALIDATION: against the original needverify: meets requirementsverify: meets design
Verification is the short horizontal check at each level: does this stage match the one above it. Validation is the long arc across the top: does the finished thing serve the need we started with.

The V-model shows why order matters. If you skip verification, defects escape downstream and get expensive to find. If you skip validation, you can ship a perfectly conforming product that does the wrong job. Regulated industries make the pairing explicit, ISO 9001:2015 clause 8.3.4 requires both design verification and design validation as separate controls, precisely because passing one does not imply the other.

How do you plan verification and validation for a product or process?

Treat them as two separate evidence plans that share a schedule. The steps below keep the gap between "built right" and "right thing" from swallowing a launch.

  1. Write down the intended use first. Before any spec, state what the product or process must actually do in real conditions and for whom. This is the yardstick validation will use, and if it is vague, validation cannot be objective.
  2. Derive requirements and make them verifiable. Turn the intended use into specified requirements that each have a stated, measurable acceptance criterion. A requirement you cannot measure cannot be verified.
  3. Plan verification at every level. For each requirement, name the method (inspection, test, analysis, or demonstration) and where in the flow it happens, incoming, in-process, first article, final. Every requirement should have one owning check.
  4. Plan validation against real conditions. Define how you will prove fitness for the intended use: field trials, process validation runs under normal operating ranges, user acceptance, or endurance testing. Validation evidence must come from conditions that represent actual use.
  5. Capture objective evidence for both. Record results as data, not sign-offs. ISO's definitions hinge on objective evidence, so a checkbox with no measurement is neither verification nor validation.
  6. Close the loop when either fails. A verification failure usually means fix the build; a validation failure often means fix the requirement. Route both through corrective action so the root cause, not just the symptom, is resolved.

Where do teams get verification and validation wrong?

The most common error is treating a validation as done because verification passed. A supplier ships parts that clear every dimensional check, the customer's assembly still fails, and everyone is surprised, but no one validated against the real application. The mirror-image error is calling a field trial "validation" when the intended use was never written down, so there is nothing objective to validate against.

Two smaller mix-ups cause real damage. First, confusing validation with quality control inspection: inspection sorts good from bad against a spec (verification), while validation asks whether the spec was right. Second, using "verification" loosely for a quick equipment check and then assuming the instrument is fully qualified. Keep the reference point straight, spec for verification, intended use for validation, and most of the confusion evaporates.

What the standards actually say

The definitions are not folklore; they are written down and stable.

Where verification and validation fit your quality system

Verification and validation are the two halves of proving a product is both correct and fit. They connect to nearly everything else in the quality toolkit: a first article inspection is verification against the print, a design review is a checkpoint where validation evidence is judged before launch, and any failure on either side should land in corrective and preventive action (CAPA) so the root cause is fixed rather than re-inspected around. Keeping the two apart in your own language, spec versus intended use, is half the battle.

The practical failure is rarely the concept; it is the evidence trail. When verification results live on paper travelers and validation runs are summarized from memory, the objective evidence ISO asks for is thin, and audits turn into archaeology. Capturing measurements and run data at the point of work, the way Harmony's live capture and shop-floor visibility tooling does, means both verification and validation leave a searchable record with the numbers attached, not just a signature. For a look at a floor where that evidence is captured as work happens, see the CLS field story. Build it right, and build the right thing, you need proof of both, and the proof is the point.