An NPI release gate should answer one practical question: can this exact PCB assembly revision enter the next manufacturing step with its unresolved risks understood and assigned? Close each manufacturing exception with evidence, an accountable decision and a clearly limited scope. A meeting, a green spreadsheet cell or a supplier quotation alone does not demonstrate readiness.
This guide focuses on exception closure between design release and first assembly. It provides a proposed workflow for engineering and purchasing teams, rather than a claim that any checklist guarantees a defect-free build. The examples are illustrative; your product requirements and agreed manufacturing processes determine the actual release criteria.
Define the configuration before reviewing the exceptions
Start the review by identifying the assembly part number, hardware revision, BOM revision, fitted variant and manufacturing package. Include the firmware and test procedure if they affect what will be built or accepted. Different revision labels can be valid, but their relationship must be explicit. A fabrication drawing at revision C and a BOM at revision 7 are not necessarily inconsistent; an undocumented combination is the problem.
NASA’s configuration management guidance describes baselines and controlled changes as tools for maintaining a known product definition. Applying that general principle to a commercial PCBA, create a short release manifest that identifies the files approved together. This does not imply that a commercial prototype needs to follow NASA’s complete project process.
Give the manifest a release identifier. List each file, its revision and its purpose. A checksum can help establish which file was transferred, but it cannot establish that the contents are correct. Engineering still needs to confirm that the exported board geometry, BOM population and assembly instructions describe the intended product.
Separate an observation from an actionable exception
“Please check the connector” is too vague to close. An actionable exception identifies the connector reference, the conflicting documents, the manufacturing consequence and the decision needed. For example: J3’s assembly drawing shows pin 1 on the opposite end from the component footprint documentation. Placement should remain on hold until the design owner resolves orientation and releases consistent files.
Keep an exception register separate from the meeting minutes. Minutes explain the discussion; the register tracks the result. Each entry should survive staff changes and be understandable without searching an email thread. Link directly to the revised drawing, approval or verification record used to close it.
| Field | What to record | Why it matters |
|---|---|---|
| Configuration | Assembly, variant and release identifier | Prevents an approval being reused for a different build |
| Observation | Reference designator, location and conflicting requirements | Makes the issue reproducible |
| Consequence | Possible effect on fit, function, assembly or inspection | Explains why a decision is needed |
| Owner and disposition | Named role; revise, verify, accept temporarily or reject | Separates responsibility from discussion |
| Closure evidence | Document revision, measurement or approved concession | Supports an auditable release decision |
| Effectivity | Applicable order, quantity, serial range or next revision | Limits temporary exceptions |
Use three gates instead of one broad approval
Gate 1: Is the manufacturing package internally consistent?
Compare the fabrication outputs, assembly drawing, BOM and placement file. Check that reference designators and fitted quantities agree, that do-not-populate positions are unambiguous and that board-side conventions are understood. Resolve contradictory dimensions or orientation notes before asking the assembler to infer which file is authoritative.
Data exchange can reduce manual translation, but it does not remove review. IPC describes IPC-2581C’s manufacturing data and bidirectional DFX exchange as a way to communicate design and manufacturing information. If using this format, confirm both parties’ export and import support, inspect the transferred result and still identify the approved revision.
The same discipline applies to Gerber-based packages. Agree on the required deliverables using an assembly file checklist, then record any intentionally omitted item. An omitted stencil layer, for example, needs an agreed responsibility for stencil development, not a silent assumption that another team will supply it.
Gate 2: Are the process and sourcing decisions closed?
Identify where the design depends on a specific process decision. Examples include a bottom-terminated package whose inspection needs are not agreed, a connector that cannot tolerate the proposed thermal exposure, or a replacement component whose body conflicts with nearby hardware. These are different questions and should have different owners and evidence.
Use the manufacturing capability review to discuss the actual construction and assembly requirements. Do not convert a general capability statement into approval of every feature on your board. A process option is ready only when the supplier confirms the relevant configuration and any conditions are carried into the build instructions.
For a sourced alternative, distinguish procurement availability from engineering acceptance. Capture the exact manufacturer part number and approved use. If qualification is incomplete, a controlled evaluation build may be appropriate, but its boards must remain distinguishable from assemblies approved for normal release.
Gate 3: Can the first assemblies be evaluated?
Review the power-up sequence, firmware availability, fixture readiness, expected measurements and acceptance limits. A test procedure that says “verify operation” leaves the operator to invent a method. Define the stimulus, measurement location, operating condition, pass limits and retained evidence for each essential check.
Consider what happens when the first board fails. Provide access to useful test points, a contact for design questions and a disposition process. If test software is still under development, record exactly what the build can demonstrate and what remains unverified. Limited test readiness should not be hidden behind a general production approval.
Choose a disposition that matches the remaining uncertainty
A useful register distinguishes four outcomes. A corrected issue has revised documentation and confirmation that the correction reached the build package. A verified issue has evidence showing the original concern is resolved. A temporary acceptance permits a defined exception for a limited scope. A hold prevents the affected operation until an identified condition is met.
“Accepted risk” needs more than a signature. Record the expected consequence, what will be monitored, who can stop the build and which assemblies are affected. A temporary approval to hand-fit one connector on evaluation units should not silently become the instruction for every future order.
Define release authority by decision type. The buyer can confirm an order quantity, but a quantity confirmation does not resolve a pinout conflict. The manufacturing engineer can propose a process adjustment, but a change to product function needs the appropriate design authority. When responsibilities overlap, name the coordinating owner and the required approvals in the register. This keeps a supplier’s acknowledgement of a message from being mistaken for approval of its technical content.
| Exception | Proposed disposition | Evidence needed before closure |
|---|---|---|
| J3 orientation differs between documents | Hold placement; correct package | Approved drawing and checked placement data |
| Alternative C18 has incomplete operating-bias data | Hold substitution | Component review and circuit verification appropriate to its function |
| Programming fixture is ready but final application test is not | Limit build to an explicitly identified evaluation stage | Agreed test boundary and handling of unverified units |
| One inspection note is missing its document revision | Clarify requirement before inspection release | Reissued note with the agreed reference |
Reopen the right issues when something changes
A closed register is valid for its recorded configuration. If the PCB revision changes, do not automatically repeat every review, but assess the affected interfaces. Moving a connector can affect placement, tooling access, enclosure fit and test-fixture contact. A firmware change can affect startup current, communication timing and the functional test sequence even when the board layout is unchanged.
Record an impact statement for each late change. Identify which gates remain valid, which evidence must be repeated and which previously approved files are superseded. Distribute a replacement manifest rather than adding an unexplained attachment to a long email chain. Ask the manufacturing contact to acknowledge the release identifier that will actually be used.
Close the first-build learning loop
After assembly, compare observed issues with the pre-build register. Did an accepted exception create the predicted difficulty? Did an unanticipated issue reveal missing requirements? Separate design corrections from process adjustments and test-fixture problems so the next revision addresses the appropriate cause.
Preserve the as-built configuration, including approved substitutions and rework. A successful laboratory demonstration is harder to reproduce if nobody knows which components or firmware were present. Attach the relevant build observations and test records to that configuration, then decide what must change before another lot is released.
For a manufacturing review, send the PCB files, BOM and unresolved engineering questions together. Include the release identifier, target quantity and proposed acceptance scope. A focused list of open decisions helps the engineering discussion reach a usable build plan.