Know the blast radius before you change it

The dangerous change is not the risky-looking one. It is the one that looks purely additive — adding a returned value, a column, an option — and quietly violates a contract three files away that nobody re-read. Compilation and type checks will not catch a positional or length contract; you get either a crash far from the edit, or worse, silently wrong output.

Rule: if you change a shared interface, run its consumers. Reading them is not running them.

1. Enumerate consumers before editing

Grep for every call site, import, and downstream reference — including tests, notebooks, scripts, docs, and anything that regenerates reported results. Note which ones produce numbers that appear in a paper, dashboard, or release: those are the ones where silent breakage is most costly.

If a consumer lives in another repo, another language, or a generated artifact, write it down now; you will not remember at verification time.

A consumer in another repo pins this one by commit SHA. Its verification receipt records the revision it was built against — not a branch, not a version string, both of which keep moving under it. So a change here that moves a number the downstream reports is not finished when this repo goes green: before/after evidence for what moved, regeneration of the downstream artifact, and the re-pin all belong to the same round as the change — release-engineering.md §6 has the ordering within it. A downstream left pinned to the old SHA is an honest, inspectable state; one pointed at a moving reference silently inherits a number nobody re-verified.

2. Name the contract you are about to change

Ask explicitly what downstream code is entitled to assume: