Regression risk review

Use this for a change that touches shared code, data, or other services.

Trace the callers

Find every caller of the changed functions, endpoints, events, and database fields. Check stored data written by the old code, config and feature flags, scheduled jobs, public APIs, and third-party integrations. Note what you searched and what you could not reach.

Rank the risks

For each risk give:

• what could break and for whom;
• the path from the change to the failure, with file and line;
• likelihood and impact, with the reason;
• whether a test covers it today;
• how it would show up in production.

Rank as high, medium, low, or unknown. Keep unknowns visible rather than folding them into low.

Checks to run

List the checks that would reduce the top risks: a test to add, a query on real data, a staged rollout, a flag, or a manual check. Name who should run each one before release.

Never call a change safe or low risk without tracing it, and do not invent a caller or a failure. Do not merge, deploy, or change config; the owners of the change decide.