Most arguments about a prototype build are not arguments about machining. They are arguments about what was written down. A drawing carries the geometry; it does not carry the intent behind the tolerance, the reason a material was chosen, or the conditions under which a part is allowed to fail. Engineering teams that treat a prototype as a throwaway object get one data point from it. Teams that document the requirements get a record they can hand to a second supplier, a second revision, or a production review six months later without re-litigating every decision. The checklist below is written for the kind of work a Shenzhen Shenzhen PowerDe Automation Precision Equipment supplier sees daily: a customer brings a functional idea, a deadline and an incomplete specification.
1. Separate the question the prototype answers from the part you are building
Write one sentence at the top of the document that states what has to be known when the prototype is in your hands. "The assembly must survive 200 mating cycles without latch fracture" is a requirement. "Build us five units in aluminium" is a request that hides the requirement. If the sentence does not name an observable behaviour and a way to observe it, the build will produce parts rather than an answer, and nobody will be able to say afterwards whether the prototype succeeded.
State explicitly what the prototype is not being used for. A form-and-fit model that never sees load should not be specified with a production surface finish, and a functional test article that will be destroyed on the bench should not carry a cosmetic acceptance standard. Writing down the exclusions stops the supplier from adding cost you did not ask for and stops your own team from reading the result as more general than it is.
2. Record interfaces before dimensions
Interfaces cause the expensive rework. A part that is wrong in the middle of a body can be remade in a day; a part that is wrong where it meets a housing, a connector, a fastener or a sensor is wrong for every downstream assembly. For each interface, document the mating part by drawing number or physical sample, the datum the interface is measured from, the permitted play, and how the interface will be checked before anything is glued, welded or fastened shut.
If a mating part does not exist yet, say so in the document and define a placeholder with a stated risk. Teams routinely send a prototype out against an interface that is still moving, and the supplier delivers exactly what was drawn. A line reading "mating housing is Rev C, subject to change, verify at fit-check before final assembly" gives everyone the same warning at the same time.
3. Make tolerabilities explicit: must, should, and does not matter
| Class | How to write it | Why the supplier needs it |
| Must | A number with a limit and a stated consequence of exceeding it. | Tells the machinist which features to hold and which process to use. |
| Should | A target that may be traded away, with what it may be traded against. | Lets the supplier propose a cheaper route without breaking the test. |
| Does not matter | An explicit statement that a feature is not being assessed this round. | Removes hidden cost from finishing, inspection and rework. |
A table like this is short to write and short to read, and it is the single most effective defence against a quote that is either too expensive or too optimistic. Where you cannot give a number, give the decision rule instead: "if the fit is loose enough to see a gap with the naked eye from 300 mm, reject it".
4. Specify the test, not just the part
Prototype requirements should describe how the article will be exercised, because that is what the fixture, the sensor mounting and the extra material allowance depend on. Document the rig or the machine that will run the test, the loads and cycle counts, the environmental conditions, the pass or fail criterion, and how many units are needed for the sample size to mean anything. If the fixture has to be designed too, it belongs in the same document with the same review gate as the part.
Write the inspection plan in the same place as the drawing. Say which features are measured, with what instrument, on how many pieces, and what happens to a part that lands outside the limit — scrapped, re-made, or accepted with a deviation note. A measurement plan agreed before the parts arrive prevents the situation where two people measure the same feature differently and the team spends a week on a discrepancy that is not real.
5. State process constraints and hand-offs
A product development requirement is incomplete if it stops at the part and never reaches the assembly bench. Record the fastening method and torque, adhesive type and cure time, order of operations, and any step that has to be verified before the next one is allowed. For anything permanent — bonding, welding, potting, over-moulding — note that a mistake ends the article, and require a dry fit and a sign-off first.
Where the work crosses teams, name the person accountable for each line rather than the team. "Mechanical owns the tolerance stack, test engineering owns the fixture, procurement owns the long-lead part" is more useful than a meeting minute. The hand-off that fails most often is the one between the designer and whoever inspects the first article, so put the inspection owner on the page.
6. Version, date and freeze
Every prototype document needs a revision letter, a date, and a rule for what counts as a change. A one-line change log — what changed, who authorised it, which article numbers are affected — is what lets you compare the results of build one with the results of build two. Freeze the document at the moment the order is placed and require a written change note for anything after that; otherwise the supplier builds against one drawing and you test against another.
7. Attach the evidence that supports the numbers
For every load, limit, temperature or material choice, note where it came from: a calculation, a previous build, a datasheet, a standard, or an assumption. Marking an entry as "assumption, to be confirmed by this build" is honest and useful — it tells the reviewer which line to look at first if the prototype behaves unexpectedly. An unmarked assumption that turns out to be wrong is expensive; a marked one is simply the next question.
A short page to send with the drawing package
Before you send the enquiry, put one page in front of the CAD files containing: the question the prototype answers; what it is not; the interface list with datum and check method; the must/should/does-not-matter table; the test rig, loads, cycles and pass criterion; the assembly constraints and sign-off points; the revision letter and change rule; and the origin of each number. That page is what a supplier quotes against, what your own team signs off, and what the next build is compared to.
