A PCBA RFQ file index should control the exact project, assembly, configuration, file class, internal revision, source, identifier, effectivity, purpose, status, controlling relationship and supersession used for one quotation response. It should also record access limits, recipients, open conflicts, quote revision and the frozen baseline accepted by both parties.
The index is not merely a list of expected attachments. An RFQ package can contain Gerber data, a BOM, placement files, drawings, firmware and test information while mixing revisions or variants. Without a controlling index, a supplier may price a technically valid file that does not belong to the requested assembly or quantity stage.
This control is narrower than deciding whether the whole RFQ is complete enough to send. It identifies which versions and assumptions a supplier is allowed to use. The file-index error review traces mismatches into priced work, while the closure checklist tests the evidence used to resolve them. Technical verification, price reasonableness, delivery commitment and project acceptance remain separate reviews.
Freeze the PCBA RFQ file index before review starts
Assign a unique RFQ baseline identifier and revision. Record project, product, assembly, PCB and PCBA revisions, variants, effectivity, quantity by configuration, workshare, buyer sender, supplier recipient and issue date. Link the baseline to the preserved source archive.
If the RFQ is sent in several transfers, record each receipt and state whether it supplements or replaces the baseline. Do not let a later email attachment silently overwrite a file that another reviewer is using. A new object should enter through a controlled index change.
give every supplier response its own quote identifier and link it to the RFQ baseline revision. If a response uses a different assumption or subset, record that deviation. This makes it possible to compare revised quotations without losing the object set behind each price.
Preserve earlier baselines and responses. A new archive name should not erase the inputs used for a prior quote. When a file changes, identify affected scope, quantity, test, sourcing and commercial assumptions.
Give every indexed object a stable identity
Create one row per file or controlled object. Retain source file name, file class, project identifier, assembly or configuration, internal revision, format, size or checksum when used, source, receipt time, access location, status and permitted purpose.
Use internal revision rather than relying on file-system dates. A file can be copied, downloaded or recompressed without changing design revision. If an object lacks an internal identifier, mark the limitation and request confirmation from the authorised owner.
Record derived files separately. If a reviewer converts manufacturing data for a viewer, retain the unchanged source, conversion method, input identifier and output identifier. A derived rendering can support review but should not silently become the controlling quotation object.
Use a hash when the parties need to prove byte-level identity, but do not treat matching hashes as technical approval. A hash shows that two files are the same digital object. It does not prove correct revision, project relationship or manufacturability.
A process map shows sequence; the RFQ file index must still identify the exact fabrication, assembly, material and test objects used for quotation.
Index field
Control purpose
Failure prevented
Readback question
Project and configuration
Bind the object to one assembly and variant
Pricing another product or option
Which build does this object describe?
Internal revision and effectivity
Identify the active design state
Using a timestamp as revision evidence
When and where does this revision apply?
Status and supersession
Separate active, reference and obsolete objects
Two files appearing active
What replaced this object?
Purpose and quote baseline
Limit how the supplier may use the file
Applying review data to another decision
Which response relies on this object?
Classify fabrication and assembly data accurately
Distinguish fabrication data, drill information, fabrication drawing, stack-up requirement, assembly drawing, placement data, panel data and mechanical model. A folder called “Gerber” may contain several object types. The index should identify the class and intended use of each file.
Ucamco maintains the official Gerber Layer Format specification and Gerber Job File resources. IPC describes IPC-2581 as an intelligent data format for printed board and assembly product descriptions. Those sources help identify formats and possible structured content. They do not prove that a supplied export is complete, correct or current.
Record the controlling relationship between fabrication data and drawings. A drawing may contain material, finish, tolerance or process notes that are not visible from filenames. If a note conflicts with the data set, mark the conflict and hold dependent assumptions until an authorised owner decides precedence.
The public project review before quotation page describes a later review path. It does not verify the indexed file set or establish a quotation baseline.
Link BOM, placement, drawing and variant objects
Index the BOM and AVL by assembly, variant and revision. Record whether they are controlling, reference only or superseded. Link them to the active placement data and assembly drawing. If reference designators, quantities, DNP rules or options differ, record the conflict rather than choosing a source by habit.
Separate candidates from approved alternates. A market-research file or supplier suggestion should not appear as an active AVL or BOM revision without buyer authority. Index the candidate’s purpose, source, reviewer and current state.
Record sourcing responsibility by line or controlled group when it affects the quote. Buyer-supplied, supplier-sourced and mixed material can change pricing, shortages, traceability and disposition assumptions. The file index should point to the workshare record that controls these conditions.
The components management page provides service context, not evidence of part approval, stock, authenticity or sourcing responsibility for the RFQ.
Index firmware, programming, test and fixture scope
For firmware, retain image identifier, target device, compatible hardware, release state, source and permitted purpose. Keep keys and credentials in approved systems. The index should reference the authorised path without copying protected values.
For programming, identify the instruction revision, interface, tool or fixture dependency and expected verification output. A firmware file without an applicable hardware relationship should not become a priced programming assumption.
For test, index the procedure, limits, fixture, cables, expected result record and disposition instruction when supplied. Separate test-method development from execution and product acceptance. The quote baseline should state which work line each object supports.
For buyer-owned fixtures or samples, record controlled identifier, revision, purpose, availability evidence, interface, responsibility and relevant return or modification conditions. A photograph does not prove compatibility and should remain a reference object.
Before setup, the index should distinguish active inputs from superseded ones so the wrong program or material list does not reach the line.
Control status, effectivity and supersession
For a PCBA RFQ file index, the NIST configuration-management guidance provides background for baseline identity and change records; the buyer’s controlled RFQ still defines the quotation scope.
Use defined states such as active for quote, conditional, reference only, pending confirmation, superseded, not applicable and out of scope. Each state should determine allowed use. Avoid “latest,” “old,” “good” or “final” without a controlled revision and owner.
Record effectivity when a revision applies by prototype build, lot, date, serial boundary, purchase order or another buyer-defined condition. If effectivity is missing, identify which pricing or scope decision remains open. Do not infer a cutoff.
When replacing a file, point the new row to the superseded object and record reason, authority and affected relationships. Keep the earlier object in the index history. Removing it entirely makes an earlier quotation impossible to reconstruct.
Check for duplicate active objects. Two BOMs or placement files can be individually valid but incompatible for the same assembly. Hold the dependent quote line until the controlling source is confirmed.
Connect quantity, workshare and assumptions to the index
Record quantity by configuration and stage. Prototype, validation, pilot and production requests may use different panel, sourcing, programming, test and documentation assumptions. Link each quote response to the quantity table it used.
Map workshare lines to indexed objects. A component price relies on BOM and sourcing responsibility. Programming relies on firmware and interface evidence. Functional-test pricing relies on method, limits and fixture assumptions. A single RFQ archive should not hide which evidence controls each line.
Index assumptions as controlled objects or linked records. State the observed gap, provisional condition, affected quote line, owner, expiry and action if rejected. Do not bury an assumption only in supplier notes.
The public PCB assembly services page does not define the RFQ quantity, workshare, price, capacity or delivery commitment.
Separate carriers support lot control; the file index links quantity, stage, test scope and workshare to the same quotation baseline.
Control access and authorised recipients
Index restricted schematics, firmware, test records, security data and commercial files by information owner, approved recipient, purpose, system path, access scope and expiry. A file can exist without being available to the quotation reviewer.
Do not send restricted content through a personal account or unapproved service to make the archive appear complete. If the quote depends on the object, hold the affected line or use a bounded alternative approved by the information owner.
Record recipient acknowledgement separately from technical or commercial acceptance. A download receipt proves access, not agreement with revision, scope or assumptions.
The quality assurance page may help frame record questions. It does not prove project conformity or authorise access to restricted evidence.
Synchronise archives, folders and the controlling index
The index should control the archive, not be reconstructed from it after the quote is prepared. Give each issued archive a baseline identifier and record its relationship to the index revision. If the file bundle is split because of size or access restrictions, identify every part and the recipient allowed to use it.
Meanwhile, check that archive paths and folder names do not create a second revision system. Labels such as “latest,” “new,” “customer update” or “final” can help a person navigate, but they should not determine status. The index row supplies internal revision, effectivity, active state and supersession. Rename working copies only when the path back to the received object remains intact.
When a transfer service changes file timestamps or recompresses an archive, use the object identifier, internal revision and checksum when required to establish digital identity. Do not treat the transfer date as the design date. If the byte-level object changes, record whether it is an authorised replacement, a derived file or an unexplained difference.
At issue and receipt, reconcile the index with the archive. The buyer should confirm that every active row intended for transfer is present or available through the approved restricted route. The supplier should confirm that every received object maps to a row or is recorded as an exception. A folder count cannot replace this comparison.
Separate derived outputs from buyer-supplied objects
control generated outputs separately. Supplier question lists, converted views, component research, DFM findings and quotation worksheets should have their own identifiers and should point to the input baseline. They may become project records, but they should not enter the buyer-supplied file set as though they were original design objects.
keep local working structures from leaking into the commercial baseline. Temporary extraction folders, automatic duplicate names and operating-system metadata are not quotation objects. Exclude them explicitly or mark them administrative so another reviewer does not count them as additional revisions.
Before sending a revised archive, run a delta comparison between index revisions. List added, replaced, superseded and unchanged objects, then identify affected quote lines and assumptions. Therefore, the supplier receives a bounded change request instead of an untraceable full review.
after receipt, freeze the supplier’s acknowledged index version. If the buyer later finds that a file was missing from the transfer, create a correction event with date, object and impact. Do not silently add the file to the shared folder and leave the response tied to an index the supplier never received.
Freeze the index for each quotation response
Before pricing, export or freeze the active index and assign its revision to the response. The supplier should read back project identity, configuration, quantity, workshare, active objects, open conflicts, assumptions and excluded files. Record the reviewer and date.
If a file changes while pricing is open, issue an index delta. Identify the changed object, old and new revisions, reason, effectivity, affected quote lines and whether the existing response remains valid, becomes conditional or needs revision.
Do not accept a revised quotation without linking it to the index revision and supplier assumptions. A price difference cannot be interpreted safely if the underlying object set also changed.
Index change state
Object condition
Quote treatment
Required record
No affected change
Active objects and assumptions match the frozen index
Continue review of the linked response
Index revision and readback
Conditional delta
Change permits bounded pricing under a written assumption
Retain condition on affected lines
Delta, owner, expiry and acceptance
Hold
Controlling object or relationship is unresolved
Stop affected quote lines
Conflict, consequence and release evidence
Revise quote
Change affects quantity, workshare, material, test or another priced input
Issue a response tied to the new index
Old/new baseline and changed assumptions
Read back the index before a commercial comparison
A second authorised reviewer should select each major quote line and trace it to active indexed objects, revisions, effectivity, workshare and assumptions. Compare source files with the frozen index rather than relying on the archive name.
Check for duplicate active objects, missing supersession, stale relationships, inaccessible evidence and response-index mismatch. Confirm that the supplier received the same baseline the buyer intends to compare.
Only then should the parties compare commercial responses. The index does not establish whether a price is reasonable or whether a schedule is committed. It establishes what inputs the response used.
Record unresolved comparison items before moving to negotiation. If two responses use different approved alternates, test assumptions, sourcing splits or quantity stages, they are not directly comparable even when both indexes are controlled. Align the baseline or keep the difference visible beside the commercial result. Do not normalise supplier assumptions without the responsible technical and commercial owners.
A saved operational record has a time and scope; the RFQ index should apply the same discipline to every frozen quotation input.
Hand off a file index that survives revision
The package should contain the RFQ baseline, object rows, active and superseded relationships, effectivity, quantities, workshare links, firmware and test scope, access conditions, open conflicts, assumptions, quote-response link and change history.
For an initial review, provide the current index, source archive name, assembly and configurations, file revisions, quantities, test and firmware scope, superseded items, quote revision and unresolved conflicts.
State the index owner and next review date so later transfers cannot bypass the frozen baseline.
Preserve it with every response.
Review a PCBA RFQ file index
FAQ
Is a PCBA RFQ file index the same as an RFQ checklist?
No. A checklist may ask whether required inputs exist. The file index controls the exact object, revision, effectivity, purpose, status and quotation response. It makes the baseline reproducible.
Should a PCBA RFQ file index include file hashes?
Hashes can confirm byte-level identity when both parties need that control. They do not prove correct revision, configuration, file relationships, technical validity or approval, so the index still needs those fields.
What happens when an RFQ file changes during quotation?
Issue an index delta that identifies old and new objects, reason, effectivity and affected quote lines. Decide whether the response remains valid, becomes conditional, is held or must be revised.
Does a frozen PCBA RFQ index approve the project?
No. It preserves the inputs and assumptions used for one response. Technical findings, price comparison, commercial agreement, capacity, delivery and production release remain separate decisions.