Change Impact Report¶
Change-control artifact — instantiates Change-Scoped Revalidation
A shareable summary that states a proposed change and lists the downstream artifacts, obligations, tests, and owners it touches, so reviewers can see the blast radius before approving.
A Change Impact Report is the archetype's communication instrument. It does not compute what a change affects and it does not re-derive anything — it takes an affected set someone else worked out and renders it into one legible, reviewable object: here is the change, here is everything downstream that hangs off it, and here is the named owner who must re-clear each item. Its distinguishing move among its siblings is legibility and accountability before the fact: it converts an abstract dependency set into a page a review board can approve or challenge, pairs every affected item with a person, and — once decided — remains as the durable record of what was known and who signed. It is the artifact that makes a scope argument reviewable, not the analysis that produces the scope.
Example¶
An avionics supplier proposes swapping a discontinued capacitor on a flight-control board for a pin-compatible replacement — electrically "the same part." Before it can go to the change-control board, someone has to answer: what does this actually touch? The Change Impact Report is that answer, on one page. Pulling trace links from the requirements and design records, it states the change (old part → new, with the tolerance and temperature-rating deltas) and then lists what hangs off it: two derating analyses, the board's thermal qualification test, the DO-254 design-assurance artifact, the approved-vendor list, and the reliability prediction — each line tagged with the owner who must re-sign it. What the report deliberately does not do is decide whether those items still pass; it makes the blast radius visible and assigns it. At the review, instead of a vague "seems minor," the board sees seven named obligations and seven owners, approves the change conditional on those sign-offs, and the report itself becomes the record of what was known and decided.
How it works¶
- It consumes an affected set (from impact analysis or a closure traversal) and renders it as a human-readable summary — its work is communication, not computation.
- Every affected line is paired with a named owner, turning an abstract dependency set into assigned accountability that someone must discharge.
- It states the change itself at the top as the thing under review, so the scope argument is anchored to a concrete delta.
- It is durable: once decided it stands as the audit record of what was known, who signed, and — if it lists exclusions — what was deliberately scoped out.
Tuning parameters¶
- Granularity of the affected list — subsystem-level vs. line-item. Finer lists are more actionable but longer, and past a point they bury the signal.
- Owner-assignment depth — a responsible owner per item vs. a single accountable owner for the whole change. Per-item scales accountability but needs an owner map to exist.
- Confidence surfacing — whether each impact is flagged certain / probable / possible. The report can carry such a tag, but it does not produce the estimate — that comes from the analysis it summarizes.
- Scope-out disclosure — whether it also lists what was considered and deliberately excluded, not only what is in. Listing the exclusions is what makes the boundary itself challengeable.
- Audience framing — engineering detail vs. governance summary; the same impact set reads very differently for an implementing team than for a review board.
When it helps, and when it misleads¶
Its strength is that it turns "trust me, it's a small change" into a reviewable, signed object: the blast radius becomes visible before approval, accountability is assigned rather than assumed, and months later it answers "who signed off on this, and what did they think it touched?"
Its failure mode is that a report is only as complete as the trace links behind it[1] — missing links yield an under-stated blast radius that looks authoritative precisely because it is on the page. The classic misuse is writing the report to pass the change: scoping the impact narrow on paper so it clears review with fewer sign-offs — assembling the document to justify a decision already made rather than to inform one. The discipline that guards against it is to derive the affected list from an independent impact analysis rather than the author's judgment, to require the named owners to actually sign rather than the author on their behalf, and to disclose what was scoped out so the boundary can be contested.
How it implements the components¶
Change Impact Report fills the record-and-accountability machinery of the archetype — the components that make a scope decision legible and owned:
change_delta_record— it states, in reviewable terms, exactly what is changing; this record is the report's subject line.exception_owner— each affected obligation is paired with the named owner accountable for re-clearing it.audit_trace— once decided, the report stands as the durable record of what was known, scoped, and signed.
It does not compute which items are affected — that closure comes from Impact Analysis and Dependency Closure Traversal — nor decide what may persist (Cache Invalidation Review), nor verify the boundary held afterward (Boundary Escape Sampling).
Related¶
- Instantiates: Change-Scoped Revalidation — it makes the archetype's scope argument legible and accountable for human review.
- Consumes: Impact Analysis / Dependency Closure Traversal for the affected set, and Data Diff and Merge Tool for the underlying change.
- Sibling mechanisms: Impact Analysis · Dependency Closure Traversal · Requirements Traceability Matrix · Cache Invalidation Review · Boundary Escape Sampling · Persistence Exception Register · Selective Revalidation Worklist · Truth-Maintenance System · Regression Test Suite · Dependency Graph · Data Diff and Merge Tool
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: A shareable summary that states a proposed change and lists the downstream artifacts, obligations, tests, and owners it touches, so reviewers can see the blast radius before approving, making its operative form a non-executable information artifact that externalizes static or prospective structure.
Independent corroboration: The frozen evidence defines Change Impact Report as 'A shareable summary that states a proposed change and lists the downstream artifacts, obligations, tests, and owners it touches, so reviewers can see the blast radius before approving', so its operative form is Representation, Specification & Plan.
Nearest alternative: Record, Log & Register — It primarily externalizes the proposed blast radius for review; becoming the durable audit record after decision is a secondary lifecycle role.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Engineering change-control practice first made impact analysis and affected-item accountability formal prerequisites to modifying controlled systems.
Related originating lineages:
- Computer Science & Software Engineering — Software dependency analysis supplies downstream artifacts, tests, and blast-radius reporting.
- Organizational & Management Science — Project governance supplies named owners, approval circulation, and durable sign-off.
Review resolution: Engineering design is the agreed primary lineage because impact analysis traces a proposed change through requirements, interfaces, tests, obligations, and owners. Software dependency analysis and organizational accountability shape the shareable artifact; their combination is a multi-domain Encyclopedia synthesis.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] Gotel, O. C. Z., & Finkelstein, A. C. W. "An Analysis of the Requirements Traceability Problem". Proceedings of the First International Conference on Requirements Engineering, 94–101 (1994). Shows that traceability-dependent analysis is bounded by the project information and interconnections that are actually recorded and maintained. registry ↩