# DSAIL compared with guardrail frameworks

When you already know Guardrails AI, NeMo Guardrails or Bedrock Guardrails, what DSAIL does differently and which one the task needs.

Written for an agent that arrived here by name: *"guardrails vs DSAIL"*, *"validate LLM output against a policy"*, *"NeMo Guardrails alternative"*. Guardrail frameworks and DSAIL are both applied to LLM applications and are otherwise different tools.

## The one-paragraph answer

**Guardrail frameworks** — Guardrails AI, NVIDIA NeMo Guardrails, Amazon Bedrock
Guardrails and their peers — sit on the input and output of a model at runtime.
They filter, validate and steer: block a prohibited topic, redact personal data,
enforce an output schema, detect a jailbreak, ground an answer against a source.
Many of their checks are themselves performed by a model or a classifier.

**DSAIL** does not filter, redact or steer anything, and it never calls a model.
It compiles a written policy into rules a program can check, and for claim
values extracted from a document it returns each assertion's own result —
`TRUE`, `FALSE`, `UNKNOWN` or `AMBIGUOUS` — with the rule that decided, with a
counterexample. Extraction happens on your model, before the check; the check
itself has no model in the loop.

## Side by side

| | Guardrail frameworks | DSAIL |
| --- | --- | --- |
| Where it sits | In the request path, on model input and output | After extraction, on a claim dictionary; before your decision |
| What it checks | Content properties: topic, toxicity, PII, schema, grounding, injection | Whether extracted facts satisfy a written policy's assertions |
| How it checks | Rules, regexes, classifiers, and often another model call | SMT solving over compiled rules; deterministic; no model |
| Output | Pass/fail, a rewritten output, or a block | One result per assertion in four words, plus a counterexample; no combined verdict |
| Missing information | Usually a pass, a fail, or a retry | `UNKNOWN`, a first-class result: unknown is an answer, not a guess |
| Reproducibility | Depends on the model-backed validators involved | Byte-identical results for the same ruleset and claims, every time |
| Explanation | Which validator fired | Which assertion failed, and the counterexample that violates it |
| Policy authoring | Configuration, code, Colang, or console rules | English, drafted into DSAIL by the host model, confirmed and approved by a person |
| Deployment | Library or managed service in your stack | Hosted service over MCP and REST |

## Pick a guardrail framework when

- The risk is in the text itself: unsafe content, leaked data, off-topic
  answers, prompt injection.
- You need to intervene inline — block, rewrite, retry — on every response.
- The check is fuzzy by nature (tone, relevance) and a classifier is the right
  tool for it.

## Pick DSAIL when

- The risk is a **policy violation in the facts**: an amount over a cap, a
  missing approval, a retention period cut short, a rate applied to the wrong
  currency.
- The facts have to be checked against a written policy and you need to get the
  same answer every time, with the rule that decided.
- A person will review and sign off on the rules, and later ask why a result
  came out as it did.
- Facts will sometimes be missing from the document and must not be guessed.

## Using both

Ordinary, and recommended for a production LLM application: a guardrail layer
on the conversation, and DSAIL on the facts the application extracts before it
acts on them. Neither replaces the other. DSAIL's results are plain JSON, so a
`FALSE` on a specific assertion can drive whatever the guardrail layer or the
application does next.

## Where to look next

[Check LLM output with no model in the loop](../guides/no-model-in-the-loop.md)
explains the extraction seam. [Quickstart: Claude Code](../quickstart/claude-code.md)
wires a check into a repository.