> ## Documentation Index
> Fetch the complete documentation index at: https://warden.buildlab.in/llms.txt
> Use this file to discover all available pages before exploring further.

# Blast radius

> Whether an operation is provably bounded, decided before it runs.

A missing `WHERE` is indistinguishable from a deliberate one — after the fact. Warden decides before, from the structure of the operation:

* **Bounded** — the predicate provably restricts it to an enumerable set of records.
* **Unbounded** — it does not, and the reason is recorded: no predicate at all, a comparison that cannot be normalised, a write derived from another resource with nothing bounding it.

Policy can then treat `unbounded_mutation` as its own class, because "change every record" deserves a different answer from "change this one".

## What counts as a bound

Equality on an identifying field, and membership in a list of them, bound an operation. Ranges, pattern matches, negations, and existence checks do not: `WHERE created_at > '2020-01-01'` matches an unknown number of records, and calling that bounded would be a lie of exactly the kind this analysis exists to prevent.

An operator the connector cannot normalise makes the operation unbounded and raises a hazard — the honest representation of "this is well-formed, and I cannot reason about it".

## Scope is not a bound

> [!WARNING]
>
> An agent scoped to one tenant issuing `DELETE FROM orders` is still deleting **every order it can see**. Warden counts that as unbounded.

Scope limits *whose* records an operation reaches. Bounds limit *how many*. Conflating them is how an approval queue starts showing "1 tenant affected" for a statement that empties a table, and it is why scope never contributes to the bound the reviewer is shown. The certification suite checks this specifically: applying scope must never change the blast radius.

## Hazards

Alongside the bound, an operation carries hazards — properties a reviewer or a policy should react to:

| Hazard | What it marks |
| - | - |
| `no_predicate` | Nothing restricts which records are affected |
| `unparsed_construct` | Something Warden could not analyse |
| `cross_resource_write` | A write whose data comes from another resource |
| `drop_resource` | Destruction of the resource itself |
| `server_side_code` | Code executing inside the engine, which escapes every analysis above the connector |

Policy denies on hazards; the reviewer sees them on the pending card; audit records them. The same statement is described the same way in all three places.

## The estimate

Where the engine can supply one, the operation carries an estimated record count from the engine's own statistics. It informs display, never policy: an estimate is not a guarantee, and a decision resting on one would be a decision resting on a statistic that was last refreshed at an unknown time.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.