Version 0.1 · 26 July 2026 · Digital Transformation Advisory
Status: non-normative practice material. This note is not part of the Transformation Decision Record standard and does not extend it.
The TDR standard captures one consequential decision: what was decided, by whom, under what authority, within what boundary, until when. It also states plainly what it does not do — a body of records supports the current position without computing it, and the graph or reasoning layer above the register is an optional consumer, out of scope.
This test operates one layer up. Its object is not a decision but a consequential change, and the collection of decisions that change moves. That is a change-planning question, not a record-format question.
Putting it into the specification to make an article’s footnote true would be the wrong repair. The claim moves layer; the standard does not move to meet the claim.
Scoping a consequential change by the decisions it touches, alongside — not instead of — scoping it by the work.
A programme, project, journey or release can carry authorisation perfectly well. As work units, they do not show which consequential judgements may later need to change independently. Work scope and decision scope are not the same shape.
1. Which decisions does it inherit? Decisions already in force that this change will operate under and must not silently break. Inherited is not the same as owned: inheriting a decision confers no authority to change it.
2. Which new decisions does it require? Judgements this change cannot proceed without, that nobody has yet made. If a required decision has no identifiable accountable holder, that is the finding, not a blocker to be worked around.
3. Which decisions does it supersede? Decisions this change intends to replace. Supersession is an outcome of accountable review, not a side effect of delivery. A project that finds itself superseding a decision it does not have authority over has found an escalation, not an obstacle.
4. Which other decisions and capabilities does it affect? Decisions not being changed, but whose validity, boundary or evidence this change disturbs. This is where most surprises live.
5. What may be decided within delegated bounds? The decisions this change is authorised to make without returning for approval — stated in advance, so that delegated speed is deliberate rather than assumed.
6. What evidence and reconsideration conditions must come back? What must be observable afterwards for anyone to know the change did what it was authorised to do, and what would trigger reopening it.
On one live change, not the estate. The output is a named list, not a completeness claim: some questions will have confident answers, some will have gaps, and the gaps are the useful part.
The test is a scoping aid. It does not confer authority, establish that an inherited decision is still valid, or determine what governs — those require an accountable holder.
These are different objects at different layers, and the distinction matters:
| TDR v1.10.0 §4.4 — five recurring scope questions | This note — the six-part change-scope test | |
|---|---|---|
| Object | One decision | One consequential change |
| Asks | applicability · authority · access · disclosure · impact | inherited · required · superseded · affected · delegated · evidence returning |
| Status | Released, normative, versioned in the standard | Non-normative practice material, versioned here |
A change scoped with this test will contain decisions, each of which can then be examined with the standard’s five. Neither contains the other.
0.1 — 26 July 2026. First issue. Offered as a candidate; expected to be superseded rather than edited.
Digital Transformation Advisory. Practice material, published separately from the open standard it sits above. All Practice Notes.