Impact Report template: Breaks vs Must-change vs Risky

The #1 missing artifact in AI-assisted shipping isn't generation.

It's an Impact Report.

Because a diff can look harmless and still break reality: schema -> API/SDK -> UI flows -> auth/PII -> docs/support.

Tests catch some "breaks". They don't catch "drift".

The 3 buckets that matter

An Impact Report is a classification:

1. "Breaks" Stop-ship. Something will fail.

2. "Must-change" Nothing crashes today, but the system is now lying somewhere. This is drift.

3. "Risky" Might work, but needs verification + rollout guardrails.

Most teams cover (1) with tests. They cover (3) when they're scared. They ignore (2) because it feels optional. Then they pay later.

Impact Report template (copy/paste)

INTENT (1 sentence): CHANGE SUMMARY: SURFACES TOUCHED: UI / API / DB / Policy / Docs

BREAKS (stop-ship):

• ...

MUST-CHANGE (required updates to avoid drift):

• ...

RISKY (needs verification + rollout):

• ...

VERIFY PLAN:

• tests:
• runtime signals:
• owner:

ROLLOUT PLAN:

• flag? staged? thresholds?

ROLLBACK PLAN:

Example: "It's just a rename"

Rename a field and you touch: DB migration -> API response -> client types -> UI validation -> policy rules -> docs.

BREAKS: Old clients crash or mis-parse responses.

MUST-CHANGE: Docs + SDK examples + UI copy are now wrong. Nothing crashes, but reality is inconsistent.

RISKY: Migration performance at scale.

How to do this manually in 10 minutes

• Write intent (1 sentence)
• List surfaces touched (UI/API/DB/Policy/Docs)
• For each surface ask: "what's the worst plausible failure?"
• Bucket it into Breaks / Must-change / Risky
• Add 1 verification signal per Risky item

Where ContractSpec Studio fits

ContractSpec Studio is built to generate an Impact Report from the same inputs as your brief/Change Card, then export work items into Linear/Jira.

If you want to see sample outputs:

• https://www.contractspec.studio/

Next reads:

• Outcome checks: deploy + 14 days
• Export-first workflow