Direct answer: what makes a PCBA pilot ready to run?
The pilot is ready when the buyer and manufacturer agree its objective, the exact hardware and firmware configuration, the material and process route, the available fixtures and test limits, the sample and acceptance plan, and the authority to disposition failures. A pilot can deliberately test an unfinished design, but its restrictions must be named before the boards are built. A working sample alone is not a production release or proof of field reliability.
This article covers the execution and acceptance decision for an industrial-control pilot. The design transfer package checklist explains how to release the files entering manufacturing. The change-effectivity guide covers a later revision change across repeat orders and existing stock.
Define the pilot question before setting a build quantity
For a controller or I/O board, the purpose may be to confirm assembly access, programming, connector fit, test-fixture operation or the handoff to a mechanical assembly. Write down which of these the build can actually evaluate. Choose the pilot quantity and sampling method from that objective and product risk; there is no universal board count or yield threshold that establishes readiness for every industrial product.
Keep the acceptance boundary explicit. A board-level functional check may exercise power rails and an I/O path without proving behavior in the customer’s complete machine. Temperature, vibration, electrical safety, EMC or long-duration operation require their own agreed methods and owners when they are relevant. The industry page on industrial automation and robotics electronics treats those operating conditions as project inputs, not assumed performance claims.
Use one pre-build readiness record
A useful record maps each input to the decision it enables. An email saying “files attached” cannot show whether the fixture, firmware and assembly variant match the same controller revision. The table below is an editorial checklist; the project release record remains authoritative.
| Before the pilot | Question to close | Evidence or owner |
|---|---|---|
| Build objective and configuration | Which PCB/assembly revision, variant, BOM and intended product use does this pilot represent? | Released manifest, assembly notes and product owner |
| Materials and alternates | Are all critical parts identified and accepted for this build, with any temporary substitutions restricted? | Kit status, approved alternate record and material owner |
| Assembly route | Are panelization, tooling, special components and process steps understood? | DFM findings, work instruction and manufacturing owner |
| Programming and configuration | Which released binary or settings belong to each hardware variant? | Versioned programming package and verification method |
| Fixture and test readiness | Can the fixture contact the right points, power the product safely and exercise agreed functions? | Fixture revision, setup, limits, known-good check and test owner |
| Acceptance and exceptions | What is a pass, what is a restricted pass and who decides rework or another build? | Acceptance plan, deviation authority and issue log |
For received parts and kit status, use the component receiving and kit-release checklist. A procurement delivery does not become accepted pilot material until identity, condition and project-specific handling requirements are resolved.
Exercise the fixture and interfaces on the intended configuration
Before judging test results, verify the test system itself. Record the fixture version, probe or connector map, power and load assumptions, program version, expected responses and pass/fail limits. A known-good reference or controlled setup check can reveal a fixture wiring or software mismatch before it is mistaken for a board defect. Retain the failure log as well as passing results.
For an industrial controller, test coverage may include a defined subset of power, communications, I/O and programming functions. The exact list must come from the product requirements. If a harness or enclosure affects access or interfaces, agree whether that check occurs at board level or after integration. The functional-test fixture guide covers fixture inputs and gaps; the inspection and test service describes the work package that must be scoped for the specific board.
Do not equate a bare-board electrical test with acceptance of an assembled controller. The IPC-9252B public preview explicitly limits that electrical test to unpopulated printed-board interconnections and notes that it cannot establish assembly or all customer requirements. This distinction helps buyers ask which test result actually supports the pilot decision.
Turn pilot findings into a release decision
Capture each issue against the built revision and affected units or lot. Classify whether the cause is design, material, assembly, programming, fixture or an unresolved interaction. Assign an owner and evidence needed to close it. Do not silently change a test limit to make a failed pilot pass.
| Pilot observation | Decision before repeat work | Closeout record |
|---|---|---|
| Assembly or access issue | Correct the design, tooling or work instruction and decide whether another build is needed | Changed file/instruction, affected revision and verification |
| Fixture or limit mismatch | Repair or validate the fixture and repeat the relevant test | Fixture version, old/new limit and retest result |
| Program or variant mismatch | Hold affected units until the approved hardware/software pairing is clear | Programming manifest, unit/lot identity and re-verification |
| Material or alternate uncertainty | Segregate affected stock and seek technical/customer disposition | BOM line, supplier evidence and written approval |
| Product-level requirement outside pilot scope | Keep the limitation open; arrange the separately defined validation | Named owner, method, acceptance rule and next milestone |
The exit may be “release for the defined repeat build,” “release only with a documented restriction,” or “hold and revise.” Record which findings are closed, which remain open, the accepted configuration and the next authorized work order. A temporary pilot deviation should not automatically carry over to a new purchase order. The NPI engineering service explains the wider review-to-pilot-to-release route.
Ask for the evidence that follows the product
A buyer should request the as-built configuration, issue/disposition log, fixture and test version, results with failed attempts, material exceptions, and the signed release or restriction decision. Agree the traceability depth—unit, lot or shipment—before the build. Do not imply that a lot record identifies every individual board when it does not. The IPC-1782 public preview frames electronics traceability around risk and user/supplier agreement; it does not prescribe one record depth for this project.
For an RFQ or pilot review, share the available controlled files, intended product use, interface list, fixture status, target build quantity and acceptance questions through the project enquiry form. Identify missing records as open items. Confidential files can follow the agreed NDA process.
Source and scope notes
The decision framework draws on the public IPC previews linked above and NASA’s general product-verification guidance, which separates verification methods and records. These are external reference concepts, not claims of Keep Best certification or a guarantee that a specific controller has passed them. Actual sample size, test coverage, environmental qualification, acceptance authority and retained records must be agreed for the product.