Design inputs have to be verifiable, not just approved

Every design-controls post on this blog so far has started downstream of one clause: verification confirms outputs match inputs, validation confirms the device meets user needs, transfer hands the file to production, and a change record reopens all of it later. None of that has anything to check against until ISO 13485:2016 Clause 7.3.3 does its own job first — establishing what the inputs actually are, in a form specific enough that a later test can be run against them. A design input document that reads like a list of adjectives can still get reviewed and signed. It hasn't cleared the clause.

What the clause requires inputs to cover

Clause 7.3.3 requires design and development inputs relating to product requirements to be determined and recorded, and it names what that determination has to include: functional, performance, usability, and safety requirements according to the device's intended use; applicable regulatory requirements and standards; applicable output of risk management; and, where appropriate, information derived from previous similar designs. The old Quality System Regulation asked for the same substance in FDA's own words, at 820.30(c) — procedures to ensure design requirements are appropriate and address the device's intended use, including the needs of the user and patient. Since QMSR's February 2, 2026 compliance date carried that obligation into the incorporated standard, the way this blog has already traced for the DMR, DHF, and DHR, a design input procedure still citing “820.30(c)” is citing a paragraph Part 820's own text no longer contains.

Four tests an input has to pass, not one

The clause doesn't stop at listing categories of input. It requires the resulting requirements to be reviewed for adequacy and approved, and it requires them to be complete, unambiguous, and not in conflict with each other. Complete and unambiguous read fairly plainly. The harder one is the requirement that inputs be capable of being verified or validated — because that's not a description of the input, it's a constraint on how it has to be written. “The device shall be easy to use” is an aspiration, not an input Clause 7.3.3 can accept, because nothing in Clause 7.3.6 can verify “easy” against anything. “A first-time user completes the priming sequence without assistance, in under 90 seconds, in at least 90% of simulated-use attempts” is the same intention rewritten as something a verification or validation activity can actually check. Design verification only has power because 7.3.3 forces the input it's checking against to already be measurable — a verification record can't rescue an input that was never written testably in the first place.

Conflicts don't resolve themselves, and the resolution has to be recorded

The old QSR was explicit that a design-control procedure needs a mechanism for addressing incomplete, ambiguous, or conflicting requirements, not just a finished input list that happens to be free of them. Two inputs can each be individually reasonable and still not survive contact with each other — a target device weight and a battery-capacity requirement that can't both be met at once, a sterilization cycle parameter that would exceed a material's own tolerance. Clause 7.3.3's own answer isn't to pick a winner informally and move on; it's to run the conflict through the same review-and-approval step every other input has to clear, with the resolution itself becoming part of the record an audit can read later.

Risk management's outputs arrive as an input, not a downstream check

One line in 7.3.3's own list is easy to read past: applicable outputs of risk management belong among the inputs, not just among the things a finished design gets checked against afterward. That ordering matters. A risk management file that only starts once a prototype exists is already behind the clause it's supposed to feed — 7.3.3 assumes risk analysis has already run early enough to hand the design process real constraints, a control measure that has to be built in, a severity threshold a material choice can't cross, rather than a list of problems discovered after the inputs were already frozen.

Where this meets the rest of the file

A design input record that passes all four tests gives every clause after it something solid to work from: verification and validation have an actual target to test against, transfer hands production a specification that was never vague to begin with, and when a change eventually reopens the file, the design change record is reopening inputs that were precise enough to show exactly what moved. A design input worksheet built around this structure — the four categories 7.3.3 names, the four tests each input has to pass, and a documented path for resolving conflicts before approval — is previewed in the launch catalog. If your program writes design inputs differently, the shelf takes that correction directly.