A PCBA project intake checklist should retain enough evidence to reproduce one received project baseline and decide whether a named review may begin. It needs more than an attachment count. The record should identify the parties, product, assembly and configuration; control every submitted object and revision; connect related files; define quantities and workshare; state programming, test and requirement boundaries; assign authorities; record exceptions; and preserve closure evidence.
The checklist is a controlled record, not a declaration that a design is correct, manufacturable or ready for production. A package can contain a BOM, Gerber data, placement data and a test procedure while still mixing two assembly revisions. It can also appear technically complete while nobody is authorised to approve an alternate part or release restricted firmware. The checklist must expose those conditions before a quotation or specialist review inherits them.
Design the record around the next decision. The PCBA project intake decision boundary defines that gate, while engineering intake verification tests the active objects and relationships. A quotation-input review, DFM review, component-risk review and test-development discussion have different minimum evidence. The checklist should show which gate is being evaluated, what evidence that gate requires, which items are conditional and who may close each open point. This makes “ready” a bounded state that another authorised reviewer can read back.
Set the Purpose of the PCBA Project Intake Checklist
Start the header with a unique intake identifier, project name, product and assembly identity, receiving date, sender, approved recipient, checklist owner and requested output. Add the intake revision and the location of the preserved source package. If files arrive in several transfers, record each receipt as part of the same baseline or as a later delta. Do not combine transfers silently.
Name the decision this checklist supports. Examples include “open fabrication-data review for assembly A revision C,” “prepare a quotation with stated sourcing assumptions” or “estimate fixture-development scope.” The decision field prevents readers from applying a narrow intake result to another task. A file set that supports a bare-board review may not support turnkey assembly pricing or functional-test planning.
Separate the blank form from the entered record. The form defines required fields and allowed states. The entered record contains project-specific values, evidence references, reviewers and dates. Attachments provide supporting evidence. A completed-looking template without traceable inputs does not prove that the check occurred.
Use stable states such as received, verified for named use, conditional, held, superseded, reference only, not applicable and out of scope. Define each state once. Avoid free-form labels such as “okay,” “latest” or “looks complete,” because a second reviewer cannot determine what action those labels permit.
Record parties, authority and requested outputs
List the buyer, legal contracting party when confirmed, design owner, project coordinator, sourcing owner, quality owner, test owner, firmware owner, document-control owner and authorised supplier recipient. Not every project uses all of these roles, and one person may hold several roles. The checklist should still record the authority attached to each decision rather than assuming that a department name grants approval.
For each controlled object, identify who may submit it, clarify it, replace it and approve an exception. A project coordinator can maintain the record without becoming the design authority. However, a sourcing contact can provide market information without approving an electrical substitute. A test engineer can define a method without accepting a product deviation unless that authority is explicit.
Describe the requested outputs and their recipients. A supplier may be asked to return clarification questions, a manufacturability review, a component-risk list, a quotation, a test concept or several separate outputs. State the required format, due gate, confidentiality route and acceptance owner. This field prevents a technical review from being treated as commercial acceptance or a quotation from being treated as production release.
The public explanation of a PCBA project review before quotation provides a reader path for later discussion. It does not define the authority, completeness or release state of a submitted project.
Identify product, assembly, variant and effectivity
Give each configuration its own row. Record product identifier, assembly number, PCBA revision, PCB revision, hardware variant, regional option, depopulation rule and requested quantity. If one printed board supports multiple assemblies, the checklist must link each assembly to its active BOM and placement set. Similar folder names or common fabrication data do not prove that two variants use the same population.
Record effectivity when the buyer provides it. A revision may apply to a prototype lot, purchase order, date, serial boundary or engineering build. If effectivity is not supplied, mark the field open and state the dependent decision. Do not infer that the file with the newest timestamp controls the request.
Track quantities by configuration and requested workshare. Prototype, validation and production quantities may use different sourcing, panel, test or documentation assumptions. State whether the request concerns bare PCB, consigned assembly, mixed procurement, turnkey assembly, programming, inspection, test or another defined combination. Avoid a broad “full service” field that hides line-level responsibility.
Record approved sample or golden-unit references only when an authorised owner identifies them and explains their purpose. A physical sample may support visual, mechanical or test comparison, but it should not override the controlled design set without a written precedence rule.
Separate fixtures make configuration identity reviewable without suggesting that visual similarity establishes revision approval. Build an Object Register Instead of Counting Attachments
Create one row for every received or expected object. Common classes include fabrication data, drill data, fabrication drawing, stack-up requirement, assembly drawing, placement data, BOM, AVL, schematic when authorised, mechanical model, panel data, firmware, programming instruction, test procedure, fixture file, inspection requirement, change notice and approved-sample reference. The list should be tailored to the requested decision.
For each row, retain the source file name, object type, identifier, revision, format, size or checksum when used, sender, receipt time, access location, owner, status and intended use. Record whether the item is buyer-supplied, supplier-generated or derived for review. A converted viewer file should point back to its unchanged source.
Use accurate format names. Ucamco maintains the official Gerber Layer Format and Gerber Job File resources, while IPC describes IPC-2581 as an intelligent data format for printed board and assembly descriptions. Those sources help identify what a format can express. They do not prove that a specific export is current, internally consistent or authorised.
Mark missing and not-applicable objects differently. A schematic may be unavailable because access has not been approved, unnecessary for a limited fabrication review or required but not yet supplied. Those conditions lead to different actions. The record should show the reason, affected gate and owner.
Matched physical objects illustrate a controlled register; the saved checklist must still identify each source, revision and use. Map relationships and precedence across files
An object register says what exists. A relationship section says whether the objects describe the same build. Link the assembly to the PCB revision, BOM, placement data, assembly drawing, firmware and test method. For fabrication data, confirm the outline, drill, layer or stack-up context and fabrication notes. Each controlled change should identify the objects it replaces and the effectivity it changes.
Record a precedence rule when two sources can contain the same requirement. An assembly drawing may carry polarity or depopulation notes that also appear in placement data. A BOM may list an approved alternate while an AVL carries manufacturer constraints. If the sources conflict, the checklist should identify the conflict and route it to the authorised owner rather than selecting one source by habit.
Relationships should be tested at the level needed for the named review. A quotation check may compare identity, quantities and major workshare. A deeper assembly review may reconcile reference designators, side, coordinates, option rules and package context. State the depth performed so that downstream users do not assume an unperformed check.
Checklist relationship
Minimum retained evidence
Open condition
First affected gate
Assembly to PCB
Assembly ID, PCBA revision, PCB revision and effectivity
Assembly and fabrication set name different revisions
Fabrication or DFM review
BOM to placement
Designators, quantities, DNP rules, options and active revisions
Missing or option-inconsistent designators
Assembly-scope review
Hardware to firmware
Hardware revision, image ID, target device and release authority
Image compatibility or release owner absent
Programming planning
Test method to fixture
Procedure, limits, interface, fixture revision and result record
Interface or acceptance limit unresolved
Test-scope estimate
Capture sourcing, programming and test boundaries
For a PCBA project intake checklist, the NIST configuration-management guidance offers a useful model for identifying baselines and changes; the signed project record still controls readiness.
For BOM and AVL records, include manufacturer part number when supplied, manufacturer, quantity, approved-alternate state, sourcing party and restrictions. Distinguish proposed, evaluated and approved alternatives. A market listing can support availability research but cannot create design approval. Record the person or role who may accept a substitution and the evidence that decision requires.
Buyer-supplied material requires a record of confirmed ownership, quantity evidence, condition statement, traceability expectation and disposition route. Do not turn an inventory spreadsheet into a claim that material is authentic, usable or available. The components management page explains service context; project-specific sourcing decisions need approved evidence.
Firmware entries should record the controlled image identifier, target device, compatible hardware revision, authorised source, programming interface, verification output and release owner. Keep credentials and keys outside the ordinary checklist. The record should identify the approved system and recipient without copying protected values into an article, email or unrestricted tracker.
For test, record the requested operation, input conditions, fixture and cable interfaces, firmware state, sequence, limits, expected output, result format and disposition owner when supplied. “Functional test” alone is not a complete test boundary. Separate programming readback, electrical test and functional acceptance because each produces different evidence.
Control Requirements, Access, and Restricted Information
List every supplied workmanship, material, inspection, cleanliness, coating, traceability, environmental, marking, documentation and regulatory requirement by source, revision, scope and approving role. Standards terminology can route a review question, but it should not be used to infer an application class or legal obligation that the buyer has not established.
IPC’s PCBA checklist maps standards across design, fabrication, assembly, inspection and test. Use it as a domain map, not as a declaration that every listed standard applies. The checklist record should preserve the buyer’s stated requirement and the evidence used for the project-specific decision.
Track access separately from existence. A schematic, firmware package or test record may exist but remain unavailable to the current reviewer. Record the object, approved recipient, allowed purpose, transfer system, access expiry and blocked decision. Do not route restricted information through an unapproved personal account to make the checklist appear complete.
Public information about quality assurance can help a buyer frame questions. It does not prove that a project meets a standard, inspection requirement or acceptance criterion. Those conclusions belong in controlled records approved for the actual assembly.
A visibly capped path represents a superseded object; actual status and effectivity must remain in the controlled record. Turn gaps and exceptions into signable decisions
Every open point needs an object, observed condition, expected relationship, effect, owner, required evidence, due gate and status. “BOM issue” is not enough. A useful entry states that the active placement set contains designators absent from the submitted BOM, names the affected assembly and review, and identifies who must confirm the controlling revision.
Allow conditional work only within written limits. Record the assumption, permitted task, prohibited task, owner, expiry and restart trigger. For example, board-outline review may proceed while a BOM conflict holds assembly pricing. The condition should not migrate into a later quotation or release record without renewed confirmation.
Close an item with evidence, not with a comment saying “resolved.” Retain the answer, source object or decision record, authorising role, date, effectivity and the rows changed by the decision. If a file was replaced, mark the prior object superseded and preserve its relationship to the earlier baseline.
Checklist state
Meaning for the named gate
Permitted action
Closure evidence
Verified
Required identity, relationship and authority fields are confirmed
Begin only the named review
Reviewer, date, evidence references and receiving owner
Conditional
One written assumption supports bounded work
Perform permitted tasks before expiry
Assumption, limits, owner and reopen trigger
Held
Evidence or authority cannot support the next decision
Collect evidence; stop dependent work
Blocker, consequence, owner and release condition
Out of scope
Item is unnecessary for this gate
Route to a named later gate or exclude
Scope reason, receiving gate and owner
Read back the checklist before closing intake
A second authorised reviewer should reconstruct the active product, assembly, configuration, quantities, workshare, object set, cross-file relationships, requirements, access limits, assumptions and open points from the saved record. Compare it with the preserved source package, not only the coordinator’s renamed working folder.
Check that links open the intended objects and that superseded items do not appear as current. Confirm that each specialist can access the correct evidence through an approved route and that their outputs return to a controlled location. A green tracker cell or email receipt does not prove that the underlying record persisted.
Record checklist version, reviewer, review time, closure result and permitted next action. If separate gates have different states, show them separately. The intake can be verified for a fabrication-data review while held for component pricing or test planning.
Only after this readback should the named PCB assembly service discussion begin. The public service page supplies context, not project acceptance, production release, price, capacity or schedule evidence.
A complete visible connection path represents independent readback; acceptance still depends on retained evidence and authority. Reopen the Checklist When the Baseline Changes
Define restart triggers before closure. Typical triggers include a PCB or PCBA revision change, replacement file, added variant, quantity or workshare change, component alternate, firmware change, revised test limit, new fixture interface, changed requirement or different authorised recipient.
When a trigger occurs, preserve the prior checklist and create a controlled delta. Record the changed object, old and new identifiers, reason, effectivity, approving authority and affected rows or decisions. Recheck only the relationships that depend on the change, but do not leave that dependency judgment undocumented.
If impact is uncertain, hold the dependent gate. Ask the relevant owner to identify affected fabrication, sourcing, assembly, programming, inspection, test or commercial assumptions. A new archive name should not erase the evidence used for an earlier review or quotation.
Hand off a checklist another reviewer can reproduce
The final intake package should include the preserved source identifier, completed object register, configuration map, relationship checks, requirement and access records, open-point log, closure evidence, state by downstream gate and restart conditions. It should state what may proceed, what remains conditional and what is held.
For an initial discussion, provide product and assembly identifiers, active revisions, variants, quantities, workshare, manufacturing-data manifest, BOM and AVL, placement and drawings, firmware identifier, programming and test interfaces, applicable requirements, open assumptions, role owners and requested output. Use the approved route for restricted objects.
Request a PCBA intake checklist review
FAQ
Is a PCBA project intake checklist the same as an RFQ checklist?
No. An RFQ checklist usually focuses on inputs needed to price a defined scope. An intake checklist controls the received baseline, relationships, authority, exceptions and state for one or more downstream reviews. The RFQ may be one receiving gate, but it should not replace the broader record.
Does every PCBA project need every file listed in the checklist?
No. Required objects depend on the named decision and workshare. Mark an item not applicable or out of scope with a reason and receiving gate. Do not mark an unavailable but necessary object as not applicable merely to close the record.
Who should sign the PCBA intake checklist?
The checklist coordinator confirms that the record is controlled and complete for readback. Authorised owners approve decisions in their domains, and the receiving owner accepts the bounded result. Design, component, test, quality, information-release and commercial approvals may belong to different people.
When should a closed PCBA intake checklist be reopened?
Reopen affected checks when a controlled object, revision, variant, quantity, workshare, component decision, firmware, test interface, requirement or authorised recipient changes. Preserve the prior result and record the delta instead of overwriting the earlier baseline.
