Don't trust AI output. Verify it.
QWED is the open-source AI verification infrastructure for LLMs and AI agents
A model is a fluent stranger. It will hand you the number you were hoping for, in the voice of someone who counted. QWED is the open-source AI verification infrastructure that stands between that voice and your production system — recomputing the claim, replaying the tool call, inspecting the agent's next move. Nothing passes on charm. The layer is fail-closed by default: what cannot be proven does not ship.
Arithmetic · Logic · Code · SQL · Tool calls · Agent state
“Revenue grew by 15% compared to last quarter.”
The dataset says −2.3%. Fluent, confident, and off by a direction.
“Revenue declined by 2.3% compared to last quarter.”
Counted again from the rows, and returned with a hash you can check.
The verification infrastructure and the GitHub-native application
QWED Verification is the platform. QWED Security is the developer-security application built on it.
QWED Verification is the foundational open-source layer. It translates model intent into structured claims or actions, runs defined verification engines, returns structured diagnostics and evidence, and supports downstream admission decisions.
QWED Security is a GitHub-native application built on QWED's verification architecture. It checks pull requests and release boundaries for defined code, secret, PII, policy, and artifact risks, then reports explicit outcomes in GitHub Checks.
How they connect: QWED Verification is the foundation; QWED Security is a developer-facing GitHub application that applies that foundation to pull requests and release workflows.
QWED Verification
Open-source verification infrastructure for AI outputs, tool calls, code, schemas, and agent state. Deterministic engines, evidence, and fail-closed outcomes.
Explore enginesQWED Security
Deterministic security verification for pull requests and release boundaries. Context-aware classification, AST analysis, secret detection, and explicit BLOCK / WARN / INFO / UNVERIFIABLE outcomes in GitHub Checks.
The distance between fluent and true
An assistant is allowed to be wrong sometimes. A system that prices, approves, executes or advises is not.
A model speaks in probabilities and never says so. A production system runs on certainties and cannot ask. Between those two sentences there is a gap no amount of prompting closes, and nearly every AI incident of the last two years has happened inside it. AI hallucination prevention, put plainly, is not a prompting problem — it is a checking problem, and a check that is not deterministic is only a second opinion.
This is not a flaw in the model. It is a missing piece of architecture — the same way a bank vault is not a criticism of cashiers. Something must stand outside the model and check its work.
- ICount
Probability, not proof
A model returns what is likely, not what is true. Likely is a weather forecast. Your ledger is not weather.
- IICount
One wrong answer is the whole story
In finance, legal, infrastructure and agent workflows, accuracy is not an average. A single wrong output is an incident with a date on it.
- IIICount
Words became actions
Once a model can call a tool, approve a payment or write to a system, a bad sentence stops being a bad sentence and becomes an event.
- IVCount
No evidence, by default
Most AI stacks ship decisions with nothing behind them. When someone finally asks how you knew, silence is the answer you have prepared.
“Nobody signs off on a probability. They sign off on a verified outcome.”
Trust was never in the model.
It was always in what you could check.
Put a deterministic verification layer in front of every output, tool call and state change — LLM output verification, applied before anything acts — and three qualities you used to argue about become things you can simply look up.
- Security
Depended onprompt quality
Now: whether the call passed the gate.
- Reliability
Depended onconfidence scores
Now: whether the value was re-derived.
- Compliance
Depended onmanual review alone
Now: the ledger entry the check wrote.
They stop being things you hope about. They become things the system knows.
Four steps, and only two of them count
The layer sits between the model and your production system, and belongs to neither.
Every output arrives as a rumour and stays one until an engine that cannot be charmed re-derives it. Every state change an agent proposes stays a proposal until a governed check lets it through. Nothing is trusted because it sounded right. Named plainly, that is verified tool calls and verified agent state, both settled before either one reaches your systems.
- 01
Someone asks
A person, a workflow, or an agent with a schedule and no supervisor.
- 02
The model answers
ProbabilisticIntent becomes a draft: a number, a query, a plan. Fluent, immediate, unproven.
- 03
QWED re-derives it
DeterministicDeterministic engines compute the claim again from scratch, or read the tool call line by line.
- 04
Passed, blocked, or corrected
Production safeOnly what was proven continues. Everything else fails closed — quietly, completely, on the record.
Two jurisdictions. One governs what a system is allowed to say; the other governs what it is allowed to remember.
Output verification
v6.0.0- LLM output
- → Math / Logic / SQL / Code / Stats verifiers
- → VERIFIED / UNVERIFIABLE / BLOCKED
- → DiagnosticResult + sha256 proof_ref
State governance
v6.0.0- Agent state proposal
- → AgentStateGuard: structural + semantic check
- → Atomic commit, or BLOCKED
- → Nothing partial is ever written
Treat the model as an interpreter, not a witness
Useful. Fluent. Not under oath. The proof is the source of truth; the model is only the draft.
A court will happily use an interpreter and still check the transcript. That is the whole posture: whatever the model says is a draft in another language, and the draft gets read against the record before anybody acts on it.
Your application sends its prompt to the provider and waits, the way anyone waits for a translator to finish.
Your app
Production environment
The untrusted translator
LLM — OpenAI / Anthropic
The trusted verifier
SymPy / Z3 / SQLGlot / CrossHair
App → LLM → QWED → App
Twelve engines, none of them guessing
Each one owns a single domain, and each one defers to an authority older than the hype cycle. Install the ones your risk actually lives in.
- 01SymPy
Math & finance
Calculus, matrices, and financial formulas solved symbolically — the algebra done, not approximated.
- 02Z3
Formal logic
A theorem prover looking for the counterexample: quantifiers, bit-vectors, contradictions you would not have found.
- 03SQLGlot AST
SQL armor
The query is parsed into a tree and read as structure — injection caught, complexity capped, schema honoured.
- 04CrossHair
Code security
Multi-language AST analysis with symbolic checks. eval, exec, and a leaked secret never reach the runtime.
- 05JSON Schema
Schema verifier
Shape checked deterministically, with any computed field handed to the math engine rather than trusted.
- 06pandas · Pandera
Statistics
pandas and polars run sandboxed, under schema validation and strict isolation. The numbers are recounted, not quoted.
- 07TF-IDF
Fact verifier
Deterministic term and keyword analysis. No second model in the loop, and therefore no second thing that can hallucinate.
- 08Triples
Knowledge graph
Claims broken into triples and matched against a structured graph — checked against what is recorded, not what is plausible.
- 09Multi-VLM consensus
Vision verifier
Metadata verified outright; for semantic claims, several models must agree before anything counts.
- 10Multi-provider
Consensus
For claims no formal method can settle: agreement scored across providers, and the disagreement kept visible.
- 11CoT · IRAC
Reasoning
The steps of the argument validated as a process — chain-of-thought and IRAC — with results cached.
- 12Rule sets
DSL logic
Your own policy and business rules, written down once and enforced identically every time they are asked.
Two hundred and fifteen chances to be wrong
Run without a verification layer, the best models still fail where failure costs something. Not often enough to notice, and never on a schedule you could prompt around. The bars below are the same tasks with the gate closed and with it open.
Financial accuracy
100%error detection with QWED
Verified
73% · raw LLM
Detecting all mathematically verifiable errors within scoped financial domains.
Logic contradictions
0%leakage rate with QWED
Verified
85% · LLM pass-through
Z3 detects logical contradictions within formally defined reasoning scopes.
Code security
100%blocked threats with QWED
Verified
60% · unverified
AST analysis detects dangerous imports, eval injections, and leaked secrets.
The $12,889 rewards error
An LLM told a customer their card held $12,889 in rewards. It did not. The number was never looked up — it was written, in the same flat, certain tone a true number would have arrived in. That is the part worth sitting with: nothing about the sentence looked wrong.
Without verification
A balance that never existed reaches a customer, becomes a complaint, and then becomes a legal file. Nobody can say where the figure came from, because no step in the system was ever capable of saying.
With QWED
The finance engine counts the balance again from source data, refuses the invented figure, and hands back a result that can be defended — carrying a proof_ref that will still mean something in a deposition two years from now.
Every check leaves a line you can cite.
Three verdicts, and no fourth. A VERIFIED result cannot be constructed without a proof reference — that is enforced by the type, not by convention, which is why the unverifiable rows below have no digest. An auditable AI agent is not one that explains itself afterwards; it is one that wrote the line down at the moment it decided, which is the entire job of AI compliance middleware.
| proof_ref | Claim | Verdict | Engine | ms |
|---|---|---|---|---|
| sha256:9f2c…a41d | Q3 revenue declined 2.3% quarter over quarter | VERIFIED | stats | 41 |
| sha256:4e19…2fc7 | IRR of the payment schedule is 12.4% | VERIFIED | math | 64 |
| sha256:1b83…07e2 | ∀x. premium(x) → ¬eligible(x) ∧ eligible(customer_7) | BLOCKED | logic | 12 |
| sha256:c04e…5db9 | SELECT * FROM accounts WHERE id = '1' OR '1'='1' | BLOCKED | sql | 3 |
| sha256:77a1…be60 | exec(user_input) inside the request handler | BLOCKED | code | 8 |
| — | Market sentiment is improving | UNVERIFIABLE | fact | 19 |
| — | Agent proposes a state write via an unregistered tool | BLOCKED | AgentStateGuard | 2 |
Example entries, with digests truncated. The columns are the real ones.
CWE-95 · CVSS 8.8
SymPy expression injection
An authenticated remote code execution path through parse_expr(). Closed in v5.1.2 by safe_parse_expr() and get_safe_symbol(), with Redis failing closed on error.
CVE-2026-24049 · Critical
Sentinel Edition hardening
Disclosed and fixed in v4.0.0 alongside 19 Snyk findings, RAGGuard, ExfiltrationGuard, MCP Poison Guard, SovereigntyGuard and ToxicFlowGuard.
Everything else improves the odds. One thing settles them.
RAG, guardrails and fine-tuning all make a good answer likelier. None of them can tell you whether this answer is right.
| Approach | Focus | Deterministic | Guarantee | Best for |
|---|---|---|---|---|
| QWED verification | Correctness | Yes | Proof-backed checks | Production AI and agent actions |
| Guardrails | Structure | No | Validation rules | Formatting and output contracts |
| RAG (retrieval) | Knowledge | No | Better context | Private docs and recent information |
| Fine-tuning / RLHF | Behaviour | No | Probabilistic improvement | General model behaviour |
| Prompt engineering | Prompt quality | No | None | Fast iteration and demos |
QWED verification
DeterministicCorrectness · Proof-backed checks · Production AI and agent actions
Guardrails
ProbabilisticStructure · Validation rules · Formatting and output contracts
RAG (retrieval)
ProbabilisticKnowledge · Better context · Private docs and recent information
Fine-tuning / RLHF
ProbabilisticBehaviour · Probabilistic improvement · General model behaviour
Prompt engineering
ProbabilisticPrompt quality · None · Fast iteration and demos
Nothing leaves. Nothing is assumed.
Zero trust is not a posture here, it is the default value. Every critical output has to earn its way out.
For teams whose data cannot travel and whose decisions have to be explainable a year later: run the layer inside your own walls, keep the sensitive fields masked before the model ever sees them, and attach signed evidence to every verification that matters. The same boundary does the unglamorous half of AI agent security — taint analysis is prompt injection defense with a proof attached, because it follows the untrusted sentence all the way to the place it would have done the damage.
“Do not trust the generated output. Verify it.”
Written for regulated environments, where “we think it was right” is not an answer.
§1
It runs where you are
Docker, Kubernetes, or an air-gapped rack in a room with a lock. The verifier never needs to cross your boundary to do its work, so it doesn’t.
§2
The sensitive parts stay home
Mask PII before the model ever sees it. The policy that decides what counts as sensitive lives inside your boundary, in a file your own reviewers can read.
§3
Your data trains nothing
QWED verifies; it does not learn. There is no model here that gets better because you used it, and therefore no quiet incentive pointing the other way.
§4
Every pass leaves a receipt
A VERIFIED result carries a sha256 proof_ref. It is the difference between remembering that something was checked and being able to show it.
A gate you can’t inspect is just another thing to trust
The layer standing between model output and production execution has to be readable by the people whose names are on the release.
We are asking you to stop taking a model’s word for things. It would be strange to then ask you to take ours. So the whole deterministic verification layer is Apache 2.0: inspectable, forkable, and deployable in your own environment, with nothing in it you are required to believe.
“You cannot ask teams to trust a black-box verification layer.”
01
Read every check
A gate you cannot see inside is just a rumour with a logo. The logic, the proof paths, the reasons for refusal — all of it is on the page.
02
Test the determinism yourself
Anyone can claim reproducibility. Here you can run it twice and diff the output, which is a different kind of claim entirely.
03
Deploy it anywhere
Self-hosted, private, air-gapped. Regulated teams do not get to send their data somewhere hopeful, and open source is what makes staying home possible.
04
Belong to no one
Verification should be a portable layer under every model and stack — a standard, not a feature one vendor gets to price.
Watched by people who are not us
Twelve providers scan, build, review and ship this project on a schedule we do not control. Outside eyes are a feature, not a logo wall.
- DockerDocker-Sponsored Open Source
- SnykContinuous vulnerability scanning
- CircleCIEnterprise-grade CI/CD
- NetlifyPro-tier deployment and edge
- SentryError tracking and performance
- CloudflareProject Alexandria
- CodeRabbitAI-powered code review
- NVIDIAInception Program
- BuildkiteCI/CD at scale
- GitLabDevSecOps platform
- HerokuCloud platform
- AtlassianCollaboration tools
Eight places a wrong number costs money
QWED is not a single tool. It is a modular verification layer spanning finance, legal, infrastructure, and AI agent workflows — one core, and eight sets of rules for the domains where being confidently wrong is expensive.
Each package knows one domain’s arithmetic and vocabulary. Take the ones you need, leave the rest.
- qwedCore
Core 12-engine verification protocol
- qwed-mcpAgents
MCP tool-call and server verification
- qwed-open-responsesAPI
Verified OpenAI-compatible responses
- qwed-financeFinance
Banking, interest rates, ISO 20022
- qwed-legalLegal
Contract deadlines and citations
- qwed-taxTax
Tax compliance and withholding
- qwed-infraInfra
IaC verification — Terraform, IAM
- qwed-ucpCommerce
E-commerce transaction verification
One line, then a gate
Model-agnostic and unbothered about whose API you are calling. Installed in seconds, answering in milliseconds.
Python
PyPIqwed
TypeScript
npm@qwed-ai/sdk
Go
Go modulesqwed-go
Rust
crates.ioqwed
A sentence can be corrected. An action cannot.
Output → execution
The interesting moment is not when a model writes something wrong; it is when a model does something wrong. The same deterministic verification layer that refuses a bad answer today is what will govern automation nobody is watching tomorrow. That is what AI agent security has to mean once agents transact with each other: not a policy document, but a gate every action has to pass.
Agents
Agent workflows
An agent calling tools and approving its own next step is a loop with no adult in it. Every action needs a policy check and a verdict.
Money
Finance operations
Underwriting, reconciliation, risk. The arithmetic has to be done — actually done — before anything moves.
Counsel
Legal review
A clause extracted wrongly reads exactly like a clause extracted correctly. The reasoning has to be checkable, and the trail has to survive.
Machines
Machine commerce
When software buys from software, nobody is reading the confirmation email. Verified execution becomes the only handshake left.
“If software can act, its actions must be verifiable.”
- CI workflows
- Sits in the pull request, where a refusal is cheap
- Container deployment
- Same image on a laptop, a cluster, or a network with no way out
- Python and JavaScript
- Published where your application already looks for things
- Infra ecosystem
- Built to sit beside the security, CI and hosting tools you already run
Ready
Portable
Available
Growing
- Mission
- Make what a model says safe enough to act on, by proving it first.
- Vision
- Be the deterministic verification layer standing between AI reasoning and the real world.
Read the checks. Run them yourself. Then decide what to trust.
Questions put to the record
Eight things people ask before they trust a gate with their production traffic.
RAG feeds the model better documents. QWED reads the answer that comes back out. One improves what goes in; the other decides what is allowed out. RAG adds knowledge, QWED adds certainty, and you probably want both.
Anything whose correctness can actually be established: math, logic, code, SQL, schemas, process flows, and agent tool calls. Every check ends in one of three verdicts, and the claim is approved, corrected, or blocked before it can execute.
Yes. QWED is model-agnostic and works with GPT-4, Claude, Gemini, Llama, Mistral, and whatever ships next month. It verifies outputs rather than trusting a provider, so changing models does not change what you can prove.
No. Fine-tuning shapes how a model behaves, its style, and its fit to a task. It still cannot tell you whether this particular answer is correct or safe to execute. QWED is the check after the behaviour, not a replacement for it.
Yes, Apache 2.0. A verification layer you cannot read is one more thing you are being asked to believe, so the core is inspectable, auditable, and self-hostable by design.
It depends on the engine. Symbolic checks over math, SQL, or logic usually finish in milliseconds; consensus and multi-model paths take longer. The more useful question is not how long a check takes, but what an unverified output costs on the day it is wrong.
It means the same input produces the same verdict, every time, with no sampling in between. The math, logic, SQL, code, and schema engines use symbolic solvers and program analysis rather than asking another model for its opinion.
Yes. QWED is built to run inside your own infrastructure, with your own model providers and your own verification policy. Nothing about checking an answer requires your data to leave the building.