Hardware teams sometimes borrow the phrase "version control" from software without adopting the actual discipline behind it. CAD files can live in a Git repository, but the harder problem — tracking which exact configuration of components, footprints, and firmware shipped in which units, and being able to answer "what changed and why" months later — needs practices that go beyond just storing files in a repository.
Why hardware change tracking is harder than source code
A software change is fully captured by a diff — the code before and after. A hardware change often isn't fully captured by the schematic/layout diff alone: a component substitution might change electrical characteristics in ways not obvious from the file diff, a footprint change might affect assembly without changing the schematic at all, and the actual as-built unit depends on which component revision was in stock and used at assembly time, not just which was specified. Real hardware traceability requires tracking more than file history.
Board revision numbering that means something
A consistent revision scheme — distinguishing schematic-level changes, layout-only changes, and BOM-only substitutions — makes it possible to know at a glance how significant a given revision actually is, rather than treating every "Rev C" as equally different from "Rev B." Many teams use a scheme where a major revision number changes for functional/schematic changes and a minor one for layout or cosmetic changes, silkscreen fixes, or BOM substitutions that don't affect function — though the specific scheme matters less than having one applied consistently.
BOM change tracking
- Component substitutions logged explicitly — even a "drop-in equivalent" substitution should be recorded, since a part that looks equivalent on paper can behave differently in an edge case the original wasn't tested against
- Alternate/approved-vendor lists maintained deliberately, not accumulated ad hoc as sourcing issues force substitutions under time pressure
- A clear approval process for BOM changes that affect form, fit, or function — distinct from changes that are purely administrative (a new distributor for the same part)
Traceability from board revision to shipped unit
When a field issue surfaces, being able to answer "which board revision and BOM configuration is in this specific unit" is what turns a vague "some units might be affected" into a precise, actionable recall or fix scope. This requires linking manufacturing lot/serial data back to the specific board revision and BOM configuration used for that production run — a connection that has to be deliberately maintained through manufacturing, not reconstructed after the fact from incomplete records.
Engineering Change Orders (ECOs) as the actual change-control mechanism
A formal ECO process — documenting what's changing, why, what's affected (schematic, layout, firmware, documentation, certification status), and requiring sign-off before the change ships — is the hardware equivalent of a code review and merge process. It's most valuable exactly when it feels like unnecessary overhead: a small, "obviously fine" substitution made without going through the process is precisely the kind of change that causes a hard-to-trace field issue later, because it was never documented as a deliberate change in the first place.
How we approach this
We apply consistent revision numbering, BOM change logging, and traceability practices from the first prototype board onward, so the discipline is already in place by the time it matters at production scale. See our embedded hardware work for how this fits into a full hardware engagement.