Where ARIA Sits
The gap between what a model says and what it does.
Input screening answers “was the prompt OK?”. ARIA answers the question nobody else does: “was the action actually allowed to happen, and is that decision provable later?”
Where ARIA Sits
Two layers. One governs what a model says. One governs what it is allowed to do.
Application layer — input screening
Prompt guardrails, AI gateways, and evaluation frameworks. They inspect what is offered to the model — the prompt and its context — and filter it before the model call. Typically fail-open, one message at a time.
inspects input · before the call · single message
complementary — not competing
State layer — ARIA
The execution boundary. ARIA inspects what the model wants to do — the proposed action — and admits or rejects it at the point of execution. Every decision is chained into the case history and can be reconstructed later. Fail-closed, whole case at a time.
inspects action · at execution · linked history
| Dimension | Application layer | ARIA state layer |
|---|---|---|
| What it inspects | Prompt / model input | Proposed action at the boundary |
| When it checks | Before the model call | At the point of execution |
| Failure mode | Fail-open (input logged) | Fail-closed (action blocked) |
| Unit of record | Single message | Linked case history |
| Reconstructibility | Logs are claims | History re-derived and verified |
Screening the prompt is not the same as governing the action. Run both: input screening shapes what the model is offered; ARIA governs what it is allowed to do. The two layers are complementary — ARIA does not replace them.
ARIA does not replace your guardrails, gateway, or evals. It sits below them, at the point where a decision becomes a consequence. See it in action on the chain page.
Book an evaluation. Bring a real deployment. Leave with a record you can verify.
In-person talks for risk officers, security researchers, and audit teams. No account. No browser scripts.