# Change Blast-Radius Mapper > Describe what you are changing and its structure; a fixed rule set maps the blast radius as concentric tiers (target, co-located, downstream, human) populated with what could be affected, plus severity-tagged risks and containment measures. It maps what could be affected, never asserts what will break. - Tool: https://ronutz.com/en/tools/change-blast-radius-mapper - Family: Operations & Fieldcraft --- ## What it does Describe what you are changing through a small structured form - the target type, whether it sits on shared hardware, whether it is in the traffic path, how many things depend on it, whether there is a redundant peer, and how far the user reach extends - and a fixed registry of seventeen original rules maps the blast radius. The map is a set of concentric tiers: the change target itself, the co-located neighbours that share its device or platform, the downstream services that depend on it, and the human and business surface behind all of it. Each tier is populated with the categories of thing that could be affected there. Alongside the map, the tool surfaces severity-tagged risk factors (in the traffic path, everything depends on it, no redundancy, customer-facing) and containment measures that would shrink the radius (drain first, change one node, fail over to the standby, lower the TTL, restore the degraded peer). A coarse overall band - contained, moderate, or wide - summarizes the reach. One click exports a Markdown blast-radius assessment for the change ticket. ## What it deliberately is not This tool has no knowledge of your actual topology. It maps categories from what you describe, not your specific servers and links. It maps what could be affected; it never asserts what will break. It does not approve a change, makes no network connections, asks for no credentials, and replaces neither a real impact analysis nor a change review. The map it produces is a prompt to confirm the specifics against your real environment, so that nothing in a tier is forgotten. The free-text notes flow only into the exported assessment; they never influence which rules fire. ## How the map is built - and how it is verified Each rule is a pure predicate over the structured input; when it fires it adds affected-category items (each belonging to one fixed tier), optionally a risk factor, and optionally containment measures. An item pulled in by several rules still appears once, ordered by the first rule that added it; the tiers are always emitted in the same concentric order, so the map reads from the target outward. The target tier always has the object being changed and the state your backup must capture; the other tiers populate from the co-location, the traffic path, the dependents, the redundancy, the user reach, and the target type. The coarse band is derived from the highest-severity risk that fired. The "Why this map?" panel lists every fired rule with its reason, so the map is auditable rather than oracular. Because there is no single "correct" map for an advisory tool, classic golden vectors do not apply. The verification model - the ruling set by the Fault Hypothesis Builder pilot for the whole Operations and Fieldcraft family - is rule-firing snapshot vectors: for each test input, the build asserts exactly which rules fire, the exact populated tiers with their ordered item ids, the exact risk factors, the exact containment measures, the exact cautions, and the coarse band. Eleven vectors (six scenarios, five rejects) pin the current registry; any drift breaks the build. One deliberate edge is pinned openly: a dedicated standalone target with narrow reach still lands a wide band, because with no peer any interruption is total - the honest reading rather than a smoothed one. ## API input The API-parity entry takes a JSON object: `{"target", "colocation", "trafficPath", "dependents", "redundancy", "userReach", "preset", "notes": {"summary", "targetDetail"}}`. Every field except `notes` uses the closed vocabularies shown in the form; an out-of-vocabulary value is a format error, never a guess. ## Standards and references - Original blast-radius ruleset (D-18: original by construction) - the 17-rule registry, 16 affected-category items across four concentric tiers, 11 severity-tagged risk factors, 9 containment measures, and the coarse radius-band derivation are original editorial work encoding standard impact-analysis practice (target/co-located/downstream/human tiering, dependency and traffic-path reasoning, redundancy and containment); no external framework or specification is claimed or reproduced ## Related reading - [Blast-Radius Thinking Before You Change Anything](https://ronutz.com/en/learn/blast-radius-thinking-before-you-change-anything.md): Before a change, the question is not only will this work but if it goes wrong, how far does the damage reach. Blast radius is the shape of that reach - target, neighbours, dependents, people - and thinking about it in tiers is how you decide what to contain before you touch anything.