A prototype-to-production transfer is ready for review when the build can be reproduced from controlled documents and the remaining design, material, assembly and test decisions have named owners. A working prototype is useful evidence, but it is not the complete manufacturing package. The release gate should show what is approved, what is conditional and what still prevents the next build.
This checklist focuses on transferring an electronics design into a defined pilot or production stage. It does not prescribe a universal qualification program or replace customer-specific release requirements. Use it to expose open decisions before a quotation or build instruction treats them as settled facts.
If the product is already released and the task is moving production between suppliers or sites, use the PCB manufacturing transfer checklist to compare the receiving process with the existing baseline. This article addresses the earlier decision: turning prototype knowledge into an approved manufacturing release.
Describe the build that is being released
Identify the product variant, PCB and assembly revisions, firmware release and intended quantity. State whether the next operation is a pilot intended to answer open questions or a repeatable production build. A controlled pilot can include planned experiments; an ordinary production order should not depend on unwritten engineering experiments.
List the differences between the working prototype and the proposed release. Hand modifications, substituted components, temporary connectors and engineering-only software can all matter to the transfer. Record which differences have already been incorporated into released data and which still require a decision. A photograph of the successful prototype does not resolve those differences by itself.
Use an open-decision register with release consequences
| Decision area | Question to close | Release evidence |
|---|---|---|
| Design baseline | Do the PCB files, assembly data and schematics describe the same approved configuration? | Configuration index with revision references |
| Materials | Which parts and alternates are approved for this build? | Released BOM and substitution decisions |
| Assembly instructions | Have prototype modifications and special operations been captured? | Approved drawings and operation notes |
| Firmware | Which image and product configuration must be installed? | Release reference and programming verification requirements |
| Production test | What must be measured, with which setup and limits? | Released test package and acceptance requirements |
| Mechanical integration | Does the assembled product fit its enclosure, harness and mounting arrangement? | Reviewed integration drawings and applicable verification |
| Exceptions | Which unresolved items affect the next build? | Owner, permitted scope, closure evidence and due decision |
| Release authority | Who can authorize the next stage? | Recorded decision tied to the exact configuration |
Give each open item an identifier and a consequence. “Test needs work” is less useful than identifying the missing test function, the affected configuration and whether the pilot may proceed without it. This turns a status meeting into an actionable release decision rather than a list of general concerns.
Transfer the test environment, not just the test script
A prototype test may rely on a developer’s computer, manually entered limits or an undocumented instrument setting. The production package needs to identify the released setup and its dependencies. NI’s TestStand deployment guidance illustrates this issue by treating the test code, supporting framework files and drivers or runtimes as parts of the deployed solution. That example is platform-specific; the handoff question applies regardless of the selected test platform.
Ask the receiving team to demonstrate the released operation using the intended station and instructions. Record which configuration was used and where the result is stored. Keep engineering diagnostics separate from the approved manufacturing decision. A useful debug script is not automatically the released acceptance test.
Make a pilot answer specific questions
Define what the pilot is expected to establish before selecting its build quantity. The project might need to verify an assembly instruction, confirm fixture access, exercise the released test sequence or assess integration into an enclosure. Each question should have an owner, a planned observation and a decision that follows the result.
A pilot quantity alone does not describe the strength of the evidence. Avoid claiming that an arbitrary number of successful units proves long-term process capability or product reliability. If statistical confidence or reliability qualification is required, the responsible team must define an appropriate plan and its assumptions. The transfer register should reference that plan rather than invent one.
Example: close a firmware-setting exception without hiding it
Consider a hypothetical instrument whose prototype meets its demonstration target only after an engineer changes a software setting. The transfer team records issue NPI-014 against assembly revision C and firmware 2.3. The missing decision is whether the value belongs in a released firmware image, a product configuration file or a unit-specific calibration operation. Those options have different verification and record requirements.
The issue owner proposes a configuration file for a ten-unit engineering pilot. The authorization permits assembly and controlled evaluation of those ten units; it does not authorize shipment. The traveler references the proposed configuration identifier and the test station records its readback. The pilot objective is to demonstrate that the receiving team can apply and verify the setting without the developer intervening. Ten successful units would answer that handoff question, not establish a statistical reliability claim.
Closure requires the responsible owner to approve the configuration file, its installation method and the verification result, then update the release index. If the setting must instead vary by unit, the issue returns for a calibration-process decision. Keeping the same issue identifier connects the proposal, observed evidence and final disposition. “Discussed in the meeting” is not a closure record. All identifiers and quantities in this example are illustrative.
Control changes while the supplier prepares the build
Agree on a release cutoff and a method for communicating subsequent changes. Identify affected materials, tooling, documentation and work already performed before approving a revision. The purpose is to make the consequence visible, not to prohibit useful engineering changes.
When a change is accepted, update the configuration index and notify the relevant owners through the agreed workflow. Preserve the earlier release for traceability. Sending one revised drawing while leaving the BOM and test package ambiguous can create a mixed configuration that neither team intended to build.
Set conditions for a controlled release
A conditional release should name the activity that may proceed, the quantity or configuration it covers and the decisions that remain blocked. For example, permission to obtain materials is different from permission to assemble or ship. The authorization should make those boundaries clear to purchasing and manufacturing.
Close each condition with evidence and a recorded decision. If the pilot produces a new issue, retain its relationship to the original question and the tested configuration. Do not remove an exception from the register merely because it has been discussed; record the document, test or approval that resolved it.
Send a transfer package that supports a useful proposal
For new product introduction, provide the configuration index, build files, open-decision register and proposed pilot objectives. Include existing test assets and identify who owns missing work. The project review workflow can then connect the inquiry to engineering clarification and an agreed scope.
When comparing an electronic manufacturing service, ask which transfer activities are included and which remain with your team. A proposal should state those responsibilities before the prototype becomes the reference for a production order.