Change request

Record what must change after a baseline, why, what else it touches, and who decided.

Any time after a baseline, before anything is changed. Inputs: the traceability matrix and the source register. Feeds: the decision log, the new baseline and the traceability matrix.

• Say what changes and what triggered it, with the source.
• Filter the traceability matrix on the items the change touches, and list every affected item by its ID.
• Say what happens if nothing is done.
• Weigh at least two options, doing nothing among them.
• Record the decision, the date and who decided, with the decision log entry.
• Update the affected documents, and note the new version of each.

1. What exactly changes, and what triggered it? Answered in CR-01, "Trigger and source": SRC-10 set 30 September 2026 for a change that SRC-07 had already made.
2. What else is affected? Answered in CR-01, "Impact": 14 documents, item by item, found through the matrix in 19.
3. What happens if we do nothing? Answered in CR-01, "If we do nothing": every refusal notice from 30 September 2026 would name a body that no longer exists.
4. Who approved it, and what is the new baseline? Answered in CR-01, "Decision" and "After approval": STK-06 on Friday 18 September 2026 (DEC-15); version 1.1 of each affected document, issued on Tuesday 22 September 2026.
5. Why is a request deferred rather than approved or rejected? Answered in CR-02, "Decision": deferred until OQ-01 is answered (DEC-16). "Options" gives the earliest date it can come back, Friday 9 October 2026.

• A change request with no impact analysis. You can spot it when the impact section names documents but no items.
• Approval before the impact is known: the decision is dated before the impact table was complete.
• The trace not updated afterwards: the matrix still shows the old rows after the change is closed.
• Changes made quietly, without a request: a document's version moves, and no change request explains it.
• A deferred request with no condition for its return: nobody can say what would bring it back.

• Two requests in one file, one approved and one deferred, because a deferral is a decision too (DEC-16). Rejected: logging approved changes only, which would lose CR-02's impact analysis until someone raised it again.
• The impact table lists items by ID, found by filtering the matrix in 19 on BR-41, BR-53 and BR-60. Only then does it say which document holds each. Rejected: a list of documents, which says where to look but not what to change.
• CR-01's timeline shows what was known when. SRC-07 was in the register at the baseline, with no date. SRC-10, made on the day of the baseline, set the date, so it joined the register in version 1.1 with the next free number. Rejected: adding SRC-10 to the baseline after the event, which would hide that the baseline missed it.
• Glossary terms, clock states and parts of the brief carry no ID, so they appear in the impact table by name. Rejected: leaving them out because the matrix cannot see them.