A design output owes four things, not a signature

A design history file usually has a clean answer for what a design input is and what design verification checks it against, because both terms get their own clause and their own template. Ask the same team to point at where the standard defines a design output, and the answer is often “the input document, but later” — which isn't what design inputs or design verification already cover. ISO 13485:2016 Clause 7.3.4 sits between the two for a reason: it's where a requirement becomes something specific enough to build, buy, and check against, and it names four things that record has to do, not one signature certifying it's finished.

Outputs are a form requirement before they're a content requirement

Clause 7.3.4 opens with a condition that's easy to read past: design and development outputs have to be provided in a form that enables verification against the design inputs they came from, and they have to be reviewed and approved before release. That's a statement about usability, not paperwork — a drawing, specification, or software requirement that can't be checked line by line against the input it's supposed to satisfy hasn't met the clause yet, however complete it looks on its own. A design output filed as prose when the input it answers was a numeric tolerance has produced something the next step in the file can't actually verify against.

Four things, and none of them is optional

Once an output is in a checkable form, the clause asks it to do four specific jobs. It has to meet the input requirements it was written against — the baseline check, and the one teams tend to focus on. It has to provide the information purchasing, production, and service provision actually need to act on it, which is what turns a design decision into a buildable part number or a serviceable component rather than an engineering drawing nobody downstream can act on directly. It has to contain, or reference, the product's acceptance criteria, so the line building to it knows what passing looks like without guessing. And it has to specify the characteristics of the device that are essential for its safe and proper use — the one item on this list that has no equivalent in a general quality output requirement, because it's written for a product that can hurt someone if the wrong characteristic goes unspecified.

The safe-and-proper-use item is the medical-device-specific one

That fourth requirement is what separates 7.3.4 from a generic design-output clause borrowed from a non-medical quality standard. It doesn't ask the manufacturer to guess what a user will do with the device; it asks the design output itself to name, explicitly, which of the device's characteristics have to be right for the device to be used safely — a maximum torque, a minimum clearance, a labeled orientation. Those named characteristics are the same ones that eventually have to show up wherever the device tells a user what it needs from them: on a warning label when engineering controls can't eliminate the hazard, or in the instructions for use when the safe operating window isn't obvious from the device alone. An output that skips this item hasn't just left a box unchecked; it's left the file with no traceable source for a claim the labeling or IFU will eventually make on its own.

Purchasing and production read the same output differently than verification does

The clause's second requirement — that outputs carry what purchasing, production, and service provision need — is the part most likely to get treated as someone else's problem. A design output written cleanly enough to satisfy a verification reviewer can still be missing the tolerance stack-up a machinist needs, or the inspection method a receiving-quality technician needs to confirm a purchased part matches spec. Clause 7.3.4 doesn't let a design team hand off a technically correct output and consider the audience served; it names three downstream functions the same document has to serve at once, and a design output that satisfies verification while leaving production to reverse-engineer its own working spec has only done part of the job the clause assigns to one record.

Where the output's trail actually leads

None of this closes inside Clause 7.3.4 itself. The acceptance criteria a design output carries are what design verification checks the finished device against, and the same output is what a design transfer record has to show survived the move to production specifications intact. A design output that can't answer “what does this trace back to, and what does it hand forward” in both directions has broken the chain the rest of Clause 7.3 depends on, whatever a single approval signature on the output itself might suggest.

Where this meets the rest of the file

A design-output template built around the clause's own four-part test — input traceability, downstream usability for purchasing and production, referenced acceptance criteria, and named safe-use characteristics — is previewed in the launch catalog. If your design controls structure this record differently, the shelf takes that correction directly.