Tracking rework and bodge wires on prototype boards
Bodges, component swaps and ECOs are where prototype tracking breaks. A simple model for recording rework per revision and per unit, with who did it and when.
Published
Every prototype engineer knows the bodge wire: the fix that makes rev A usable while rev B is in fab. Rework is normal. What causes trouble is untracked rework. Two boards that look identical behave differently, test results can’t be reproduced, and firmware workarounds pile up for bugs that were fixed in hardware weeks ago.
Why notes columns fail
The usual approach is a free-text “notes” field: “R12 changed, bodge on U3 pin 4”. It fails for predictable reasons:
- It’s unstructured: you can’t filter for “boards without the U3 fix”.
- It’s inconsistent: the same rework gets described five different ways.
- It’s incomplete: rework done under time pressure doesn’t get written up.
- It has no history: you can’t tell when a board was modified relative to a test result.
Model rework as “mods”
Treat each rework as a first-class item, which we’ll call a mod, with three properties:
- It belongs to a revision. “Bodge R12 to 10k” only makes sense on rev A, because rev B fixed the footprint. Scoping mods to revisions stops them being applied to the wrong boards.
- It’s defined once. Write the instructions once (what to change, why, and how to verify it) rather than re-describing it on every board.
- It’s applied per unit, with a record. For each board, record whether the mod is applied, who applied it, and when.
This turns rework into data you can query:
- Which rev A boards still need mod 2? Filter for boards without it.
- Was MC4-006 modified before or after its thermal test failure? Compare timestamps in its history.
- We found a problem with mod 3. Which boards have it? Open the mod and see every unit it’s on.
A worked example
| Revision | Mod | Applied to |
|---|---|---|
| A | Add TVS diode on VBUS | MC4-001 to 004, 006 |
| A | Bodge R12 to 10k | MC4-001 to 007 |
| B | Rework U7 footprint | none yet |
When rev B boards arrive, rev A mods don’t apply to them, and nobody wastes time looking for a bodge that isn’t needed.
Moving a board to a new revision
Sometimes a board is reworked so heavily that it effectively becomes the next revision. Handle this deliberately:
- Confirm the old-revision mods are superseded by the new revision.
- Remove them from the unit (the removal is logged).
- Change the unit’s revision (also logged).
Proto Tracker enforces this order: it won’t move a board to another revision while old-revision mods are still applied, so a board’s mod list always matches its revision.
Keep the history
The final ingredient is an append-only history. When you’re chasing an intermittent fault, “this board was modified on 3 March at 17:40 by Sam, two hours before it started failing” is worth more than any amount of documentation written afterwards.
Proto Tracker records all of this automatically. See how to track PCB prototypes for the full system.