Use RFQ file index closure to identify the controlled objects the buyer sent, their active revisions, each unresolved condition and owner, the recorded approvals, and the index revision supporting the supplier’s quotation. A second reviewer should be able to reconstruct the quote baseline without relying on email memory or a folder called “final.”
Apply the checklist after defining the PCBA RFQ file index and before closing an open issue. Use the file-index error review when a mismatch may have changed priced work. Keep manufacturability, price reasonableness, and delivery decisions in their separate evidence paths.
Test the record with one priced work line. Trace it to the active design and commercial inputs, then read back the same baseline from the buyer and supplier records. The index issue remains open when that path stops at a filename, an unchecked spreadsheet cell, or an unrecorded phone call.
Define the RFQ File Index Closure Question
State the exact question that the evidence must answer. “RFQ files reviewed” is too broad. A useful closure question names the project, assembly, configuration, quote revision, affected work line, observed gap, required evidence, owner, approver, and due date.
Separate existence, identity, relationship, authority, and acceptance. A file may belong to another product, carry a superseded revision, remain unavailable to the supplier, or lack approval for quotation use even after review.
The public PCBA project review before quotation page describes broader review context. It does not close a specific file-index exception or approve a buyer revision.
Identify every evidence object without changing the source
Preserve the received source object. Record its original filename, controlled identifier, internal revision, source, receipt time, file class, assembly or configuration, and approved storage location. If byte-level identity matters, add a checksum, but retain the business identity and internal revision as separate fields.
A checksum answers whether two digital objects are identical. It does not show that the object is correct for the requested build. File-system dates are also weak revision evidence because copying, extracting, or transferring a file may change them. Use the revision inside the controlled object or obtain written confirmation from the authorised owner.
Index reviewer-created files as derived objects
When a reviewer creates a PDF rendering, viewer export, component research sheet, or marked-up screenshot, index it as a derived object. Record its source, purpose, creator, date, and limitation. Do not place a derived file into the buyer-supplied baseline as if it were original design data.
IPC describes IPC-2581 as a structured format that can contain content, history, BOM, ECAD, and AVL information. That official description supports the need to preserve object classes and relationships. It does not prove that a particular customer export is current or complete.
Separate racks keep board groups in distinct physical locations. Give received, derived, superseded, and approved files equally distinct index states.
Evidence field
What to record
Closure test
Common false closure
Object identity
Controlled ID, filename, class, assembly, configuration
A second reviewer finds the same source object
“It is in the folder”
Revision and effectivity
Internal revision and build boundary
Applicable build and option are explicit
Newest file date is assumed active
Relationship
Links to BOM, placement, drawing, test, firmware, quantity, or workshare
Conflicting objects are resolved
Each file is checked in isolation
Authority
Decision owner, approver, date, reason
Authority matches the affected decision
Supplier acknowledgement is treated as buyer approval
Quote link
RFQ baseline and response revision
Priced line traces to the evidence
Evidence was added after pricing without re-readback
Bind evidence to one assembly and configuration
Record project, product, assembly number, PCB revision, PCBA revision, option, population variant, and effectivity. If the RFQ contains several configurations, give each one a stable identifier and state which indexed objects are shared.
Do not close a variant gap with a general statement such as “same board.” The bare PCB may be shared while BOM options, placements, programming images, test limits, labels, or quantities differ. Identify the relationship that is actually common and keep the remaining differences visible.
For a DNP or option decision, preserve the controlling source and the accepted rule. If the BOM, placement data, and assembly drawing disagree, record which object controls each decision. An approval that resolves component population may not resolve test coverage or firmware compatibility.
The PCB assembly services page gives service context. It is not evidence of project identity, selected configuration, quantity, capacity, or delivery for an RFQ.
Record revision, effectivity, and supersession together
Every active item needs an internal revision and a statement of where it applies. Effectivity may be tied to prototype stage, lot, date, serial boundary, purchase order, or another buyer-defined condition. If no effectivity rule exists, record the uncertainty and the decisions it blocks.
When an object is replaced, keep the previous row. Add the new object, identify the superseded object, record the reason and authority, and state whether the existing quote remains valid. Deleting the old row prevents later reconstruction of the response.
Use clear states such as active for quote, conditional, reference only, pending confirmation, superseded, out of scope, and not applicable. Define the permitted action for each state. “Old,” “good,” “latest,” and “final” are navigation labels, not controlled states.
NIST SP 800-128 defines a baseline as an agreed set of specifications changed through control procedures. It is a security configuration publication, not a PCBA requirement. Its baseline and change-control concepts are useful analogies for preserving a quotation input set and its history.
Prove Priced-Work Relationships for RFQ File Index Closure
Map each commercial work line to the objects it uses. Tie PCB fabrication to fabrication data, drill data, stack-up and drawings, and tie component pricing to the BOM, approved parts, sourcing responsibility, quantity, and substitutions. For assembly, record placement, assembly notes, panel conditions, and inspection scope. Keep programming and test linked to their own instructions, interfaces, limits, and fixtures.
The closure record should answer whether all objects describe the same configuration and effectivity. It should also show which conflicts owners accepted, which uncertainties owners converted into bounded assumptions, and which gaps forced a hold.
An RFQ can be complete enough to receive a budgetary response while remaining unsuitable for a firm production commitment. Label the response type and the unresolved inputs. Do not let a budgetary assumption become an approved production baseline through repeated copying.
The components management page may help frame material questions. It does not prove an approved manufacturer part number, availability, authenticity, allocation, or price for the current RFQ.
A physical assembly remains the review object; filenames and folder dates cannot replace its controlled identity and configuration. Separate Review States in RFQ File Index Closure
Keep receipt, identity verification, and buyer approval as separate fields, with a responsible person and timestamp for each. Different people may own the three events.
A supplier acknowledgement can confirm receipt and readable access. It cannot approve the buyer’s design revision, authorised alternates, configuration effectivity, or acceptance criteria. An engineering approval may resolve technical applicability without accepting price or delivery.
When a buyer delegates authority, record the delegation scope. Someone authorised to clarify a filename may not be authorised to approve a substitute component or release a revised quotation.
Review event
Evidence required
Owner
What it does not prove
Receipt
Transfer record, object count, accessible path
Sender and recipient
Correct revision or applicability
Identity check
Controlled ID, internal revision, configuration
Document control or engineering
Technical sufficiency
Relationship check
Cross-object comparison and conflict record
Relevant technical owner
Commercial acceptance
Buyer approval
Decision, effectivity, authority, reason
Authorised buyer owner
Supplier implementation
Supplier readback
Baseline revision, assumptions, exceptions
Quotation owner
Price reasonableness or schedule commitment
Use exception records that state consequence and next action
An exception record should name the observed condition, affected object, affected work line, immediate consequence, allowed interim action, prohibited action, owner, due date, closure evidence, and re-open condition.
Avoid “TBC” without context. Instead, write what remains unknown and what the supplier may do while it is unknown. For example: “Functional-test limits revision is unconfirmed; estimate excludes test execution; buyer test owner to issue limits or accept a separate development line before firm quotation.”
Teams must show a bounded assumption in the quote instead of hiding it only in an internal checklist. Link the assumption to the index and response. State what happens if the buyer rejects it or provides a different input.
If an exception changes quantity, workshare, approved parts, tooling, programming, test, or delivery basis, trigger a quote-impact review. Closure of the file question may require a revised commercial response.
Control restricted and unavailable information
Some schematics, firmware, security material, test data, or commercial files may require restricted access. Record the owner, approved system, recipient, purpose, access period, and the quote line that depends on the object. Do not duplicate protected content into an uncontrolled checklist.
If the supplier cannot access a required object, the evidence state is unavailable, not complete. The affected work can be held, excluded, or estimated under an approved condition. Record which treatment applies.
Access logs establish delivery and retrieval events. They do not prove that the recipient understood or accepted the contents. Obtain a separate readback of the baseline and exceptions.
Keep protected project details in the buyer’s approved collaboration system under the applicable contractual controls.
Numbered rack positions separate board groups on the factory floor. Record the corresponding file revision and effectivity in the digital index. Freeze RFQ File Index Closure Evidence for Each Response
Assign a revision to the evidence checklist and link it to the RFQ baseline and supplier response. Preserve the issued copy. If a source object changes during pricing, create a delta showing added, removed, replaced, superseded, and unchanged objects.
For each delta, identify affected work lines and supplier assumptions. Decide whether the response remains valid, becomes conditional, requires partial repricing, or must be replaced. Do not silently update a shared folder and leave the quote linked to an earlier index.
At readback, select representative lines for PCB fabrication, component supply, assembly, programming, test, tooling, and documentation where applicable. Trace each line to active objects and recorded assumptions. A successful sample does not replace review of a known conflict.
The quality assurance page is general service information. It does not verify a project record, conformity result, approved exception, or quotation baseline.
Apply explicit closure and re-open rules
Close an item only when the required object exists, reviewers have verified identity and relationship, the record names the authority, the authorised owner approved the decision, the supplier completed readback where needed, and the team disposed of quote impact. The closure date should follow the last required event.
Re-open the item when a linked object changes, effectivity shifts, a reviewer discovers a conflict, an owner withdraws access, a buyer rejects an assumption, or a new quotation uses a different baseline. Keep the previous closure event in history.
Use a four-state outcome for practical control: close, close with stated condition, hold affected work, or revise the quotation. Each state should tell the next reviewer what action is permitted.
Schedule periodic second-reviewer samples and use the closed-item procedure below. Any missing object, authority, relationship, or quote link becomes a corrective action for the record system.
The screen shows an inspection result beside the board under review. Link the recorded result to that board and its active revision. Define the minimum closure packet before reviewers sign
Before review starts, agree on the smallest evidence packet that can close an index issue. It should contain the source object or approved access path, controlled identifier, internal revision, assembly and configuration, relationship to the affected work line, decision owner, approver, quote-impact disposition, and supplier readback. A screenshot of a folder or a message saying that files were received is not this packet.
Use the same packet definition for every open item, but do not force every item through the same approval role. A BOM substitution, placement conflict, test-limit gap, quantity change, and commercial exclusion affect different decisions. The record must send each issue to the owner authorised to resolve that decision and show what remains prohibited until approval arrives.
Test the packet on one closed issue before applying it to the full RFQ. If a second reviewer cannot find the source, identify the applicable revision, trace the approval, and locate the same condition in the supplier response, reopen the issue.
Run the RFQ File Index Closure Review
For each open item, capture the following fields:
Project, assembly, configuration, RFQ baseline, and quote revision.
Closure question and affected work line.
Source object ID, class, internal revision, source, and approved location.
Applicable effectivity and supersession relationship.
Related BOM, placement, drawing, firmware, test, quantity, and workshare objects.
Observed conflict or missing fact and its consequence.
Allowed interim assumption and prohibited action.
Evidence owner, verifier, approver, supplier readback owner, and dates.
Quote-impact disposition and response revision.
Closure evidence, closure state, and re-open trigger.
The checklist supports traceability. It does not replace design approval, DFM, component approval, quality planning, commercial review, or contractual acceptance.
Check RFQ File Index Closure Against the Response
Choose an item that affected price, test, programming, or material responsibility. Open the preserved buyer object, confirm its internal revision and configuration, trace the approval, and then locate the same assumption in the supplier response. Confirm that the response revision was issued after the decision and that no later delta changed the input. The sample fails when the supplier response omits the approved condition; reopen the item before commercial comparison.
Record the reviewer, date, sampled line, discrepancy, corrective owner, and result. Keep this audit event separate from the original approval so history remains intelligible.
FAQ
Does a checksum close an RFQ file index issue?
No. It may prove byte-level identity between two files. You still need evidence of project relationship, internal revision, effectivity, authority, and permitted quotation use.
Can an email approval serve as closure evidence?
It can if the message identifies the object, revision, decision, authority, effectivity, and quote impact, and if the team preserves it in the approved record system. A vague “looks good” is insufficient.
Who should sign the evidence checklist?
The responsible owner for each affected decision should approve it. Document control, engineering, sourcing, test, commercial review, and supplier quotation roles should not be merged into one generic signature.
When must a closed item be reopened?
Reopen it when a linked object or assumption changes, access is lost, a conflict appears, effectivity changes, or a new response uses another baseline.
Send the current index and exception for readback
Send the current file index, RFQ baseline, assembly and configuration identifiers, one unresolved exception, relevant quantity and workshare records, and the supplier response revision. Ask which objects and assumptions control the affected work line.
For a GNS readback, send the current index and one unresolved exception together with the supplier response revision. GNS can compare the records; buyer data approval, price, capacity, and delivery remain with the applicable project owners.
