The worst dispute I have been part of was not about quality. It was about which of nine near-identical photographs represented the approved colour.
Nobody was lying. There were simply nine photographs called things like final, final2, approved_v3, and use this one, spread across three email threads and two messaging apps.
The convention
Specs now carry a version identifier that encodes three things: the design, the revision, and the date. SQ-114-R3-2026-03-11. Revision numbers only go up. A revision is never edited in place.
Colour approvals are a separate object with their own identifier, and the approval record names the physical swatch that was signed off, not just a photograph. The photograph is evidence about the swatch, not a substitute for it.
The changelog
Every revision gets one line: what changed and why. Not a diff, a sentence. Ten revisions of a squishy toy spec is maybe half a page of history, and it answers the only question that ever comes up — "when did this change and did we agree to it".
This is unglamorous and it has saved more money than any negotiation I have been in.
Why it belongs with operations, not design
Designers treat versions as work in progress. Operations needs versions as commitments. The same identifier has to serve both, which means the version has to be cut at a moment everyone can point to — usually when a sample is approved and a proforma is issued.
The approval gate itself is described in our note on private label and OEM production, and the earlier step is covered under toy safety standards for importers.
Minimum viable version control
One identifier scheme, monotonic revision numbers, and a one-line changelog. A shared spreadsheet is enough. The failure mode is not the tool, it is that nobody agrees on when a version becomes a commitment.
Written by Zhao Jin, sales at Yiwu Jinji Trading Company (King Squishy), a Yiwu-based supplier of wholesale squishy and fidget toys working with partner workshops. support@kingsquishy.com · WhatsApp +86 182 6776 0712.
Top comments (0)