Skip to main content
QWED is a new layer in the AI stack: deterministic verification. While many tools exist to improve LLM outputs—ranging from better training (RLHF) to context retrieval (RAG) and structural validation (Guardrails)—QWED serves a distinct purpose. It does not try to make the model “smarter” or “safer” through probability. Instead, it treats the model as an untrusted translator and checks the claims in its output with deterministic engines (Math, Logic, SQL, etc.). This document compares mechanism and scope, not quality. For what another project does, its own documentation is the authority; follow the links. If you are evaluating formal verification for LLMs, AI agent guardrails, or runtime output validation, this is the right place to map QWED against adjacent approaches.

​
Comparison matrix

​
1. QWED vs. RLHF / Constitutional AI

RLHF (Reinforcement Learning from Human Feedback) and Constitutional AI are training-time techniques designed to align a model’s general behavior with human values (helpfulness, honesty, harmlessness).

​
Key differences

  • Training vs. runtime: RLHF is baked into the model weights during training. QWED sits outside the model, verifying outputs in real-time.
  • Probabilistic vs. deterministic: An RLHF-tuned model is less likely to be wrong, but it can still hallucinate confidently. QWED checks the answer mathematically; if the output says 2+2=5, the Math engine returns CORRECTION_NEEDED with the calculated value, regardless of how “aligned” the model is. That result is not admitted, and your integration holds the answer.
  • Scope: RLHF covers tone, style, and safety guidelines. QWED covers claims with a formal statement: math, logic, SQL and code.

​
When to use what?

  • Use RLHF to ensure the model is polite, refuses illegal requests generally, and follows instructions.
  • Use QWED when a specific calculation, logical deduction, or SQL query should go ahead only with a reproducible proof of its formal statement.

​
2. QWED and Guardrails AI

Guardrails AI describes itself as running Input and Output Guards that detect, quantify and mitigate specific types of risk, with validators collected in Guardrails Hub, and as helping generate structured data from LLMs (its docs). Structured generation libraries such as guidance and lmql constrain the shape of the output.

​
Key differences

  • Mechanism: QWED proves or disproves a formal statement with a deterministic engine; no model decides the verdict. Guardrails AI applies validators; how each one works is described in its own docs.
  • Scope: QWED covers claims that have a formal statement (math, logic, SQL, code, schema). Guardrails AI covers risks its validators address, including ones with no formal statement to prove, which QWED does not try to cover.
  • Default: QWED fails closed: a claim it cannot check is denied.

​
When to use what?

  • Use Guardrails AI or structured generation to shape the response and to check risks its validators cover.
  • Use QWED to check the claims within that structure (for example, whether the SQL query inside the JSON is safe to run).
  • They are complementary: one can guard the response, the other can check the claims inside it.
See also QWED and Guardrails AI.

​
3. QWED vs. RAG systems

RAG (Retrieval-Augmented Generation) systems like LangChain and LlamaIndex address hallucinations by providing the model with relevant context (documents, wikis) before it answers.

​
Key differences

  • Retrieval vs. verification: RAG provides input (context). QWED verifies output (conclusions).
  • Knowledge vs. reasoning: RAG solves “unknown knowledge” (the model doesn’t know your internal policy). QWED solves “flawed reasoning” (the model has the data but calculates the wrong sum).
  • Groundedness vs. correctness: RAG ensures the answer is based on the docs. QWED ensures the answer logically follows from the docs (using the Logic Engine).

​
When to use what?

  • Use RAG to give the model access to private data or recent news.
  • Use QWED to ensure the model interprets that data correctly (e.g., verifying a summary of financial tables matches the actual numbers in the rows).

​
4. QWED vs. red teaming tools

Red Teaming tools like Giskard, PyRIT, and Garak are offline testing platforms. They attack the model with thousands of adversarial prompts to find weaknesses before deployment.

​
Key differences

  • Attack vs. runtime check: Red teaming tools simulate attackers to find weaknesses. QWED checks each claim at runtime and returns a decision that your integration enforces.
  • Testing vs. production: Red teaming gives you a report on the model. QWED gives you a decision on one specific answer, with the formal statement it checked.
  • Estimated risk vs. rule check: Red teaming estimates risk. QWED applies deterministic rules (e.g., the Code Engine flags eval() regardless of prompt injection attempts).

​
When to use what?

  • Use Red Teaming during development/CI to benchmark model performance and find blind spots.
  • Use QWED in production to deny claims that cannot be proven, within the domains it covers.

​
5. Summary: the right tool for the job

QWED is not a “do-it-all” solution. It checks claims that can be stated formally, and denies the ones it cannot prove.

​
Where QWED excels (use QWED)

  • Math & finance: Calculations, tax logic, financial reports.
  • Code generation: Verifying syntax, security, and logic.
  • Formal logic: Checking policy compliance, contract contradictions.
  • Data consistency: Verifying summaries against structured data (CSV/SQL).

​
Where QWED is not the best choice (use alternatives)

  • Creative writing: Writing poems, marketing copy, or fiction. (Use RLHF optimized models).
  • Open-ended chat: “Tell me about the history of Rome.” (Use RAG).
  • Subjective analysis: “Is this email polite?” or “What is the mood of this text?” (Use a validator or model built for tone).
  • General knowledge: “Who won the 1998 World Cup?” (Use Search/RAG).
Conclusion: In an AI stack, RAG provides the knowledge, Guardrails and structured generation shape and check the response, red teaming tests the model before release, and QWED checks formal claims at runtime. QWED verifies the formal statement, not intent; see qwedai.tech/limits.