Is blast radius the same as a dependency graph?

It is computed from one, but it is a per-change measurement rather than a static picture. Blast radius takes the entities a specific change touches and closes over their dependents and the boundaries crossed, so the answer is specific to what the agent is about to do.

What happens when an agent exceeds its envelope?

The proposal is refused with the list of nodes it reached beyond the declaration. The agent can narrow the change, or propose again with --justification. Either way the decision is recorded on the knot, so a reviewer sees that scope was exceeded and why.

Does the envelope check slow agents down?

The benchmark measured governed Nool at 648 valid tasks per hour against 635 for git worktrees, with synthetic agents on nool 6.14.1: not a significant difference after multiple-comparison correction, though average stall was about 0.2 seconds higher. The content-policy arm, which blocks the most violations, trails git by about 52 tasks per hour; that trade is explicit and configurable.

Can I see blast radius without using Nool for version control?

Yes. nool init on an existing Git repository builds the architecture model, and nool debug blast-radius works from then on. Git remains the storage layer; Nool governs on top of it.

How do I declare the envelope for a change?

Through the scope you lease: --target-nodes on nool announce intent, or --nodes on nool try new, which files a lease atomically or exits before writing anything. The declared intent text adds the negative constraints, such as which paths must not change, that the proposal is checked against.

Semantic Blast Radius for AI Code Changes

Nool enforces high-fidelity boundaries for autonomous agents, ensuring that implementation never outruns the declared intent of a task.

Measure the reach of a change before it lands

# What does touching these paths actually affect?
nool debug blast-radius src/config/billing.ts src/pages/Pricing.tsx --compact

# Orient an agent with the blast radius of a task before it starts
nool context "rotate billing policy without weakening license checks" --budget 3000

# Inside the envelope: lands once its checks pass
nool propose --path src/config/billing.ts --intent "Rotate billing policy without weakening license checks"

# Outside the envelope: refused unless justified, and the justification is recorded on the knot
nool propose --path src/config/billing.ts --path src/lib/license.ts --intent "Rotate billing policy" \
  --justification "Touches payment policy and the licensing boundary; both reviewed with security"

Blast radius is computed from the architecture model Nool maintains for the repository, not from the text of the diff.

Which files changed is the wrong question

A diff tells you which lines moved. It does not tell you which callers now behave differently, which invariant a renamed field just broke three modules away, or whether a change in the billing package reached into identity. Agents make this worse, not because they write bad code, but because they write a lot of it quickly and across boundaries a human would have paused at. Reviewing agent output line by line does not scale, and reviewing it by file list misses exactly the changes that matter: the ones whose effects are felt far from where they were made.

Blast radius: the dependency closure of a change

Nool computes the semantic blast radius of a change from its architecture model: the entities touched, the entities that depend on them, and the architectural boundaries crossed on the way. nool debug blast-radius reports it for any set of paths before a change is landed. nool context reports it for the entities matched by a task description before the work even starts, so the agent knows what it is about to affect. In the benchmark's coordination arms, that same analysis is what lets Nool detect that two agents' changes conflict semantically even when their text merges cleanly.

The envelope: declared scope versus computed impact

The Semantic Impact Envelope is the comparison between the scope a change declared and the impact it actually has. The declaration comes from the announced intent and the leased paths. The impact comes from blast radius at proposal time. If the impact stays inside the declaration, the change lands on the fast path. If it exceeds the declaration, Nool refuses the proposal unless the agent supplies a justification, which is recorded on the knot for reviewers and for anyone who asks why later. This is how scope creep becomes a visible, gated event instead of a surprise in code review. On this site's own repository, an SEO change that reached seventeen nodes against sixteen declared was stopped for exactly this reason and landed only with a written justification.

Envelopes in a multi-agent fleet

With several agents working in parallel, envelopes are also how Nool partitions work. nool fleet plan computes waves of tasks whose blast radii do not overlap, so agents in the same wave cannot collide by construction. Leases fence the declared scope while work is in flight, and the envelope check at proposal time catches an agent that wandered past its lease. The result is a fleet where coordination is a property of the ledger rather than a promise the agents make to each other.

Reading a blast-radius report

The report lists the affected nodes, split into direct dependents, entities in the same architectural community and the wider closure, with a risk score, and the whole report as one JSON object with --json. The number that matters is the count against the scope you declared. When this site's SEO manifest was refactored, the proposal reported seventeen affected nodes against sixteen declared, and it landed only after a justification naming the extra node as a dependent rather than a change. That is the envelope working as intended: not blocking the work, but making the excursion explicit and recorded. Over time the reports also show which paths are hubs, because they appear in every closure, and those are the paths to protect with authored policies.

Frequently asked questions

Is blast radius the same as a dependency graph?: It is computed from one, but it is a per-change measurement rather than a static picture. Blast radius takes the entities a specific change touches and closes over their dependents and the boundaries crossed, so the answer is specific to what the agent is about to do.
What happens when an agent exceeds its envelope?: The proposal is refused with the list of nodes it reached beyond the declaration. The agent can narrow the change, or propose again with --justification. Either way the decision is recorded on the knot, so a reviewer sees that scope was exceeded and why.
Does the envelope check slow agents down?: The benchmark measured governed Nool at 648 valid tasks per hour against 635 for git worktrees, with synthetic agents on nool 6.14.1: not a significant difference after multiple-comparison correction, though average stall was about 0.2 seconds higher. The content-policy arm, which blocks the most violations, trails git by about 52 tasks per hour; that trade is explicit and configurable.
Can I see blast radius without using Nool for version control?: Yes. nool init on an existing Git repository builds the architecture model, and nool debug blast-radius works from then on. Git remains the storage layer; Nool governs on top of it.
How do I declare the envelope for a change?: Through the scope you lease: --target-nodes on nool announce intent, or --nodes on nool try new, which files a lease atomically or exits before writing anything. The declared intent text adds the negative constraints, such as which paths must not change, that the proposal is checked against.