How do you keep a decision record that shows what to revisit when a requirement or test result changes?

What a useful decision record contains.

A decision record is the reasoning behind a commitment, kept in a form someone else can inspect later. Minutes and slide decks capture the outcome; they rarely capture the basis. A record that supports later change needs six things:

• The question and its scope. What was being decided, by whom, and what was out of scope.
• The alternatives. Every option that was seriously considered, including the ones rejected and why.
• The decision basis. The requirements, test results, models and assumptions the comparison used.
• The recommendation. Who recommended which option, with any dissent.
• The commitment. Who authorized the course of action, when, and under what conditions.
• Reopening conditions. The specific changes that would require the decision to be looked at again.

Reference versions, not documents.

“The thermal test report” is not a useful reference, because the report will be revised. Record the version or revision you relied on: test report version 2, requirement revision C. Your requirements, test and model systems stay the source of record; the decision record points to the exact item it used. Without versions, nobody can tell later whether a decision was made before or after a result changed.

Mark what was decisive, and by how much.

Not every input matters equally. Note which requirements or results actually separated the chosen option from the others, and how close the margins were. An option that cleared a mandatory limit by half a percent is fragile; one that cleared it by twenty percent is not. This is what lets a team triage a change quickly instead of re-examining everything.

Write the reopening conditions when you commit.

At the moment of commitment, the team knows best what could undo the choice. Write it down: “If cold-weather test results reduce conservative range below the floor, reopen.” “If the supplier slips beyond the qualification date, reopen.” Conditions turn a vague obligation to keep decisions current into a check anyone can run.

When something changes, run a short triage.

1. Find the affected decisions. Search for every decision record that references the changed requirement or result. This is the step that fails when reasoning lives in presentations.
2. Check whether the change matters. Does it touch a decisive input, cross a recorded reopening condition or reduce a narrow margin? If not, record that it was reviewed and why no action is needed.
3. Authorize the scope of reanalysis. The decision owner decides whether a bounded reanalysis or a fuller restudy is needed.
4. Reanalyze against the same accepted basis. Keep the accepted requirements and stakeholder priorities unless they are what changed. Do not relax a limit to preserve an earlier selection.
5. Record the outcome. The authority either reaffirms the commitment or records a successor commitment, with its own conditions.

Supersede; do not overwrite.

When a decision changes, keep the original record and mark it as superseded by the new one. A later reviewer or new team member should be able to see the original choice, the evidence that challenged it, who authorized reanalysis and why the direction changed. Overwriting the record erases exactly the information that explains the current design.

Common failure modes.

• Decisions recorded only as an outcome, with no alternatives or basis.
• Links to a document’s latest version instead of the version used.
• No named owner for deciding whether a change matters.
• Reanalysis that quietly changes the requirements as well as the evidence.