- First article inspection for PCBA should be treated as a first-build, documentation, and launch-control gate, not as a universal statement that the whole product is fully validated.
- The most useful boundary is simple: FAI checks whether the first build matches the released package and planned assembly path, while screening, qualification, and high-speed validation answer different questions.
- A board can complete FAI and still need AOI, X-ray, ICT, flying probe, functional test, or program-specific qualification evidence.
- FAI should be described as early-run verification plus traceable records, not as proof of long-term reliability, supplier qualification, or class-based release authority.
- When teams overstate FAI, they usually blur three different layers: first-build confirmation, production screening, and program qualification.
Quick Answer First article inspection for PCBA is the gate used to review the first build against the released BOM, drawings, assembly intent, and planned process before the build is treated as ready to scale. It is useful because it creates a documented baseline for launch and helps catch mismatches early. It should not be described as high-speed validation, environmental screening, or qualification proof by itself.
For the broader view of how SPI, AOI, X-ray, ICT, flying probe, FCT, FAI, and release review fit together, start with the PCBA Assembly Test and Quality Guide. The nearest service-side pages for this topic are First Article Inspection, Testing & Quality, and PCBA Quality System.
Table of Contents
- What should engineers review first?
- What does first article inspection for PCBA actually mean?
- What should FAI own in the build flow?
- How is FAI different from screening, qualification, and high-speed validation?
- When should a team trigger FAI again?
- What should be frozen before using FAI as launch evidence?
- Next steps with APTPCB
- FAQ
- Public references
- Author and review information
What should engineers review first?
Start with build status, released package, gate ownership, and downstream validation needs.
That order matters because FAI has to be defined before checklist items can be interpreted correctly.
The better planning question is:
Is this gate being used to confirm the first build against the released package, or is it being asked to carry validation claims that belong somewhere else?
The first review questions should be:
- Is this the first build of a new or changed assembly package?
- Which records define the build baseline: BOM, drawings, approved substitutions, assembly notes, and revision state?
- Which later gates still own hidden-joint inspection, electrical verification, powered behavior, or shipment release?
- Is anyone trying to use FAI as a stand-in for screening, qualification, or application-specific validation?
| Review axis | What to check | Why it matters | What FAI alone does not prove |
|---|---|---|---|
| Build status | Whether this is a first build or a materially changed build | FAI is tied to launch control, not routine repetition | Ongoing lot conformance by itself |
| Released package | Whether BOM, drawings, and assembly intent are frozen enough to review | FAI compares the build against a defined baseline | That the baseline is optimal for every use case |
| Gate ownership | Which defects or decisions belong to AOI, X-ray, electrical test, FCT, or final inspection | FAI sits inside a layered quality system | That all later gates can be skipped |
| Downstream validation | Whether the product still needs screening, qualification, or high-speed validation | Keeps FAI inside its real scope | Reliability, qualification, or signal-integrity proof |
What does first article inspection for PCBA actually mean?
In this context, first article inspection for PCBA means reviewing the first build against the released design package and the planned assembly path, then documenting what was checked and what was found.
That usually includes evidence such as:
- released BOM and approved substitution review
- drawing and revision alignment
- assembly workmanship review
- first-build process and setup confirmation
- linked inspection or test records when those records are part of the launch package
- traceable documentation that supports ramp decisions
It does not automatically mean:
- high-speed signal validation
- environmental stress screening
- program qualification proof
- supplier certification proof
- blanket shipment release authority for every future lot
This boundary matters because FAI is strongest when it is treated as a first-build control and documentation gate. It becomes weak when it is described as if it alone proves long-term product behavior or customer-program approval.
What should FAI own in the build flow?
FAI owns the first-build questions that depend on matching the released package, confirming launch readiness, and creating traceable review records.
| FAI ownership area | Why it belongs here | What still may be needed later |
|---|---|---|
| Released-package alignment | The first build should match the current BOM, drawing set, and assembly intent | DFM, DFT, or redesign work if the released package itself is still weak |
| First-build workmanship review | Early output should be checked before the route is treated as stable | AOI, X-ray, or electrical evidence at the appropriate later layers |
| Launch documentation | FAI should create a traceable record of what build was reviewed and what evidence supported it | Final inspection and release records for shipped lots |
| Change visibility | FAI helps surface whether a design change, sourcing change, or process change needs a new launch review | Qualification or customer approval workflows where a program requires them |
The factory-floor reason this matters is brutal and very practical.
On a modern SMT line, once the program is released and feeders are loaded, hundreds of boards can move through placement in only a few hours. Imagine the BOM contains an unapproved substitute that was never explicitly cleared at launch review, or a tape-and-reel diode or IC arrives with a polarity or Pin 1 convention that does not match the rotation logic in the placement data. If the team skips a strict, documented FAI halt-and-verify step, the machine will not hesitate. It will place the wrong substitute, or place the part at the wrong rotation, on 500 boards with perfect repeatability.
The defect may stay invisible until downstream electrical test, power-on, or functional debug. At that point, what should have been a one-board correction to a feeder setup or rotation code becomes a mass manual rework event across the whole lot, and in the worst case the batch is pushed into widespread scrap because shorts, polarity reversals, or nonfunctional assemblies have already been multiplied by machine speed. The painful lesson is simple:
FAI is the moment to hit the brakes before a small data-package mistake is amplified a thousand times by automation.
There is an even more absurd NPI failure mode, and it is common in undisciplined factories. The first board comes off the line with one diode reversed or one package loaded from the wrong feeder. Instead of stopping the launch properly, the line engineer grabs a soldering iron, swaps the part by hand, reruns the local test, and signs the FAI sheet as PASS. That repaired board is then treated as the Golden Board even though the physical correction never went back into the SMT program, placement rotation table, or the controlled BOM.
The machine does not know any of that. When the line restarts, the pick-and-place program still reflects the original wrong data and repeats the same polarity or part-number error at full speed across the remaining lot. The result is grotesque but predictable: one board was manually rescued, 499 boards were still built wrong, and the signed FAI record becomes nothing more than paperwork covering a systemic failure. That is why FAI is not fix the first board and move on. It is a data-loop closure gate. If a physical correction made during first build is not driven back into the release package and machine code before restart, the FAI record is functionally worthless.
This is why FAI is best framed as a launch-gate checkpoint, not as a synonym for overall product validation.
Related reading:
- PCBA Assembly Test and Quality Guide
- First Article Inspection
- Testing & Quality
- PCBA Quality System
- AOI and SPI Best Practices in PCBA
- X-Ray Inspection in PCBA
How is FAI different from screening, qualification, and high-speed validation?
FAI becomes easier to explain when each governance layer stays in its own lane.
| Layer | What it mainly answers | What it does not replace |
|---|---|---|
| FAI | Whether the first build matches the released package and has documented launch evidence | Screening, qualification, or full application validation |
| Screening | Whether production units are stressed or screened according to the program's production-risk plan | First-build documentation or design qualification |
| Qualification | Whether the design and process have separate evidence for program-level reliability or acceptance requirements | First-build conformance review alone |
| High-speed validation | Whether the signal path, stackup, and system behavior are validated for high-speed use | First-build documentation or workmanship review alone |
That table matters because the most common overclaims are predictable:
- FAI is described as if it proves long-term reliability
- FAI is described as if it replaces ESS, burn-in, or screening
- FAI is described as if it releases a high-speed design without separate validation
- FAI is described as if it proves supplier qualification or class pass status
Those claims are weak because they collapse different governance questions into one first-build event.
The stronger rule is:
Use FAI to confirm the first build and document the launch baseline, but route screening, qualification, and high-speed evidence to their own gates.
When should a team trigger FAI again?
Teams usually trigger FAI again when the baseline being trusted for launch is no longer the same baseline.
That often includes:
- a new design entering its first assembly run
- a meaningful BOM or drawing revision
- a process route change that affects how the build is assembled or reviewed
- a sourcing or package change that alters what the first-build evidence needs to confirm
- a restart where the team decides the launch baseline needs to be re-established
The important point is not to publish a universal trigger rule with unsupported numerics.
Keep the principle clear:
when the released build package changes enough that the previous first-build evidence is no longer the right baseline, FAI should be reconsidered.
What should be frozen before using FAI as launch evidence?
Before FAI is used as real launch evidence, freeze:
- the board revision, assembly drawing, BOM, and approved substitutions
- the scope of the first-build review, including what evidence is expected in the record
- the relationship between FAI and other gates such as AOI, X-ray, ICT, flying probe, FCT, and final inspection
- the boundary between first-build confirmation and later screening or qualification requirements
- the traceability rule for linking the reviewed build to the released documentation set
If those items are still moving, FAI can still provide useful engineering feedback, but it should be framed as a working launch review rather than a final proof package.
Next steps with APTPCB
If you are preparing a critical NPI build, worried that a mixed BOM may hide substitute risk, or concerned that polarity, package, or rotation mismatches could derail the first article, do not wait until the line is already running.
Send APTPCB the release package before machine start, including:
- the assembly BOM with clear AVL and approved-substitute status
- assembly drawings and revision-controlled notes
- full Gerber package and placement data
- expected inspection, test, and FAI gate ownership for the first build
- any known concerns around polarity, Pin 1, special packages, hidden joints, or traceability requirements
Email the package to [email protected] or start through the release-package readiness review request. APTPCB's NPI and quality engineering team will complete a Release-package Readiness Review within 24 hours to:
- expose BOM ambiguity before it reaches feeder setup
- verify whether substitute parts, polarity conventions, and rotation logic are aligned
- enforce First-Build Data Closure, with bi-directional closure between any physical first-article fix and the released machine data before the SMT program restarts
- lock the right FAI halt points and downstream test ownership
- reduce the risk of batch-wide rework or scrap before the SMT program is released
If you want to align the launch gate before that handoff, review these APTPCB pages first:
FAQ
Is first article inspection the same thing as qualification?
No. FAI is a first-build conformance and documentation gate. Qualification is a separate program-level activity.
Can FAI replace AOI, X-ray, or electrical test?
No. FAI may include or reference evidence from those layers, but it does not erase their separate ownership.
Does FAI prove a high-speed PCBA is fully validated?
No. High-speed performance still depends on separate design and validation evidence beyond first-build review.
Is FAI the same as screening or burn-in?
No. Screening and burn-in belong to a different production-risk or reliability layer. FAI belongs to the first-build launch layer.
What is the biggest mistake in FAI planning?
Treating FAI as a universal release claim instead of defining exactly what first-build evidence it owns and what later gates still need to happen.
Public references
APTPCB First Article Inspection Supports FAI as an integrated first-build review and documentation step for new or changed projects.
APTPCB Testing & Quality Supports the broader layered relationship between inspection, electrical verification, screening, and release review.
APTPCB PCBA Quality System Supports the multi-gate quality-flow framing used to keep FAI in its correct lane.
IAQG 9102 First Article Inspection Requirement Supports the public identity of first article inspection as a defined documentation and review vocabulary rather than a generic catch-all validation claim.
SAE AS9102C First Article Inspection Requirements Supports the idea that FAI is a documented first-article framework, even though PCBA launch packages still need their own assembly, inspection, and test boundaries.
Author and review information
- Author: APTPCB PCBA launch-control content team
- Technical review: first-build governance and PCBA quality engineering team
- Review scope: first-build launch gate definition, documentation control, and method-boundary consistency
The FAI report structure described here is the same acceptance package our contract PCB assembly engineers use to release a build into production.