--- title: "What fail-closed means for AI checks" description: "A check on AI output can fail too: a solver times out, a model call errors, a claim cannot be read. Fail-closed means the action does not go ahead when that happens. A definition, three questions to ask of any tool, and how QWED applies it." url: https://qwedai.com/guides/fail-closed --- # What fail-closed means for AI checks. A check on AI output can fail too. A solver times out, a model call errors, a claim cannot be read. Fail-closed means that when the check cannot finish, the action does not go ahead. Definition **Fail-closed:** every outcome other than a completed, positive result stops the action by default. That includes errors, timeouts, inputs the check cannot handle and cases no rule covers. **Fail-open** is the opposite: when the check cannot finish, the action goes ahead. From safety and security engineering, long before AI: a lock that stays locked when the power fails, a firewall that drops traffic it has no rule for. ## Why it matters more for _AI_ - ### Wrong answers sound right A model is as fluent when it is wrong as when it is right, so the check is often the only thing that notices. - ### The checks have more ways to fail Checking AI output means parsing free text, calling solvers and sometimes other models. Each can time out or error, far more often than a simple rule. - ### Agents act on their own Nobody is watching the moment the check fails. A fail-open check under load or during an outage quietly becomes no check at all. ## Watch a check _fail_. Pick what goes wrong. The same claim from your AI takes both paths: one check that fails open, one that fails closed. **Fails open** If the check cannot finish, carry on AI claim Your systems Timed out Goes ahead, unchecked **Fails closed** If the check cannot finish, stop AI claim Your systems Timed out · denied Held What QWED returns `UNVERIFIABLE · DENY` A Z3 timeout or unknown result is never VERIFIED, so the claim is held. ## Three questions to ask of any check “Fail-closed” on a product page can mean any of these, or only one. 1. 1 ### What happens when the check errors or times out? The solver gives up, a model call fails, a dependency is missing. Fail-closed: denied. Fail-open: it goes ahead as if it had passed. 2. 2 ### What happens with an input it cannot handle? A claim outside what the check understands, or one it cannot parse. Fail-closed: held or denied, never treated as a pass. 3. 3 ### What happens when no rule says anything? A policy with no matching rule, a scanner with nothing to report. Deny by default means silence is a deny. A tool can answer the first with “denied” and the third with “allowed”. Both are reasonable designs; they are not the same guarantee. ## How tools differ [Full comparison, with sources](https://qwedai.com/compare) From each project’s own documentation and code, checked on 15 October 2026. - On errors: denied ### Microsoft Agent Governance Toolkit Its specification says any error during evaluation yields a deny. When no rule matches, the policy’s own default decides; the quick start allows. - Depends on configuration ### NVIDIA NeMo Guardrails Its documentation says no library-wide failure policy applies to every rail; the behaviour depends on the engine and rail. - On errors: goes through ### OpenAI Guardrails (Python) In the default mode a check that errors lets content through; raising an error instead is an opt-in setting. - Detect-only ### Bedrock Automated Reasoning Returns findings and never blocks; your application decides what to do with them. ## How QWED applies it QWED keeps the [verdict](https://qwedai.com/glossary#verdict) (what was proven) apart from [admission](https://qwedai.com/glossary#admission) (whether it may go ahead). Only one combination admits. - A `VERIFIED` result must carry a [`proof_ref`](https://qwedai.com/glossary#proof-ref) ; `UNVERIFIABLE` and `BLOCKED` must not. The result object refuses to be built otherwise. - The [admission function](https://github.com/QWED-AI/qwed-verification/blob/main/src/qwed_new/core/diagnostics.py#L1114-L1135) returns `ADMIT` only for a result that is verified and valid; every other path, including a malformed result, is a deny. - The [Verification Context specification](https://github.com/QWED-AI/qwed-verification/blob/main/spec/v1.0/verification-context.md) requires that unknown, timeout and error outcomes are never `VERIFIED`. - Where an [attestation](https://qwedai.com/glossary#attestation) is required and missing or invalid, a verified result is turned into a deny. - The engine proves the claim holds `VERIFIED · ADMIT` - The engine proves the claim false or unsafe `VERIFIED · DENY` - No engine can prove it either way `UNVERIFIABLE · DENY` - The Z3 solver times out or returns unknown `UNVERIFIABLE · DENY` - The input cannot be parsed, or a setting or dependency is missing `BLOCKED · DENY` - An engine throws an error `BLOCKED · DENY` - An advisory engine or a model has an opinion `Never VERIFIED` ### What fail-closed does not mean **Not never wrong.** A bug that makes a check wrongly confident is a different failure. QWED has had them, published them, and measures for them on every release. **Not enforcement.** QWED returns the decision; your integration, a CI gate or a QWED product acts on it. An integration that ignores a deny lets the action through. **Not coverage.** Output that never passes through QWED is not held by it. [Evidence](https://qwedai.com/evidence) [Track record](https://qwedai.com/security#record) [Limits](https://qwedai.com/limits) ### When fail-open is fine For a suggestion a person will review anyway, or a signal shown beside an answer, keeping the product available can matter more than a missed check. QWED’s own advisory engines work this way: they inform, they never admit. The line is action. When a system will act without a person in between, the check should fail closed.