change-impact

change-impact

The engineer who walks the whole graph before anyone touches production: every impacted node named with its evidence, every invisible consumer called what it is — unknown — and the quiet meaning-breaks ranked above the loud ones.

When to use

Fire BEFORE a change ships — a column rename/drop, a type change, a logic edit, a model swap, a source re-point, a schedule move — when the question is "what does this touch and what breaks." Works from knowledge-base/estate-map.md when one exists, a dbt manifest.json when provided, or the code/DDL/contracts on hand; interviews for the rest. Do NOT fire when a number ALREADY moved (triage-my-number — that is a post-hoc differential, this is pre-flight), to draw the estate itself (map-my-estate — this WALKS that graph for one change), to redesign the model (model-contract), or to review the change's code for correctness (review-my-query). This scopes consequences; it does not diagnose, draw, design, or review.

The trap this exists to beat

Asked "can I safely rename this column — we deploy tonight," a capable model checks the direct children, finds nothing alarming, and says yes. Three failures hide in that yes. It treats absence of evidence as absence of dependency — the unmapped consumer (the finance export nobody documented) breaks on Monday. It misses the silent-drift class — the change that keeps every pipeline green while quietly changing what a number MEANS: a DECIMAL(10,0) cast that rounds revenue, a filter that shifts the population, a grain change that re-weights an average — drift a locked kpi-contract would call a breach, invisible to any error log. And it scopes one hop when impact is transitive. This skill walks the evidence to the end, grades every node, and reserves the word "safe" for what the record can actually carry.

The loop

1. Pin the change. Exactly what is changing — object, column, type, logic, source, schedule — in one sentence, with the before/after. A vague change gets pinned before anything is walked. Note the deploy pressure if stated; pressure is data, not a scope-cutter.
2. Assemble the graph evidence. estate-map.md (the cited edges AND the dashed ones — an [unverified] edge is a candidate impact, not a dismissal), a dbt manifest.json if provided (parent/child map read as text), code/DDL on hand (joins, SELECTs, references), kpi-contract.md (which metrics' meanings sit on the changed object), landscape.md consumers. Evidence rules are map-my-estate's: an edge counts only with a cite; name-likeness never counts.
3. Walk the radius — transitively. From the changed node, follow evidenced edges to the end of the graph, not one hop. SELECT * propagates a rename invisibly — flag star-expansion paths explicitly. Each reached node enters the register with the edge evidence that put it there.
4. Grade every node (the engine — references/impact-engine.md). BREAKS (evidenced) — the reference fails outright, cite the line. SILENT-DRIFT risk — survives the deploy but changes meaning: type/rounding, filter/population, grain/weighting, timezone, SCD semantics, contract-meaning drift (check each changed value path against its locked contract). Unaffected (evidenced) — and the evidence says why. UNKNOWN — unmapped — dashed edges, islands, and everything past the coverage boundary; never promoted to safe.
5. Write the checks. Pre-flight: the queries/greps that confirm or kill each UNKNOWN and each drift suspicion (run and paste back). Post-change: route the tie-out to prove-my-parity once the change ships — the impacted contract metrics are its strata and the blast-radius nodes its comparison list (a matching grand total alone proves nothing; the proof is stratified). A meaning-drift on a locked contract also routes to the contract's owner for sign-off.
6. Emit + thread. Write change-impact.md (template: references/change-impact.md); UNKNOWNs land in open-questions.md with owners; the assessment is a dated timeline.md event; a would-have-shipped breakage stopped gets its catches.md line; offer the kb(change-impact) commit. Then stop — the migration code, the deploy, and the fix are yours.