Blast Radius Guard

Blast Radius Guard

Constrain the failure domain before a consequential mutation without slowing ordinary work. The objective is not zero risk; it is a known target set, authorized impact, recoverable execution, and verified outcome.

Decide whether to raise the gate

Evaluate four dimensions:

• Reach: one local artifact, one external object, many objects, or a shared system
• Reversibility: one-step undo, restore from a checkpoint, manual reconstruction, or irreversible
• Ambiguity: deterministic response, delayed result, timeout-prone result, or no reliable status channel
• Authority: explicitly requested target, normal in-scope workflow step, loosely implied mutation, or missing authorization

Use the lowest gate that fits:

• Routine: narrow, reversible, local, and clearly authorized. Proceed with normal verification.
• Guarded: externally visible, multi-object, or costly to reconstruct. Resolve targets from current state and establish an undo path first.
• Hard gate: destructive, financial, permission-changing, broad, irreversible, or authorization-sensitive. Require authority for the exact impact and stop if the target set or recovery story remains unclear.

Do not turn a routine edit into a ceremony. Raise the gate when one dimension is severe or several are uncertain.

Write the mutation contract

Before a guarded or hard-gate action, establish:

1. Intent: the outcome the user asked for, not merely the command about to run.
2. Exact targets: concrete files, records, recipients, environments, branches, accounts, or resource IDs resolved through read-only inspection.
3. Expected delta: what will change and what must remain unchanged.
4. Authority: why this mutation is within scope. A broad goal does not authorize a materially different external effect.
5. Recovery: undo command, backup, previous revision, provider rollback, or an explicit statement that recovery is impossible.
6. Proof: the independent read, remote state, receipt, or behavior that will confirm success.
7. Stop trigger: the first unexpected condition that ends the attempt before impact expands.

Keep the contract concise. Never echo secrets, tokens, private payloads, or sensitive recipient data into logs or reports.

Execute with a narrow failure domain

• Prefer exact identifiers over globs, unresolved variables, inferred recipients, or broad directory roots.
• Use a preview, dry run, diff, plan, or read-only API when it accurately models the real action.
• Start with the smallest representative batch when partial rollout is useful and safe.
• Preserve unrelated user state. Do not clean, overwrite, reformat, or restage outside the resolved target set.
• Capture the operation identifier, revision, timestamp, or receipt needed to reconcile the result.
• Stop at the defined trigger. Do not improvise a broader mutation to rescue a failed narrow one.

Handle ambiguous results

A timeout, dropped connection, or missing response does not prove failure. Before retrying a non-idempotent action such as sending, charging, creating, publishing, or appending:

1. Query the authoritative current state or operation history.
2. Classify the first attempt as applied, not applied, or unknown.
3. Retry only when it is confirmed not applied or the provider guarantees idempotency for the same key.
4. If state remains unknown, stop and report the reconciliation path instead of risking a duplicate side effect.

For idempotent operations, keep retries bounded and verify that the request key, target, and desired state have not changed.

Verify the outcome independently

Do not treat a successful command exit, redirect, queued status, or optimistic UI as final proof when a source of truth is available.

• Re-read the affected state through an independent path.
• Compare the observed delta with the mutation contract.
• Check the invariants that were supposed to remain untouched.
• For publish or deploy actions, verify the user-facing artifact or remote revision.
• For deletion or replacement, state what disappeared, what replaced it, and whether recovery remains possible.

Report the resolved scope, action taken, verification evidence, and recovery status. If verification fails, say that the mutation was attempted but not confirmed; do not claim completion.