Direct answer: when is an engineering change ready to build?
A change is ready for the affected work only when the current and proposed configurations are identified, the technical and commercial impact is reviewed, the authorized owner has approved the decision, and the implementation boundary is unambiguous. That boundary may be a named work order, lot, serial range or another project-defined identifier. Each affected material and product state needs a disposition. A revised file alone does not answer whether the next shipment contains the old or new configuration.
This guide covers the transition between approved versions during repeat production. For assembling the first controlled data package, see the design transfer release checklist. For identifying an obsolete or single-source part before a change is proposed, use the component lifecycle risk guide.
Build a change request around the affected configuration
Begin with a change identifier and a short reason: component availability, interface correction, field finding, test update or customer requirement. Separate a requested change from an approved release. The product owner should define who can authorize a design change, a temporary deviation and a manufacturing process adjustment under the project agreement.
| Record field | Buyer question | Evidence to retain |
|---|---|---|
| Current and proposed baseline | Which PCB, assembly, BOM, firmware, test and mechanical revisions are involved? | Linked document IDs and approval states |
| Change reason and impact | What problem is being solved, and what interfaces or acceptance limits may change? | Engineering comparison and open risks |
| Approval authority | Who may accept the product change, and who may release its manufacturing instructions? | Named decision and date; customer approval where required |
| Implementation boundary | Which work order or identifiable units use the new configuration first? | Effectivity rule and cutover record |
| Material and product status | What happens to stock, work in progress, finished units and returns? | Quantity, location, disposition and owner by bucket |
| Verification and closeout | What evidence shows the changed build meets the agreed requirements? | Test plan, result, first-build review and as-built record |
A supplier product-change notice can be an input, not the final PCBA approval. For example, Texas Instruments explains that its notifiable semiconductor changes identify affected products and anticipated form, fit, function, quality or reliability impact. The assembly owner must still decide whether that supplier change affects the specific approved board and its tests.
Set effectivity at a traceable build boundary
“Use the new revision next month” is hard to audit when orders overlap or stock is in transit. Name the first affected work order or lot and the rule for mixed inventory. If the product needs unit-level identification, record the relevant serial range. If only lot-level traceability is agreed, do not imply a serial-level history exists. Record the last authorized old build and the first authorized new build, including any overlap or approved rework.
Consider a hypothetical connector change on a controller PCBA. Thirty old connectors are in stores, ten boards are in process and eight finished boards await shipment. The buyer should not apply a single blanket “replace” instruction. The thirty components, ten boards and eight units have different access, test and commercial consequences. The decision record should state which can be used as approved, which must be held or reworked, which require further validation, and whether any shipment restriction applies. These quantities illustrate the method and are not Keep Best project data.
The approved BOM, placement information and assembly instruction must agree for the first new build. If a programmed device changes, the firmware release manifest and verification record should identify the compatible hardware and software combination. A file name or date alone is too weak to define effectivity.
Disposition every affected stock and product bucket
Ask purchasing, manufacturing, quality and the product owner to work from one inventory snapshot. “On order” is different from “received and accepted,” and a finished unit may need a different decision from loose parts. The available options below are review choices, not automatic permissions.
| Affected bucket | Decision to document | Record that closes it |
|---|---|---|
| Open purchase orders and in-transit parts | Continue, amend, cancel or segregate by approved part and delivery timing | Supplier confirmation and revised order or hold |
| Accepted stock and customer consignment | Use under old revision, reserve, return, requalify or scrap as authorized | Count, ownership, location and disposition approval |
| Work in progress | Complete under old instructions, stop, rework or split into identified lots | Traveler/work-order instruction and affected-unit list |
| Finished goods and shipped units | Ship under approved old configuration, hold, retrofit or investigate field scope | Shipment or serial/lot record and customer decision |
| Fixtures, firmware and test limits | Retain, revise or validate against the new hardware configuration | Versioned asset, test result and release approval |
Do not consume customer-owned material or scrap obsolete stock without the agreed commercial authority. The turnkey and consigned sourcing guide helps define ownership and excess-material terms before the change. A supplier substitute also needs the product owner’s technical approval rather than a purchasing-only decision.
Check the first changed build and close the record
Choose the verification depth from the actual change. A label correction may need document and identity checks; a connector, power component or firmware change may affect interface fit, electrical behavior, programming, functional test or system integration. Agree the comparison, sample or first-article approach, acceptance criteria and decision owner before treating the new revision as repeatable. A passing board-level test does not establish every system-level or field requirement.
At closeout, keep the approved change, effectivity boundary, stock dispositions, updated build data and as-built identifiers together. If a field issue appears later, the team should be able to distinguish units built before, during and after the change. The electronics contract manufacturing service describes how a defined work package connects purchasing, assembly, test and repeat orders.
Questions to send with an industrial PCBA RFQ or repeat-order change
- What is the released product configuration today, and which document or part is proposed to change?
- Which purchase orders, received stock, work orders, finished units and shipments could be affected?
- Who owns the material and who can approve use, rework, return or scrap?
- What is the first identified build using the new revision, and how will mixed lots be prevented or recorded?
- Which interface, firmware, fixture and test checks need to be repeated?
- What evidence will close the change before unrestricted repeat production?
Send the current BOM, revision list, proposed change and available stock picture through the project enquiry form to scope the manufacturing discussion. List missing data as open questions; confidential files can follow the agreed NDA process.
Source and scope notes
The decision structure is informed by NASA’s public configuration-management guidance, the ECSS configuration and information management standard overview and the TI supplier-notification explanation above. NASA and ECSS describe controlled baselines, change decisions and as-built records in their own domains; they are not claims that Keep Best operates under those programs or holds a related certification. The tables are buyer preparation tools. The actual approval authority, traceability depth, validation and inventory disposition must be agreed for each product.