Impact Report template: breaks vs must-change vs risky
A practical Impact Report template to make blast radius explicit before approved work leaves review.
The missing artifact in AI-assisted shipping is usually not generation.
It is an Impact Report.
Because a change can look harmless and still break reality across:
schema -> API -> UI -> policy -> docs -> support.
The three buckets that matter
-
Breaks Something fails now. Stop ship.
-
Must-change Nothing crashes yet, but the system is already lying somewhere.
-
Risky The change may work, but it still needs verification and rollout guardrails.
Most teams cover the first bucket with tests. They cover the third when they are nervous. They skip the second and call the drift "fine for now."
Impact Report template
INTENT (1 sentence): CHANGE SUMMARY: SURFACES TOUCHED: UI / API / DB / Policy / Docs
BREAKS: MUST-CHANGE: RISKY: VERIFY PLAN: ROLLOUT PLAN: ROLLBACK PLAN:
Why it matters
The Impact Report is what keeps the reviewed handoff honest before it leaves the workflow.
Without it, teams still ship. They just ship blind.
Related articles
Outcome checks: deploy is not done
A simple Check schedule (+24h, +7d, +14d) so approved work stays tied to measurable follow-through.
Change Card template: the smallest spec engineers trust
PRDs are too big. Tickets are too small. Use a Change Card to define the reviewed handoff engineers can trust.
The 8-step workflow: signal -> verified impact
A practical Meeting-to-Execution workflow: evidence -> brief -> Change Card -> Impact Report -> approved handoff -> Checks.