How to Evaluate Substitute Components Before PCB Assembly
Direct answer: The practical answer to "What must be checked before a substitute component is approved for a PCB assembly?" is to use a documented decision gate, not a generic supplier promise. The target outcome is a substitution checklist with decision ownership and validation depth. Start with the function gate: Confirm device role and every parameter material to that role. Then review the package and people who can approve exceptions. Hold the project when comparison relies only on a generic description. Exact manufacturing, inspection, sourcing, and test scope depends on the selected design and partner. This guide makes scope explicit before quotation, release, or the next build decision.
What decision does this guide support?
Matching package and a few headline parameters does not establish electrical, mechanical, regulatory, or lifecycle equivalence. This guide helps design engineers approving sourcing alternatives make decisions about alternate-part engineering review. Its information gain is a multi-domain substitution review checklist. The framework below is a project-control tool, not a claim that one process, supplier, quantity, or lead time fits every board.
Substitution Review Checklist
Use this framework at the point where a project could otherwise move forward on an assumption. Each row names the evidence needed and a condition that should stop release until an owner resolves it.
| Checklist item | Required evidence | Hold condition |
|---|---|---|
| Function | Confirm device role and every parameter material to that role. | Comparison relies only on a generic description. |
| Electrical | Check ratings, tolerances, thresholds, interfaces, protection, and derating context. | A maximum rating is mistaken for operating equivalence. |
| Mechanical | Check package, pinout, land pattern, height, orientation, and assembly handling. | The part fits the schematic but not the board. |
| Thermal/timing | Review dissipation, thermal path, switching, propagation, clocks, and analog behavior as relevant. | System-level behavior has not been considered. |
| Firmware/test | Identify identifiers, calibration, drivers, limits, and regression tests affected. | The board can assemble but cannot be validated. |
| Approval record | Document evidence, approver, scope, revision, and BOM update before purchase. | Approval remains an untraceable message. |
Classify the proposed change
For the classify the proposed change step, use Function as the control point. Confirm device role and every parameter material to that role. Treat this as a release decision rather than an administrative detail. Place the build on hold when comparison relies only on a generic description. Record the input reviewed, its revision or date, the decision owner, and the action required. That record keeps a later sourcing, assembly, test, or repeat-batch decision tied to the same baseline.
Electrical comparison
For the electrical comparison step, use Electrical as the control point. Check ratings, tolerances, thresholds, interfaces, protection, and derating context. The useful evidence is a record another person can review without reconstructing the conversation. Place the build on hold when a maximum rating is mistaken for operating equivalence. Record the input reviewed, its revision or date, the decision owner, and the action required. That record keeps a later sourcing, assembly, test, or repeat-batch decision tied to the same baseline.
Package and footprint
For the package and footprint step, use Mechanical as the control point. Check package, pinout, land pattern, height, orientation, and assembly handling. This check should connect engineering intent to a purchasing or manufacturing action. Place the build on hold when the part fits the schematic but not the board. Record the input reviewed, its revision or date, the decision owner, and the action required. That record keeps a later sourcing, assembly, test, or repeat-batch decision tied to the same baseline.
Thermal and timing behavior
For the thermal and timing behavior step, use Thermal/timing as the control point. Review dissipation, thermal path, switching, propagation, clocks, and analog behavior as relevant. A short written rule is more valuable than a broad assurance because it exposes the next owner. Place the build on hold when system-level behavior has not been considered. Record the input reviewed, its revision or date, the decision owner, and the action required. That record keeps a later sourcing, assembly, test, or repeat-batch decision tied to the same baseline.
Firmware and test impact
For the firmware and test impact step, use Firmware/test as the control point. Identify identifiers, calibration, drivers, limits, and regression tests affected. The aim is not maximum paperwork; it is to prevent an unapproved assumption from entering the build. Place the build on hold when the board can assemble but cannot be validated. Record the input reviewed, its revision or date, the decision owner, and the action required. That record keeps a later sourcing, assembly, test, or repeat-batch decision tied to the same baseline.
Approval and BOM update
For the approval and bom update step, use Approval record as the control point. Document evidence, approver, scope, revision, and BOM update before purchase. Close the step with an explicit pass, hold, or approved-deviation result. Place the build on hold when approval remains an untraceable message. Record the input reviewed, its revision or date, the decision owner, and the action required. That record keeps a later sourcing, assembly, test, or repeat-batch decision tied to the same baseline.
How to use the framework on a real project
- Define the baseline. Identify the board revision, assembly variant, quantity, intended learning or delivery outcome, and files being reviewed.
- Assign decisions. Name who can approve engineering changes, sourcing substitutions, process deviations, test failures, and schedule tradeoffs.
- Record the result. Store the pass, hold, or deviation outcome with the build package so a repeat order does not depend on memory.
Questions to close before release
What evidence is sufficient?
Evidence should match the risk. A file reconciliation may be enough for one decision; a datasheet comparison, inspection record, controlled test, or engineering approval may be needed for another. The key is that the evidence is named before work proceeds.
Who owns an exception?
The party executing purchasing or manufacturing can identify an issue and present options, but changes to functional intent require an authorized customer engineering decision. Put that boundary in the RFQ or release record.
When should the project stay on hold?
Hold when the next action would make an unresolved assumption expensive, irreversible, unsafe, or difficult to trace. A documented hold is usually less costly than discovering after assembly that teams used different revisions or acceptance criteria.
Related Cyrionix resources
This guide strengthens the component sourcing topic owner. Supporting resources:
