Design verification is not design validation

Verification checks the device against its own paperwork

Verification is an internal comparison: does what came out of design — the finished specification, the manufactured unit — satisfy what the design inputs specified going in, whether that's a dimensional tolerance, an electrical parameter, or a software requirement? The evidence is typically testing, inspection, analysis, or comparison to a similar established design, checked against the input requirements themselves. It's a closed loop by design, and it never has to leave the requirements document to succeed. A device can pass every verification test in the file and still be the wrong device, if the input requirements it was checked against were themselves incomplete or mistaken about what the device actually needed to do.

Validation checks the device against the user, not the spec

Validation asks a question verification structurally can't answer: does the device, used the way it's actually going to be used, meet the needs of its intended users and its intended use? Clause 7.3.7 calls for that confirmation on representative product, under actual or simulated use conditions, before the device is released for use except where an organization documents why an exception applies — and where the intended use requires the device to connect or interface with other devices, validation has to confirm the requirements are still met once that connection is made. This is the clause where clinical evaluation, simulated-use studies, and summative usability testing enter the record, rather than the verification clause a spec-comparison test satisfies.

One well-written input requirement doesn't excuse skipping the other test

It's tempting to treat validation as redundant once the input requirements were written carefully and clearly traced back to user needs from the start — if the inputs were right, doesn't verifying against them cover the same ground? Clause 7.3.7 doesn't accept that substitution, because verification only checks the input-to-output loop; it can't detect a requirement that was itself wrong about the use environment or the user's actual need, no matter how faithfully the output matched it. The reverse shortcut fails too: a strong validation report doesn't retroactively excuse a missing per-input verification trail. An auditor can ask for either record independently, and a file with one but not the other is missing a specific, nameable piece of evidence — not a general gap in rigor.

QMSR carried the split forward; it didn't erase it

Under the old Quality System Regulation, 820.30(f) and 820.30(g) held verification and validation as two distinct paragraphs with two distinct requirements. Now that ISO 13485 is incorporated by reference, that same split lives at Clause 7.3.6 and 7.3.7 instead — renumbered, not merged. A design history file still citing 820.30(f) and (g) by paragraph number is citing sections that no longer appear in Part 820's own text, even though the two-part obligation those paragraphs described didn't change at all.

Where this meets the rest of the file

Validation's own evidence, especially for a device with critical tasks a user has to perform correctly, is frequently the same summative testing a human factors report now has to categorize and present in a specific order — one validation record, feeding two different sections of the file it belongs to. Keeping that record visibly separate from the verification evidence beside it is what lets either section stand on its own when an auditor asks for just one.

A design-control record that keeps verification's input-to-output evidence and validation's user-needs evidence in two visibly separate sections, rather than one blended V&V binder, is previewed in the launch catalog. If your program's design file draws this line differently, the shelf takes that correction directly.