A board revision is useful only when it identifies a reproducible build. Track the bare PCB, fitted assembly, firmware and approved exceptions as related but distinct records.

Separate the identities that can change

The bare board may stay unchanged while the fitted components or firmware change. Conversely, a copper revision may require a new test fixture even when the product name stays the same. Give each controlled item an identity and record which combinations form an approved product configuration.

This does not require a complicated numbering system. It requires a clear answer to a practical question: if another team receives the release record, can it determine exactly what to build and what to test?

Create a release manifest

  • Bare-board part number and fabrication revision.
  • Assembly part number, BOM revision and fitted variant.
  • Assembly drawing and placement-data revisions.
  • Firmware image, version and programming instructions when applicable.
  • Test procedure, fixture and acceptance criteria.
  • Approved deviations and the units or orders to which they apply.

Archive the files listed by the manifest together. A file named “final2” is not a reliable revision system because its meaning depends on a person’s memory. Prefer identifiers that can be referenced unambiguously in a purchase order, question log or test record.

Describe a change before releasing it

A useful change record states the reason, affected documents and disposition of existing stock or work in progress. A component substitution can affect a BOM, placement program, programming procedure and test limit. Review those dependencies rather than updating only the purchasing line.

For example, moving a connector may leave the circuit function unchanged but alter the enclosure fit and assembly fixture. A release check should identify those mechanical consequences before the revised board reaches production.

Resolve a supplier question without losing the decision

When a manufacturer asks for clarification, record the answer against the release. If the answer changes the intended product, decide whether it requires a new revision or a documented limited deviation. Do not leave a permanent construction change buried in an email attachment.

Ask the supplier to confirm the exact release accepted for production. If a replacement archive is sent, state whether the earlier package is withdrawn and how already-started work should be handled.

Use receipt and test records to close the loop

At receipt, compare board markings and documentation with the ordered configuration. Record the relevant identifiers with test results. If a field issue later appears, those records help distinguish a design revision, assembly variant and process exception.

The prototype planning guide can help define early builds, while the test and inspection overview helps connect each release with its acceptance evidence.

Move from reading to a build-ready project

Use the fabrication and assembly checklists to prepare drawings, production files and test requirements.

Open the DFM checklist