Alternate rule approval records must connect each proposed substitute to the released baseline, observed differences, validation evidence, approving authority, and permitted use.
PCBA alternate rule approval records should do more than collect a proposed substitute and an approval signature. It should preserve the exact baseline, define the permitted difference, identify every open risk, link the required evidence, and limit the release to named products, revisions, sources, and dates. Without those controls, the same “approved alternate” can mean different things to engineering, purchasing, quality, manufacturing, and the customer.
Build the checklist as a controlled decision record, not as a generic yes-or-no form. Each field should answer one of four questions: What is changing? Why is it allowed? What evidence closes the resulting risk? Where and when may the decision take effect? If the team cannot complete a required field, the checklist should show a hold, owner, due date, and next action rather than hiding the gap.
Define the source hierarchy before reviewers begin. Manufacturer-controlled ordering information, datasheets, package drawings, and change notices should control part identity. Released product documents should control the product baseline. Approved test plans and raw records should control verification results. Distributor pages, automated comparisons, emails, and meeting notes may point to evidence, but they should not replace it. When two sources disagree, the checklist should show the conflict, assign an owner, and remain on hold until the controlling source and rationale are recorded. This rule prevents reviewers from selecting whichever document supports the fastest answer.
The TI product-change notification policy can support source-status review, while alternate rule approval records must still preserve the project-specific authority, scope, and effectivity.
Give Alternate Rule Approval Records a Controlled Identity
Start with a unique checklist ID, revision, creation date, owner, current status, and link to the governing alternate rule. Add the reason for review, such as lifecycle change, allocation, lead time, quality event, approved cost action, manufacturer notice, or design update. The reason provides context; it does not change the technical acceptance criteria.
State the decision point. A checklist may support an RFQ, a material reservation, a sample build, an engineering release, a temporary deviation, or a production effectivity change. Marking the decision point prevents a document prepared for quotation from being treated as production approval.
List the required reviewers by function. Typical owners include component engineering, design engineering, manufacturing engineering, firmware, test, quality, sourcing, the product owner, and an authorized customer representative when the agreement requires one. The checklist should show “not applicable” only with a short rationale and a named reviewer.
Identify the product, board, BOM, and approved baseline
Record the customer or program reference only when the team has permission to use it. Then identify the end product, assembly number, PCB number, PCBA revision, BOM revision, drawing set, firmware revision, test-program revision, and any configuration or regional variant. A checklist that says “all models” without a controlled product list creates an unbounded release.
Copy the baseline BOM row exactly. Include item number, reference designators, quantity per assembly, approved manufacturer, full manufacturer part number, description, package, key value or function, and approved source requirements. Link the controlled BOM rather than attaching an uncontrolled spreadsheet copy when possible.
The component-alternative review method explains why the baseline and candidate identities must remain separate throughout comparison. If the baseline itself is unclear, stop and correct the BOM or approved manufacturer record before reviewing an alternate.
Record the complete manufacturer part number, approved source, supplied lot, packing condition, and covered BOM revision. Capture the proposed part and supply identity
Enter the proposed manufacturer and complete orderable part number, including suffixes for package, grade, finish, packing, orientation, or screening. Add manufacturer product status, datasheet revision, package drawing revision, ordering-information source, and the date the information was checked. Do not shorten the number to a family when the orderable suffix changes a controlled attribute.
Separate part approval from supplied-material acceptance. For actual samples or purchase material, record supplier, channel type, lot or batch, date code when available, label data, received quantity, packaging condition, moisture barrier and indicator condition when relevant, traceability documents, and incoming-inspection reference. A technically acceptable manufacturer part can still remain on hold if the delivered material lacks identity or handling evidence.
Include the requested quantity, need date, minimum order, quoted lead time, lifecycle horizon, and available stock only as dated commercial inputs. They may explain urgency, but they should not turn an unresolved engineering difference into approval.
Use one row for every observed difference
The difference register is the center of the checklist. Compare the baseline and candidate, then create one row for each difference that can reach product behavior, manufacturing, test, compliance, reliability, sourcing control, or field support. Do not use a single row labeled “datasheet differs.”
Each row should name the baseline value, candidate value, affected requirement or process, possible failure effect, verification method, acceptance criterion, evidence reference, owner, due date, and status. If a difference has no effect, record the engineering rationale. If the team has not checked a category, mark it open rather than equal.
Checklist block
Required fields
Primary owner
Hold condition
Controlled identity
Checklist ID, revision, rule ID, reason, decision point, status
Document owner
No unique record or unclear purpose
Product scope
Assembly, PCB, BOM, firmware, test and configuration revisions
Product owner
Release scope is broader than the evidence
Baseline and candidate
Full part numbers, manufacturers, package, grade, source documents
Component engineering
Family name used instead of orderable identity
Difference register
Delta, affected requirement, risk, method, criterion, owner and status
Discipline owner
Known difference has no disposition
Physical material
Supplier, lot, date code, labels, packaging, quantity and inspection
Quality and sourcing
Material cannot be linked to approved identity
Release record
Decision, conditions, approvers, effectivity, monitoring and reopen trigger
Release authority
Approval has no bounded effectivity
Record Electrical, Mechanical, and Thermal Evidence
Electrical fields should reflect the component’s actual circuit role. Record required operating range, absolute limits, tolerance stack, current, voltage, power, frequency, timing, leakage, noise, protection, startup, shutdown, and fault behavior as applicable. Show the source of each acceptance limit and link calculations, simulations, or measurements used to close the difference.
Mechanical fields should cover package drawing, pinout, polarity, dimensions, height, mass when relevant, land pattern, courtyard, keep-out area, exposed pad, coplanarity, connector keying, retention, mating requirements, and enclosure clearance. Thermal fields should address power dissipation, junction or case limit, thermal resistance, heatsinking, airflow, interface material, and temperature margin under stated conditions.
Do not fill the checklist with copied specifications that have no relationship to the design. A short rationale such as “not used by this circuit because the pin is tied low” is more useful than a long unreviewed table. The reviewer should be able to see which characteristics matter, how much margin exists, and what remains unmeasured.
Record package and manufacturing-process consequences
Include package type, termination finish, moisture-sensitivity level, storage and bake requirements, peak reflow condition, floor life, packing method, tape orientation, feeder or tray requirement, placement-library status, stencil impact, reflow-profile impact, inspection access, X-ray need, cleaning or coating compatibility, and rework instruction. Link the package drawing and controlled process document revisions.
Ask whether the existing process can detect an incorrect orientation, wrong package, open joint, void, insufficient solder, bridging, coplanarity issue, or hidden-joint defect. If the alternate changes the inspection method or program, create an action and owner before the sample build.
The PCBA engineering change-control workflow should carry updated libraries, work instructions, inspection programs, and effectivity. The checklist records the required change; the controlled document system releases it.
Physical status and the checklist record should agree so an unresolved sample cannot enter an approved flow. Link Firmware and Test Evidence to Alternate Rule Approval Records
Alternate rule approval records should reference the firmware, programming, calibration, and test evidence without copying protected files into an uncontrolled checklist.
For programmable or communicating devices, record device IDs, register-map differences, boot behavior, initialization, drivers, firmware branches, programming algorithms, memory layout, address options, calibration data, security settings, errata, and diagnostic response. State whether the existing firmware recognizes the candidate and whether a firmware change limits the release to a named version.
List every verification activity with a test ID, method, sample condition, equipment, acceptance limit, raw-data location, result, and reviewer. Include visual inspection, measurement, programming, boundary scan, in-circuit test, functional test, bench test, thermal check, environmental test, and system regression only when they address a named risk.
A pass result needs a coverage statement. The PCBA test-coverage plan helps connect each changed characteristic to an observable test or an explicit residual risk. Record first-pass results and any rework separately from the final disposition.
Define the controlled sample and evidence package
When the review requires hardware, assign a sample-build reference before material enters production. Record baseline and candidate lots, board and BOM revisions, firmware, build date, line or equipment reference, process revision, quantity started, quantity completed, first-pass result, failures, rework, scrap, deviations, and retained samples. Keep baseline, candidate, failed, and reworked units distinguishable.
Attach or link the approved test plan before execution. After the build, link raw measurements, inspection images, machine or test logs, nonconformance records, failure analysis, corrective actions, and the signed result summary. A photograph without a sample ID and criterion is context, not acceptance evidence.
State what the sample can support. A small build may demonstrate fit, placement, solderability, programming, or function under the tested conditions. It normally cannot establish a broad lifetime or field-reliability claim. The checklist should preserve that boundary in the final decision.
The checklist should tie sample quantity, board revision, firmware, build condition, and disposition to one controlled reference. Link Compliance and Lifecycle Evidence to Alternate Rule Approval Records
Ask whether the component appears in a regulated construction, critical-component list, safety file, risk-control document, environmental declaration, customer drawing, approved manufacturer list, or contractual source restriction. Record the exact document, revision, scope, issuer, and covered part or family. A company-level certificate does not automatically cover the candidate, site, process, or product.
Lifecycle fields should include current manufacturer status, change notices, last-time-buy dates, expected availability horizon, alternate-source plan, and the date each status was verified. Link these fields to the component lifecycle risk workflow when the decision addresses shortage or obsolescence.
Customer approval should be explicit when the agreement, drawing, regulated file, or risk level requires it. Record the authorized person, approved scope, date, attached response, and any conditions. Silence, an informal chat, or approval of a quote should not be converted into technical approval.
Use four decision states instead of a vague approval box
The checklist should support Approved, Approved with conditions, Hold, and Rejected. Each state needs a definition. Approved closes every required line for the stated scope. Approved with conditions names limits, monitoring, expiry, or follow-up. Hold lists missing evidence, owner, and due date. Rejected identifies the failed criterion and whether new evidence can reopen the review.
Decision state
Required statement
Material action
Reopen rule
Approved
Evidence closes all required differences for the named scope
Use only within effectivity and approved source controls
Reopen on listed change or evidence expiry
Approved with conditions
Conditions, monitoring, owner, limit and review date are explicit
Segregate or limit quantity as stated
Reopen when a condition fails or expires
Hold
Missing item, owner, due date and next review are recorded
Do not release unresolved material to the approved flow
Resume when cited evidence becomes available
Rejected
Failed criterion and reason are documented
Return, quarantine, or disposition under the applicable process
Start a new revision only with changed evidence or scope
Set Effectivity and Reopening Conditions for Alternate Rule Approval Records
Limit alternate rule approval records to named products, revisions, lots, suppliers, quantities, and dates, then define which change reopens the decision.
Effectivity should name the product, assembly, board and BOM revisions, firmware, test program, approved manufacturer and source, production site or process when relevant, quantity or date boundary, and any customer or regional configuration. Do not approve “all future builds” unless the evidence and authority actually support that scope.
Add reopening triggers before signatures: manufacturer product-change notice, datasheet or drawing revision, package or site change, new source, lot anomaly, field failure, process change, firmware or test-limit change, regulatory update, product reuse, evidence expiry, or failure of a stated monitoring condition. Assign an owner for monitoring each trigger.
Version the checklist after every scope, evidence, or decision change. Preserve prior revisions and their effectivity so the team can reconstruct which rule applied to a specific quote, purchase order, build, or shipped lot.
Keep baseline, candidate, failed, reworked, and released samples distinguishable throughout verification. Use the checklist differently at each commercial and build gate
RFQ and quotation gate
At RFQ, the checklist should expose assumptions before they enter price or lead time. Mark the baseline BOM revision, candidate identity, reason for proposing it, known differences, required customer constraints, source status, and unresolved evidence. The quotation should state whether it uses the approved baseline, assumes a future approval, or excludes the candidate. A price comparison should not make an open technical line appear closed.
Material commitment gate
Before a purchase order, reservation, or non-cancellable commitment, confirm the exact manufacturer part number, approved source, required quantity, lot controls, shelf or floor-life conditions, traceability, and the decision authority for the intended scope. Record whether purchasing may buy samples only, a capped quantity under deviation, or production material. Link the commercial commitment to the checklist revision so later changes do not alter the basis silently.
Sample and first-build gate
Before the first candidate build, close the test plan, sample identity, board and firmware revisions, process changes, acceptance criteria, inspection method, rework boundary, and evidence owners. During execution, update actual quantities, first-pass results, failures, rework, measurements, and deviations. Do not change acceptance criteria after seeing the result without recording a new revision and rationale.
Production and repeat-order gate
Production release should confirm that every required checklist line is closed or covered by an explicit condition. Verify that controlled BOMs, libraries, work instructions, inspection programs, test limits, source controls, and customer approvals carry the same effectivity. For a repeat order, do not copy the old Approved state automatically. Recheck manufacturer status, source, lot condition, change notices, document revisions, product configuration, monitoring results, expiry, and reopening triggers.
A useful checklist produces different actions at these gates while preserving one evidence chain. It can support an early estimate without authorizing production, allow a limited sample without changing the approved BOM, and later release a bounded production scope without losing the assumptions that led to the decision. This separation reduces disputes because procurement, engineering, quality, and the customer can see what the current state permits.
FAQ about a PCBA alternate rules checklist
Should every alternate use the same verification depth?
No. Use the same checklist blocks, but scale the required evidence to the observed difference, design margin, failure effect, detectability, compliance scope, and evidence quality. Record why a block is not applicable.
Can purchasing complete the checklist alone?
Purchasing can provide source, quantity, price, lead-time, and lifecycle inputs. Engineering and quality owners must close technical, process, test, traceability, and compliance fields. The named release authority controls the final scope.
What happens when one required field is missing?
Mark the line Hold, identify the missing evidence, assign an owner and due date, and state the blocked action. Do not replace the missing value with “TBD” inside an Approved record.
How often should an approved checklist be reviewed?
Review it when a listed reopening trigger occurs and at any stated expiry or monitoring date. The team should also confirm that the cited source documents and effectivity remain current before reuse on a repeat order.
Next action: Assemble the current BOM revision, proposed full part number, manufacturer documents, supplied-material identity, product constraints, and required decision date. Ask GNS for an alternate-rule checklist review before material commitment or a controlled sample build.
