Prototype labels do not define the evidence
Teams use “proof of concept,” “alpha,” “beta,” and “functional prototype” differently. A machine-shop assembly may be called a proof of concept even though its geometry is mature. A realistic printed product may be called functional even though an operator secretly resets it between demonstrations. Define the configuration and behavior instead of relying on the label.
A proof of concept usually isolates a difficult principle: can this arrangement release the object, sense the movement, or transfer the required motion? A functional prototype usually combines several subsystems so the user can complete a task. Integration introduces new questions, such as interference, access, sequence, and the effect of one subsystem on another.
NASA's product-realization guidance distinguishes verification against requirements from validation for intended use. Those questions can be asked at different prototype stages. A mechanism can satisfy a bench requirement and still be awkward in the actual use situation. Conversely, a user may like an interaction that the present hardware cannot deliver reliably.
Trace every important substitution
List what differs between the demonstrated system and the intended product. Common differences include external power, a heavier base, purchased components replacing custom ones, a technician aligning parts, and a material selected for easy printing rather than service behavior. None automatically makes the test useless. The problem is forgetting the difference when interpreting the result.
For each substitution, identify which conclusion it could affect. A larger enclosure may invalidate a reach assessment. A stiffer metal frame may conceal deformation expected in plastic. A hand-operated actuator may prove the motion path but say nothing about the eventual motor's torque, speed, or control. Transfer evidence only where the relevant conditions remain sufficiently representative.
Separate positive observations from claims. “Completed twenty bench operations with manual alignment” is a record. “The product is reliable” is an unsupported generalization. A short evidence table can retain the observation, the limited conclusion, and the next required test without dismissing useful progress.
A hypothetical automatic drawer divider
Imagine a divider whose adjustment is first demonstrated on a large open bench rig. A handwheel replaces the eventual compact actuator, and the frame is aluminum. The proof of concept shows that a particular linkage can move through the required range without geometric interference. It does not establish the actuator size, plastic stiffness, finger access, or behavior with debris in the drawer.
The next functional prototype includes the intended user control and a representative enclosure. It still uses a temporary frame. During use, the enclosure prevents access to the handwheel's former adjustment point, exposing a maintenance issue that the open rig concealed. This is not a contradiction of the earlier result; it is a different question introduced by integration.
A third build adopts the candidate production material and process. It may reveal dimensional variation or flexing absent from both earlier versions. The correct response is to reopen the affected requirement and test, not to insist that “the prototype already worked.” Each configuration answered a different subset of questions.
An evidence map for this example would mark linkage travel as provisionally established, integrated access as newly tested, and production consistency as unresolved. The map directs the next build toward missing evidence rather than another general demonstration.
Avoid a production-readiness leap
A functional prototype often contains hidden craftsmanship: sanding, selective pairing, extra adhesive, hand-drilled holes, or careful adjustment by its creator. Document those operations. They may be acceptable for learning but expensive or inconsistent in a batch. Ask whether an unfamiliar assembler could reproduce the result from the files and instructions.
Likewise, a production-process sample is not automatically a production-qualified product. It may come from one tool cavity, one material lot, or one favorable setup. Establishing repeatability requires evidence appropriate to the process and risk. A successful sample can justify the next controlled trial without justifying unrestricted shipment.
Do not add compliance language to prototype labels. Terms such as certified, approved, or validated for a regulated use require the applicable process and evidence. Describe the actual study completed and any external review still needed. The prototype's visual realism has no bearing on whether those obligations have been satisfied.
Build a practical evidence-transfer table
Use columns for requirement or user task, tested configuration, result, difference in the next configuration, and retest decision. Mark evidence as carried forward, carried forward with an explicit assumption, or not transferable. Explain the reason in ordinary language.
Before each new build, review the table with the designer or supplier. A material change may require repeating a snap-fit study but leave a packaging-envelope measurement relevant. A new interface may require assembly testing while leaving an unrelated cosmetic observation intact. This selective approach avoids both blind confidence and unnecessary repetition.
Your deliverable is a clear statement of what is known at each stage. It makes progress visible without inflating it, and it allows an investor, collaborator, or manufacturer to understand exactly what further work stands between a working demonstration and a repeatable product.