Two suppliers receive the same STEP file for a handheld-device bracket. One responds with three questions about load and test conditions before quoting; the other quotes immediately and ships parts machined from a different aluminum, with the locating holes at a looser tolerance than your assembly needs. Neither supplier behaved maliciously. You sent geometry without intent, so each shop filled the gaps with its own assumptions — and the faster quote simply assumed away the requirements that cost money. A prototype specification exists to close exactly that gap before money changes hands: it states what the part must prove, under what conditions, against which measurable criteria, and what evidence you need back with the parts.
Why send a spec when the CAD model is already complete?
A CAD model shows geometry; a specification shows intent, and intent is what turns two identical files into two different jobs. The same bracket file could belong to a proof-of-fit check, a drop-test program, or a pilot run for a sealed outdoor product. Those three programs need different materials, tolerances, finishes, inspection, and documentation — none of which the model can express. Without the spec, the shop optimizes for the cheapest interpretation of the geometry, which is rational behavior, not a failure of trust.
The specification also makes quotes comparable. When every supplier receives the same written conditions, their prices differ for real reasons — process, tooling, quality scope — instead of differing because one supplier assumed a loose tolerance and another assumed a certified material. Buyers who skip the spec are not saving time; they are deferring the ambiguity into change orders and rework, where it costs more.
The five sections every hardware prototype spec needs
The five sections below cover nearly everything a contract manufacturer needs to quote and build a prototype correctly. Sections two and four carry the most cost risk, so they deserve the most specific language; sections that do not apply to your program can be marked “not applicable” rather than deleted, so the shop knows they were considered.
| Section | What it tells the shop | Example that prevents rework |
|---|---|---|
| Purpose and test goal | Which question this iteration answers | “Verify that the bracket fits the mating rail and supports a 6 kg load for 1,000 cycles.” |
| Operating conditions | Environment the part must survive | “-20 to 60 °C, 95% RH non-condensing, UV-exposed exterior.” |
| Material and process intent | Grade, process, and what it should imitate | “6061-T6, machined; must match production material, not 3D-printed substitute.” |
| Quantities and schedule | How many, when, and in what batches | “12 parts, 3 delivered in 5 days for early fit check, 9 by day 12.” |
| Acceptance criteria | Measurable pass/fail for this iteration | “Runout at coupling face ≤ 0.05 mm; hand-assembly force 20–40 N.” |
The last row is the one most specifications get wrong. Acceptance criteria are not a restatement of the drawing tolerances; they are the conditions that decide whether the prototype answers the question you built it to answer. A part can be inside every drawing tolerance and still fail its purpose, and the spec is the only document that captures the difference.
Turning vague goals into acceptance criteria you can measure
Break the goal into a feature, a condition, a measurement, and a numeric limit: “the shaft rotates freely” becomes “the shaft rotates by hand with measured runout at the coupling face below 0.05 mm after the retaining nut is torqued to 8 N·m.” Each part of that sentence removes an ambiguity that would otherwise surface at inspection time.
For fit criteria, name the mating part and the fit condition — at room temperature, with or without lubrication, after plating. For strength criteria, name the test, the load rate, the pass limit, and the sample size, because a single static pull and a 10,000-cycle fatigue test are different requirements wearing the same phrase “must be strong.” For appearance criteria, avoid color words alone; reference a physical sample or a Pantone/RAL number, and state the lighting condition under which the comparison happens.
One criterion per decision keeps the iteration fast. If the goal is assembly fit, do not also demand a cosmetic finish that the fit test cannot evaluate; defer appearance to the iteration that exists to answer it. Mixed criteria produce mixed results and slower learning.
DFM feedback belongs in the spec as a formal revision
Treat design-for-manufacturing feedback as a proposed revision to the specification, review it against the test goal, and approve it explicitly — never let it become a silent substitution. A shop that suggests changing 7075 to 6061, loosening a hole tolerance, or adding a corner radius is usually offering a real cost or lead-time improvement. The suggestion is only safe if the change still satisfies the acceptance criteria, which only you can judge.
When you accept the change, update the spec and the revision number, and restate which acceptance criteria were checked against the new configuration. If the supplier changes material or tolerance without confirmation, the test results lose their meaning, because you can no longer attribute the outcome to the design you intended. The same discipline applies to your own engineering changes: each CAD revision should carry a note saying which acceptance criteria changed and why, so the shop is never choosing between two versions of the truth.
A pre-submission checklist catches ambiguity before quoting
The checklist catches missing conditions and ambiguous criteria while they are still free to fix. Run through it before every quote request, and treat an unchecked box as a reason to delay sending rather than a detail to resolve later.
- Purpose of this iteration is written in one sentence and names the decision it supports.
- Critical dimensions are marked on the drawing; noncritical features are intentionally loose.
- Material grade, process, and finish match the test intent and are stated in full.
- Operating conditions, quantity, lead time, and delivery point are explicit.
- Acceptance criteria include the measurement or test method and the numeric limit.
- Known risks — tight tolerance, thin wall, exotic material — are flagged for the shop.
- Revision number and change history are attached so the file matches the spec.
A complete package also gives the shop what it needs to respond usefully. If you want suppliers to challenge your assumptions, invite them to; if you want apples-to-apples pricing, ask them to quote the spec as written and list deviations separately. The RFQ basics guide explains how the request itself should be structured, and the quote request page accepts the drawing and spec together so nothing gets lost between email and review.
A specification and a test plan are different documents that teams sometimes merge too early. The specification defines what the prototype must prove and the criteria that decide success; the test plan defines how the proof will be collected — which samples, which equipment, which operator, and which sequence. For a simple fit check the two fit on one page; for a loaded or environmental validation they should be separated, because the test plan changes when equipment changes while the specification should stay stable. Keep the specification revision-controlled and the test plan date-controlled, and link them by the acceptance criteria. That split also makes supplier responses more useful: a shop can quote against the specification and comment on the test plan without feeling it owns the test method. When a prototype program has several iterations, record which revision of the spec each iteration was built against and which acceptance criteria it passed or failed. That history is what turns a series of builds into evidence for the design freeze, and it is the reason reviewers should be able to see the criteria that were dropped or relaxed and who approved the change.
Frequently asked questions
Should the specification state a target budget?
Yes, as a range with assumptions, not as a number floating in the email. “Target landed cost under $25 per part at 200 pieces, machining from 6061-T6, no exotic tooling” tells the shop what to optimize and invites it to flag when the goal is unrealistic. Without a range, suppliers either quote the cheapest interpretation of the geometry or avoid the question and surprise you later.
Who should approve the specification before it goes to a supplier?
The engineering owner who defines the test goal and the person who will sign the acceptance results should both review it. A spec approved by one and enforced by the other creates disputes at inspection. Assign a single revision owner who merges feedback, bumps the version, and confirms the drawing, the spec, and the quote all reference the same revision before it ships.
What if the shop recommends a cheaper material than the spec calls for?
Ask for the recommendation in writing with the property comparison and the affected acceptance criteria. If the substitute still passes every criterion, approve a formal revision; if it does not, keep the specified material and say why. Never accept a substitution verbally “because it is basically the same,” because material changes invalidate test results and downstream documentation.
Conclusion
The specification is the cheapest quality tool in a prototype program because it moves ambiguity to the front of the process, where it costs nothing, instead of leaving it to inspection, where it costs rework. The practical sequence is: state the decision this prototype supports, write acceptance criteria in measurable language, send the drawing and spec together, and treat every supplier suggestion as a revision to review — not a substitution to absorb.
If you are finalizing a prototype spec and want a manufacturing review before you commit, send the drawing with your load, environment, and acceptance notes to the 6CProto rapid prototyping team. A quick review of the conditions up front can change tolerances, material, or process before the first quote — and avoids the more expensive review after the first bad batch.