Record iterations & developments, traceably.
Also called: Change log · Design history · Decision record · Revision trail
A running note of what changed in the design, why, and when, kept light enough that the team actually keeps it.
One line per change: what, why, when. Not a process; a habit. Done well, anyone can trace why a decision was made and avoid re-making a mistake. Done as bureaucracy, nobody updates it and it rots. Keep it boring and current.
What recording iterations is
It is keeping a usable trail of how the design got to where it is. Every product of any seriousness goes through dozens of changes: a seal redesigned, a feature dropped, a tolerance loosened. Each was decided for a reason that felt obvious at the time and is completely forgotten six weeks later. The record is what stops you re-arguing a settled question, or worse, quietly undoing a fix because nobody remembered why it was there.
The thing to understand is that this is a habit, not a process. The trap is treating it as document control: signed-off revisions, approval workflows, a template with fourteen fields nobody fills in. That version dies in week two. The version that survives is one line per change, written the moment the change is made, capturing three things and no more: what changed, why, and when. In my experience the “why” is the line that earns its keep; the what and when you can usually reconstruct, but the reasoning evaporates.
Here is what the proofing box’s change log actually looked like, so you can see the shape of a usable one rather than a generic template.
Three entries, three reasons, all reconstructable a year on. Notice each one records the reasoning, not just the edit. The seal entry alone saved an argument when, months later, someone proposed the cheaper foam gasket again.
- Files named box-final.step, box-final-v2.step, box-final-final-v3.step.
- No note of why any of them differ.
- The “real” reasoning living in three people’s heads.
- A 14-field template last touched in week two.
- One log, one line per change: what, why, when.
- Written at the moment the decision is made.
- The reasoning captured, not just the edit.
- Boring, current, and under a minute to update.
The chaos on the left is not a filing problem; it is a memory problem. final-final-v3 tells you the order things happened in and nothing about why. The log on the right is the cheapest insurance a project buys.
How it fits the bigger picture
Record Iterations & Developments is activity 07.10.12 in the framework, late in Stage 07 Engineer. It runs alongside the engineering work rather than after it, and it feeds directly into CE/UKCA mark documents (07.10.13), where a clean design-history trail is exactly what a UKCA technical file and a BS EN 61010 conformity case lean on.
What it can do
It lets anyone trace a decision back to its reason, hand the project over cleanly, and stop the team from re-solving a problem it already solved. When an assessor or a new engineer asks “why is the wood band that thick?”, the answer is one dated line away rather than a half-day of archaeology.
What it can’t do
It can’t make the decisions for you, and it can’t rescue a project that never wrote anything down at the time; reconstructing reasoning after the fact is guesswork dressed as record. It also isn’t formal document control. If your product needs signed, revision-controlled drawings, that is a separate, heavier discipline this habit feeds but does not replace.
See the full 10-stage process →
Try it yourself
Open one shared text file today. Newest entry at the top. The next time you change anything in the design, write one line before you move on: what changed, why, and the date. That is the whole method. The discipline is doing it at the moment of decision, not “when there’s time”, because there never is.
Want the structure that surrounds the habit? Start the Free Sprint → and the GPT will frame the decisions worth logging in the first place.
Your change-log checklist
▸ From the notebook · optional reading
Project notes: one text file, three saved arguments
Dan and Anna in Stockport kept a one-line-per-change log on the proofing box. It was unglamorous and it paid for itself three times over.
3 min read · click to open
I will be honest: when I suggested a change log, Dan’s face said “more admin”. So we agreed the lightest possible thing. One shared text file, newest entry at the top, three columns in plain prose: what, why, when. No template, no sign-off, no tool. The deal was that you wrote the line before you closed the CAD, not “later”.
The entry that earned the whole thing
Early on, the first lid used a foam gasket. It leaked warm air and the box wouldn’t hold 26°C through a cold Stockport night. We worked through a few options and switched to a silicone lip seal. Anna wrote one line: “Foam gasket out, silicone lip seal in. Foam leaked, couldn’t hold 26°C overnight. 12 Feb.”
Two months later, costing the bill of materials, someone spotted that the foam gasket was 80p cheaper and proposed switching back. In a project without the log, that is a half-day of re-testing to rediscover what we already knew. Instead Dan read the line aloud, and the conversation was over in a minute. The same thing happened again near launch with a new contractor who hadn’t been there for the original test. One line, settled.
What it cost, what it saved
- Cost. Under a minute per change. One text file. A small amount of nagging from me in the first fortnight until it became reflex.
- Saved. Two re-litigated decisions on the seal, one on the dropped preset, and a clean trail that went straight into the UKCA technical file when we reached CE/UKCA documents.
The thing nobody tells you is that the log’s value is almost entirely in the boring entries you assumed you’d never need. We never did manage a fancy version. The fancy version is the one that doesn’t get kept.
— Engineer stage, project notes, 2026
— Next in Engineer → CE/UKCA mark documents