The Difference Between a Design Review and a Design Check
These two activities are routinely confused in engineering practice. The confusion is not semantic. It produces real consequences.
These two activities are routinely confused in engineering practice. The confusion is not semantic. It produces real consequences - reviews that do not review, checks that cannot check, and a governance record that looks complete but is not.
A design check is an examination of a specific piece of work against a defined standard. It asks whether the calculation is correct, whether the drawing conforms to the specification, whether the selected component meets the stated duty. The checker works within the frame the designer has established. The inputs are taken as given. The question is whether the output follows correctly from them.
A design review is something categorically different. It examines whether the frame itself is correct. It asks whether the right problem is being solved, whether the inputs are valid, whether the assumptions behind the design are defensible, and whether the proposed solution would actually perform as intended under real operating conditions. The reviewer does not take the frame as given. Questioning the frame is the job.
What each activity catches - and what it cannot
This distinction matters because the two activities catch different failures. A check catches execution errors - the wrong section modulus, the misapplied safety factor, the tolerance that conflicts with the manufacturing process. These are real errors and finding them is genuinely valuable. But a check cannot catch a design that has been executed correctly against the wrong requirement. It cannot catch an assumption that is coherent internally but wrong about the world. It cannot catch the operating condition that the designer did not consider because no one told them about it. A well-checked design can still be fundamentally wrong, and checking will not surface that.
Most organisations understand this in principle and collapse it in practice. The collapse happens in two directions. The first is when a review is scoped like a check - the reviewer is given a drawing package and asked whether it is correct, rather than being given a design problem and asked whether the solution is sound. The reviewer then does what the scope permits: they check. They find execution errors, they raise comments, they sign off. The review record looks like a review. The activity was a check.
The second direction of collapse is subtler and more damaging. It happens when checking is elevated into review without the authority, preparation, or independence that a review requires. The checker, working through a calculation line by line, encounters an assumption that looks questionable. But the checker’s remit is to verify the output given the inputs, not to challenge the inputs themselves. So the assumption passes. It passes not because anyone judged it sound, but because the activity being performed was not designed to examine it. The assumption is now inside the governance record with an implicit endorsement it was never given.
The failure mode this produces
The failure mode is distinctive. The design has been checked. The review has been signed off. The paperwork is complete. And somewhere inside the approved package is an assumption that no one ever examined - not because it was examined and accepted, but because the activity that should have examined it was structured as something else.
What separates a review from a check in practice is not the seniority of the person performing it, though seniority matters. It is the question being asked at the outset. A check asks: given these inputs, is this output correct? A review asks: given this problem, is this design sound? The first question can be answered by working through the document. The second requires independent judgement about the problem itself - about what the design is trying to do, what conditions it will face, what could go wrong, and whether the proposed solution adequately addresses those things.
Running a review as though it were a check is not a minor procedural shortfall. It is a structural gap in the governance record. The decisions that a review should have produced - on assumptions, on risk, on fitness for purpose - were never made. They were bypassed, and the bypass was documented as completion.
Getting it right from the outset
The fix is not to make checks more thorough. Checks should be thorough, but that is not the point. The fix is to be deliberate about which activity is being commissioned. If you want a check, commission a check and be clear about what it can and cannot certify. If you want a review, commission a review and give the reviewer the authority, time, and independence to perform one.
The governance record should reflect which activity took place. A check sign-off certifies that the work is internally consistent with the given inputs. A review endorsement certifies that an independent judgement was made about whether the design is sound. Those are different claims. Conflating them in the record produces a document that appears to say more than it does.
The distinction is not procedural pedantry. It is the difference between a programme that knows what it has examined and a programme that has documented activity without producing accountability.