Design inputs written as marketing statements rather than verifiable requirements, verification that does not trace to a specific input, and design changes made after transfer without returning to the design file. Nearly every design control observation traces back to one of those three.
Inputs that cannot be verified
"Easy to use" and "durable" are not design inputs. An input has to state a property, a value and a way to confirm it. When inputs are vague, verification becomes an argument rather than a test, and the design history file cannot demonstrate the device meets its requirements.
Traceability that breaks in the middle
A trace matrix is only useful if every verification activity resolves to an input and every input resolves to a user need. Matrices are commonly built once at the end of the project, from memory, and then never maintained through change.
The repair is unglamorous: rebuild the matrix from the actual protocols and reports, and make its update a required deliverable of the change control process.
Changes after design transfer
- Supplier or material substitutions treated as purchasing changes only
- Software updates handled through IT change management rather than design change
- Labeling and IFU revisions that skip usability consideration
- Process changes at the contract manufacturer that alter a verified characteristic
What good looks like
Design reviews with named, independent reviewers and recorded decisions; verification protocols that cite the input under test; and a change process that asks, every time, whether the change touches something already verified or validated.
References
Reviewed by the named consultant. Last updated July 14, 2026. General information only — not regulatory or legal advice for a specific situation.