Glossary
Revision control
Revision control is the discipline of identifying, tracking, and managing the changing states of engineering artifacts — parts, assemblies, drawings, documents, and firmware — so that everyone who touches the product is working from the same released truth.
In one sentence
Software learned decades ago that “it works on my machine” is a configuration problem; hardware is still learning that “it worked on my bench” is too.
Why it matters
A physical product is a configuration: a specific set of revisions of many artifacts — schematic, PCB layout, BOM, firmware, enclosure, harness — that together define one buildable thing. When revision control is disciplined, “build rev C” is an unambiguous instruction. When it isn’t, rev C means one thing to engineering, another to the contract manufacturer, and a third to service — and the resulting misbuilds, wrong parts, and field issues are traced back to a problem that was never really about the design.
How it works in practice
Each artifact carries a revision identifier — letters or numbers, depending on the scheme — that advances when an ECO changes it. A released revision is immutable: you never edit rev C after release, you create rev D. Working copies (versions, iterations) exist before release and are allowed to be fluid. The configuration — the set of artifact revisions that define one product state — is recorded explicitly, so that “the rev C build” resolves to a specific schematic rev, layout rev, BOM rev, and firmware version, not to whatever each engineer happens to have open.
Common failure modes
Released revisions get edited. A “small fix” goes straight into the released file instead of through a new revision. Now two products labeled rev C contain different designs, and traceability is fiction.
Per-artifact revisions, no configuration record. The schematic is at rev D, the layout at rev C, the BOM at rev E — and nobody has written down which combination was actually built and shipped. When a field failure appears, the investigation starts by guessing.
The revision scheme dies quietly. The convention starts strong — letters for released, numbers for work-in-progress — and erodes under schedule pressure until “final_final2” appears in the project folder. The most common failure isn’t the scheme; it’s that enforcement stops.
Firmware floats free. Hardware revisions are tracked in PLM while firmware versions live in a separate repo with no link between them. The product ships with firmware 2.4.1 on a board that was validated against 2.3.0, and the pairing was never recorded — this is the reconciliation tax applied to versioning itself.
How ProductFlo handles it
ProductFlo keeps a live, versioned record of every artifact — schematics, firmware, CAD, BOMs — with full history and diff on every change, branching and merging for design variants, and a merge gate that checks each change against the full engineering graph before it can ship. Agents watch the graph and flag cross-discipline impacts as reviewable diffs; a human approves. Agents propose diffs. Humans approve. The revision scheme stays yours — ProductFlo just makes it enforceable.
Questions about revision control
What is the difference between revision and version in hardware?+
How should a hardware team number revisions?+
What is a revision configuration?+
How does ProductFlo help with revision control?+
Related concept
ECO →
The formal vehicle that creates new revisions — and the audit trail behind them.
Related concept
BOM →
Revision discipline starts with the BOM — the shared definition of what gets built.
Eight definitions, zero marketing. Browse the full glossary.
All glossary terms →Make your revision scheme enforceable.
A 30-day pilot on one active product. Fixed $8k. Live on your own BOM in week one.
Book a demo →