How to record engineering design decisions properly

Every engineer has inherited a project where a dimension, a material or a supplier looked wrong, and nobody could say why it was that way. Sometimes it was wrong. Often it was right for a reason everyone had forgotten, and changing it broke something.

What counts as a design decision?

A design decision is a choice between credible alternatives that constrains what comes after it. To tell whether something counts, ask: could a competent engineer reasonably have chosen differently? If so, it is a decision and the reason is worth recording.

• Choosing a spherical roller bearing over a deep-groove ball bearing for a misaligned shaft.
• Specifying 316 stainless over 304 for a wash-down environment.
• Setting a weld size above what the calculation requires, for fabrication tolerance.
• Accepting a supplier's deviation from the drawing.
• Deciding not to do something, such as not adding a guard, not testing to failure or not upgrading a foundation.

The last item is the one most often missed. A decision not to act leaves nothing in the drawings, so it is the hardest kind to reconstruct later.

What is worth recording

Prioritise decisions that are:

• Expensive to reverse. Anything that has been manufactured, poured, ordered or certified.
• Non-obvious. Cases where the textbook answer was not the one chosen.
• Safety or compliance related. Load cases, factors of safety, and standards clauses applied or judged not to apply.
• Driven by a third party. Client instructions, supplier limitations, regulator feedback. Record who said it, and when.
• Based on an assumption you have not yet been able to verify.

What is not worth recording

Recording too much causes its own problem: if every entry is a decision, nobody reads any of them. Leave out:

• Choices fully determined by a standard or a calculation, with no judgement involved. Cite the standard instead.
• Cosmetic and drafting choices with no functional consequence.
• Choices that are cheap and easy to reverse, like the fastener head style on a prototype or a temporary test fixture.
• The full story of how you got there. Record the conclusion and what drove it.

Capturing rationale

The rationale is usually the first part of a record people forget, and the part they most need later. A good one names the driver: the requirement, constraint or result without which the decision would have gone another way.

Weak rationale	Useful rationale
"Better option."	"Measured misalignment 0.5°; deep-groove limit is ~0.15°."
"Client preference."	"Client (J. Smith, email 3 Mar) requires no new floor fixings in the wash-down zone."
"Stronger."	"Bending utilisation 1.22 with existing section at the new motor rating."
"Standard practice."	"Site is 400 m from the coast, corrosivity category C4 (ISO 9223), so hot-dip galvanise rather than paint."

If you can't name a driver, either the decision isn't really made yet or it was a judgement call. If it was judgement, say so. "Engineering judgement: chose X because Y feels more robust; no calculation" is honest, and much more useful than nothing.

Recording rejected alternatives

Writing down the options you rejected saves the next engineer from repeating your work. For each credible option you set aside, record one line: the option, and the specific reason it lost.

Rejected: torque arm to floor. Client won't accept floor fixings in wash-down zone.
Rejected: 6308 bearing. 90 mm OD needs a new housing; only ~2× life.
Rejected: re-aligning shaft only. Doesn't address the 75% higher radial load.

The reasons are often non-technical: cost, lead time, a client constraint, site access. Those are also the reasons most likely to change. When lead times drop or the client relents, a rejected option may become the best one, and the record shows you which decisions to revisit.

Linking calculations and evidence

A decision record should point to its evidence precisely enough that someone else can find and check it:

• Calculations: the working itself, or the file name, revision and sheet. Spreadsheets get overwritten, so record the revision you relied on.
• Test results: date, test ID, and the specific value that mattered.
• Datasheets and standards: document, revision or edition, and clause or table number.
• Correspondence: who, when, and the instruction in their words.

If the calculation is written in the entry and the photo is pasted beside it, the evidence and the decision can't drift apart.

Assumptions and uncertainty

Most design decisions rest on something that has not been verified yet: a load estimate, a soil report still to come, a supplier's verbal confirmation. Record these explicitly, with what would change if they turned out wrong:

Assumption: radial load 6.1 kN from one day's logging.
If wrong: above ~8 kN, the 22208 still clears 50,000 h; below 4 kN the original 6208 would have sufficed.
Verify: full-shift logging, JB, by 19 March.

The "if wrong" line tells you how much the assumption matters. Months later, it also tells you whether a changed input affects the decision at all.

Recording later changes

Decisions change. When they do, do not edit the original entry. Write a new, dated entry that states the new decision, refers to the old one, and records what changed, whether that was new information, a changed requirement or a mistake.

This keeps the sequence intact. In a dispute or an incident investigation the question is usually what was known and when, and a record that shows its corrections is worth far more than one that was quietly edited.

Picking up a project eighteen months later

Imagine you have just been handed a project somebody else ran. The engineer who did the work has moved on, the client wants to know why the frame was changed, and all you have is the record. Here is what would make your first day on it easy:

1. A dated list of what was decided, so you can see the order things happened in.
2. The requirement or constraint behind each decision, so you can check it still applies before you change anything.
3. The options that were ruled out and why, so you don't spend a week repeating analysis somebody already did.
4. The assumptions that were made, and whether anyone confirmed them. If something has gone wrong, an unchecked assumption is the first place to look.
5. Where the calculations, drawings and test results are, by file name and revision, so you check the same version they used.
6. What is still open: actions nobody closed, risks nobody resolved, questions the client never answered.
7. Whether a later entry changed or reversed the decision, so you aren't working from one that was superseded.

Write your own records so that whoever inherits your projects gets all of that. Our free engineering logbook template has a section for each of these.

Where to keep decision records

Decision records work best in the same place as the rest of the engineering log, dated and filed against the project, rather than in a separate register someone has to keep up to date. Some teams use a dedicated decision log. For most consultancy and product design work, a well-structured logbook entry is enough, and it is far more likely to be kept up.

Engineering logbook software such as FactaLog keeps each decision in a dated entry with its calculation, images and links beside it, searchable across every project. You can also seal an entry, so you can show later that it hasn't changed.