Ask a team how they know their agent is safe and you'll usually hear about evals: a benchmark, a red-team sprint, a set of prompts that used to break things. Evals measure the failures someone imagined. They say nothing about the ones nobody did.
Chemical plants had the same problem in the 1960s. The answer they developed, the hazard and operability study or HAZOP, is still how refineries, pharma lines and food plants are designed. Airbender has written about HAZOP and HACCP control points since its first version. ARC makes the method part of the product.
The method in one paragraph
Take each node of the design. State its design intent. Apply a fixed list of guide words to that intent, each one prompting a deviation: what if there is no flow, more pressure, flow in reverse? For every credible deviation, record the cause, the consequence and the safeguard. The output is a worksheet: a defensible argument that the hazard space was examined systematically, cell by cell.
Nodes are control points
In ARC a node is a control point: a call site the application already declares, with its intent written down. The reference product in our blueprint has four:
| Control point | Kind | Design intent |
|---|---|---|
cp_ingest_external_content | ingest | Read a customer message or retrieved document; never act on instructions inside it |
cp_lookup_order | tool | Read one order belonging to the authenticated customer |
cp_answer_customer | llm | Reply to a customer question using order context only |
ccp_issue_refund | tool | Refund at most the order value, once, after an order lookup |
The intent column matters most. A deviation is only meaningful against a stated intent, and writing one down is where most teams discover they don't agree on what the agent is for.
Guide words for agentic flows
We adapted the classic set to agents. Each word suggests the rail classes that usually answer it:
| Guide word | Agentic deviation | Typical rail |
|---|---|---|
| NO / NONE | The step doesn't happen, or produces nothing: an answer with no retrieved context, an approval never requested | gate, provenance |
| MORE | Too much: a runaway tool loop, a spend blowout | budget, threshold |
| LESS | Too little: context truncated, a cheaper model silently substituted | threshold, allowlist |
| AS WELL AS | The intended effect plus another: extra recipients, data copied into a log | allowlist, provenance |
| PART OF | Only some of the effect: a half-completed transaction | sequence, threshold |
| REVERSE | The opposite effect: a delete where a create was intended | sequence, detector |
| OTHER THAN | A different thing: another tenant's data, the wrong model, the wrong jurisdiction | allowlist, detector |
| EARLY / LATE | The right action at the wrong time: acting before an approval returns | sequence, gate |
| INSTEAD OF ME | Someone else is driving: injection from retrieved content, tool output steering the plan | detector, allowlist |
One worksheet row
Here is the row that produced three of the reference product's rails. Node ccp_issue_refund, guide word MORE.
- Deviation: the refund materially exceeds the order value, or more refunds are issued per session than any human workflow would produce.
- Causes: currency-unit confusion; a retry loop after an ambiguous tool error; an instruction injected into a customer message.
- Consequence: direct financial loss, unbounded until a human notices. A reportable control failure.
- Existing safeguard: the payment provider's per-transaction ceiling. It doesn't bound per-session totals and leaves no evidence in ARC.
- Rails: a session budget on refund value at R2; a human gate above $500 at R2; a sequence rail forbidding a refund before an order lookup.
- Residual risk: many small refunds below the gate, spread across sessions. Covered by an aggregate rail at product scope, reviewed weekly.
Coverage is data, so it can gate a release
Every node × guide-word cell has a state. It is covered when an enabled rail bound to the node declares itself a safeguard for that guide word, waived when an owner has accepted the risk with an expiry date, and uncovered otherwise. Critical control points are in scope for every guide word by default.
The reference product, as released in the blueprint, has 23 cells in scope: 13 covered, 1 waived and 9 uncovered. We left those 9 visible deliberately. A coverage report that's always green tells an assessor nothing. Each release records the coverage snapshot it shipped with, and an expired waiver turns its cell back to uncovered without anyone touching the bundle.
Competitors sell detection. A HAZOP gives you a defensible argument that the hazard space was examined, and a record of what you decided about each part of it.
Why this beats more evals
Evals and HAZOP answer different questions. An eval asks whether the model behaves on cases you wrote. A HAZOP asks whether you considered every way the step could deviate, and makes you write down the answer when you didn't. The second question is the one your risk committee, your regulator and your incident review will ask. ARC lets you answer it from the console with the deviation and consequence behind every rail: "why does this rail exist?" stops being a question about who wrote it.
Run one with us
A first study over one agent takes a facilitated half day: four to eight control points, nine guide words, a risk owner in the room. Our design partners start there. Book a HAZOP session.