Machine Design #110: Evidence-Based Design Review — End With Questions That Can Be Verified
Evidence-based design review must preserve function, intent, manufacturability, inspectability, release quality, and serviceability when the boundary changes.
Evidence before release
Write the input, expected result, acceptance limit, failure symptom, and measurement method before changing a drawing or releasing a package. Assign an owner to every assumption, value, and change.
Core checks
- Requirement, assumption, and boundary: record value, source, method, owner, and pass/fail evidence.
- Evidence source, quality, and date: record value, source, method, owner, and pass/fail evidence.
- Risk, failure mode, and verification: record value, source, method, owner, and pass/fail evidence.
- Decision owner and unresolved item: record value, source, method, owner, and pass/fail evidence.
- Change trigger and re-test plan: record value, source, method, owner, and pass/fail evidence.
- Record, handover, and next review: record value, source, method, owner, and pass/fail evidence.
| Failure mode | Symptom | Verification |
|---|
| Intent missing | Correct file, wrong function | Review requirements and evidence |
| Package incomplete | Supplier or inspection stops | Run a release completeness check |
| Documents out of sync | Correct number, wrong revision | Baseline every reference |
Three different reviews, and they should not share one meeting
Putting every question into one long meeting is the usual reason a review becomes a formality: the people with the relevant expertise sit through what does not concern them, and the important part is pushed to the end when everyone is tired.
| Type | The question it answers | Who has to be there | When |
|---|
| Concept review | Is this approach solving the right problem? | The requester, the designer | Before the detailed model is built |
| Manufacturability review | Can it be made, at what price, can it be measured? | Shop, inspection, supplier | Once the geometry is settled, before the drawing is finished |
| Release review | Is the documentation complete and consistent? | Designer, document checker | Immediately before release |
The manufacturability review is the one most often skipped and also the one that saves the most, because at that moment changes are still cheap. The list of documents needed for a release is in Machine Design #109 — Drawing release packages.
A good question is one that can come back negative
A review is only worth holding if the questions asked are capable of producing the answer "not yet". The question "has this been calculated?" always gets "yes". Questions that actually produce information:
- Ask for the number and the boundary conditions, not for a status: which load was it calculated
for, in which position, with what safety factor, and where is the result kept.
- Ask about the worst case, not the design case: if the parts sit at the limits of their permitted
tolerances, does the assembly still fit?
- Ask how it would be detected: if this assumption is wrong, how will the machine behave, and who
will see it first?
- Ask the person who will do the work, not the designer: hand the drawing to someone outside the
design and listen to how they would clamp it, cut it and measure it.
Three sources of findings better than opinions in a meeting room
- Machines already running in the field. Repeated faults on an old machine are the best data for a
new one, provided they were recorded — how to record so the data is usable is in Machine Design #49 — Downtime data.
- The maintenance people. They know which part is hard to remove, where a tool cannot reach, which
assembly needs constant adjustment. None of that appears on a drawing, yet it decides lifecycle cost.
- The risk assessment file. Every committed measure has to be findable in a concrete artefact, in
the way described in Machine Design #69 — Machine risk assessment.
Closing a review: four things that must remain
A review does not create value when people leave the room; it creates value through what remains afterwards:
- An action list with an owner and a date. An action without a name attached does not happen.
- Decisions with their reasons. Six months later the reader needs to know why this option was
chosen, otherwise they will propose the option that was already rejected.
- Assumptions not yet proven, written down as assumptions together with how they will be checked.
- The scope to be rechecked if a change is approved, managed the way described in
Machine Design #107.
An open item without an owner closes itself on the day the machine ships — by being forgotten, not by being resolved.
Each review demands a different kind of evidence
An evidence-based review means each meeting brings the right documents to examine, not a general discussion. The three reviews from the earlier pass demand three different sets of evidence:
| Review | Evidence to bring | The question it answers |
|---|
| Concept review | Requirements, compared options, rough calculations | Does this option meet the requirement, and is it feasible |
| Detailed design review | Full calculations, tolerance stack, design FMEA, drawings | Is the design correct, will it take the load, will it assemble |
| Pre-production review | Prototype results, test data, machining/inspection capability | Can it be made in quantity, correctly and consistently |
Bring the wrong evidence and the review becomes idle talk: a detailed review without a tolerance stack cannot conclude whether it assembles; a pre-production review without a prototype is only guessing.
Checklists and closing open items
- Use a checklist per review type: each has its own list (load, tolerance, material, safety,
manufacturability, inspectability). The checklist keeps the meeting from missing an item or sinking into one detail.
- Open items need an owner and a date: every issue raised becomes an open item with a responsible
person and a due date. A review with no open-item list leaves nothing behind.
- Sign-off is controlled risk acceptance: the signer confirms they saw the evidence and accept moving
on, not a signature for form's sake. Record who approved at what level, so the decision is traceable later.
Closing a review means closing every open item or turning it into a dated action, not "the meeting is over".
MINATA release checklist
- [ ] Function, intent, boundary, and failure symptom are written.
- [ ] Ownership, interfaces, process, and mistake-proofing are clear.
- [ ] Six topic checks have evidence and pass/fail limits.
- [ ] Manufacturing, assembly, inspection, release, and maintenance were tried.
- [ ] Revision, supplier, package, and configuration records agree.
Good engineering ends with questions that can be verified. For evidence-based design review, evidence that function and intent remain reliable is the MINATA standard.
Frequently asked questions
How many reviews should a project hold?
At least three, with three different purposes: a concept review before the detailed model, a manufacturability review once the geometry is settled, and a release review immediately before the documents go out. Merging all three into one meeting is the usual reason reviews become a formality.
Why is the manufacturability review so often skipped?
Because it falls at the moment when the drawing is "nearly done" and everyone wants to release on time. That is also the moment when changes are still cheap, so skipping it usually costs several times the time it saved.
How do you stop a review becoming a formality?
Ask questions capable of returning "not yet": ask for numbers and boundary conditions, ask about the worst case, ask how a wrong assumption would be detected. And invite the people who will manufacture, measure and maintain — not only the designers.
Who should attend a review?
It depends on the type. A concept review needs the requester; a manufacturability review needs the shop, the inspection team and the supplier; a release review needs the document checker. Maintenance should attend at least one round, because they know things that are not on any drawing.
What has to remain after a review?
An action list with owners and dates, decisions with their reasons, unproven assumptions with the way they will be checked, and the scope to be rechecked if a change is approved. Without those four, the review was only a meeting.
Frequently asked questions, continued
What should each review bring?
The right evidence for that review type: a concept review needs requirements and compared options; a detailed review needs calculations, a tolerance stack, an FMEA, and drawings; a pre-production review needs prototype results, test data, and machining/inspection capability. Without the evidence, the review is idle talk.
How do I handle open items after a review?
Every open item gets a responsible person and a due date. A review is only closed when every open item is closed or turned into a dated action, not when "the meeting is over".
What does sign-off in a review mean?
The signer confirms they saw the evidence and accept moving on, as controlled risk acceptance — not a signature for form's sake. Record who approved at what level, so it is traceable who decided.
A quick table for the shop floor
A design review stays productive when the situation, the evidence and the purpose are lined up:
| Situation | How to back it up | Purpose |
|---|
| A requirement | Link it to a drawing, calculation or test | Do not conclude by feel |
| A risk | Give it an owner and a closing action | Do not leave items open indefinitely |
| Release | A checklist with signatures and the configuration | Know exactly what was approved |
A worked case
"Stiffness was checked" has to come with the load, boundary conditions, safety factor and where the result is. A review ends when the questions have evidence and an owner, not when the meeting runs out of time.
Conclusion
Evidence-Based Design Review is not paperwork done to make a file look tidy. It is how intent becomes a result that can be manufactured, assembled and measured repeatedly. A good drawing does not need the designer standing beside it to explain it; the structure of the information has to do that work.
View all MINATA technical articles