Engines
Every engine sits in one of three tiers. The tier decides what the engine is allowed to claim: only a deterministic proof can make a result verified.
Three tiers
A request flows through the tiers in order. Proof engines try a deterministic proof, policy guards apply runtime rules, and advisory engines add structured diagnostics. Since v6.0.0 every path returns the same DiagnosticResult model.
Proof engines
Proof engines use symbolic solvers and formal methods. Verified always comes with a proof_ref. For the domains they cover, an answer either has a reproducible proof or it is not verified.
| Engine | Backend | Domain |
|---|---|---|
| Math | SymPy + Decimal | Arithmetic, calculus, matrices, NPV/IRR |
| Logic | Z3 | SAT/SMT, quantifiers, bit-vectors |
| SQL | SQLGlot AST | Query structure, complexity, schema |
| Code | Multi-language AST | Python, JS, Java, Go security analysis |
| Schema | Pydantic + Math | JSON structure and embedded calculations |
| Stats | Pandera + Wasm | Data-frame invariants, sandboxed execution |
| Symbolic | CrossHair | Reference DiagnosticResult engine |
{
"status": "VERIFIED",
"engine": "QWED-Math-v2",
"proof_ref": "sha256:9f2c...",
"evidence": {"expression": "2+2", "value": 4}
}Policy guards
Policy guards apply deterministic rules to inputs, context and tool calls at runtime. The same input against the same policy always gives the same decision. They never produce a proof, so they can block or hold, but not verify.
| Guard | Purpose |
|---|---|
| SystemGuard | System-prompt integrity and policy binding |
| ConfigGuard | Secret detection and configuration policy |
| RAGGuard | Retrieval-context injection and poisoning defence |
| MCPPoisonGuard | MCP tool definition validation |
| ExfiltrationGuard | Unauthorised data-movement prevention |
| SelfInitiatedCoTGuard | Reasoning-flow integrity |
| SovereigntyGuard | Data residency and routing policy |
| StartupHookGuard | Startup and hook integrity |
| ProcessVerifier | Milestone-based process validation |
{
"status": "BLOCK",
"engine": "ConfigGuard",
"reason": "SECRETS_DETECTED",
"decision_trace": ["match:OPENAI_API_KEY@api_key"]
}Advisory engines
Advisory engines handle questions where no formal proof exists. Their heuristic and model-based results are recorded as advisory checks, which are inputs for review and never a verdict by themselves. Graph and Image are hybrids: their deterministic path can still return verified. A model fallback never overrides a deterministic result.
| Engine | Deterministic path | Advisory only |
|---|---|---|
| Fact | TF-IDF and entity matching. Capped at unverifiable, or blocked when refuted. | LLM fallback |
| Graph | A full triple match can return verified. | NLI fallback |
| Image | Pixel and metadata evidence can return verified with a proof_ref. | VLM cross-check |
| Reasoning | None. | LLM providers and heuristics |
| Consensus | Keeps each engine’s verified, unverifiable or blocked status. | Non-unanimous agreement |
Other checks
Taint analysis follows untrusted input through generated code and blocks it before it reaches a sensitive sink such as SQL or a shell. Domain packages such as qwed-finance add their own guards on top of these engines.
Full reference for every engine, including inputs and result fields: docs.qwedai.com/engines.