> ## Documentation Index
> Fetch the complete documentation index at: https://qwed-ai-mintlify-6a1e3354.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# QWED architecture: translation, verification, guards
> High-level QWED architecture separating untrusted LLM translation from deterministic verification engines, agent security guards, and signed attestations.
This page gives the high-level architecture.\
For deeper diagrams, see [Architecture diagrams](/advanced/architecture-diagrams).
QWED separates untrusted model translation from deterministic verification so you can enforce AI reliability, tool call verification, and zero-trust policy boundaries at runtime.
## Core principle
```mermaid theme={null}
flowchart LR
I[User input] --> T[LLM translation]
T --> S[Structured claim]
S --> V[Deterministic verifier]
V --> R[Result + evidence]
classDef untrusted fill:#fff4e5,stroke:#f59e0b,color:#92400e;
classDef trusted fill:#ecfeff,stroke:#06b6d4,color:#155e75;
class T,S untrusted;
class V,R trusted;
```
Translation is useful but untrusted. Verification is the trust anchor.
## Layered architecture
```mermaid theme={null}
flowchart TB
A[API Gateway] --> B[Translation Layer]
B --> C[Verification Engines]
C --> D[Security Guards]
D --> E[Attestation and Audit]
```
### 1) API gateway
* Authentication and authorization
* Rate limiting and tenancy controls
* Request routing and transport security
### 2) Translation layer (untrusted)
* Converts natural language into structured inputs
* Can use any LLM provider (cloud or local)
* QWED treats all output as untrusted until the verifier confirms it
### 3) Verification engines (deterministic)
Verification engines are grouped into three tiers with distinct output guarantees. Only **proof engines** can emit `VERIFIED` (with a `proof_ref`); the deterministic-verification claim above applies to supported proof domains. **Policy enforcement engines** emit `BLOCK` / `UNVERIFIABLE`, and **advisory engines** emit `AdvisoryCheck` records only. See [Verification engines](/engines/overview) for the full 3-tier classification.
| Engine | Purpose |
| -------------------------------------------- | --------------------------------------------------- |
| Math | Symbolic arithmetic and algebra checks (proof) |
| Logic | SAT/SMT verification and constraint solving (proof) |
| Code | AST and symbolic security analysis (proof) |
| SQL | Query safety and structure validation (proof) |
| Schema / Stats / Taint | Structural and data-flow proofs |
| Fact / Graph / Image / Reasoning / Consensus | Advisory analysis (no `VERIFIED`) |
### 4) Agent security guards
Guards inspect tool calls, contexts, and policy boundaries before execution.
| Guard | Purpose |
| --------------------- | --------------------------------------------------------- |
| RAGGuard | Defends retrieval contexts from injection/poisoning |
| ExfiltrationGuard | Prevents unauthorized data movement |
| MCPPoisonGuard | Validates MCP tool definitions and safety |
| SovereigntyGuard | Enforces data residency and routing policy |
| SelfInitiatedCoTGuard | Checks reasoning flow integrity |
| ProcessVerifier | Milestone-based process validation |
| StateGuard | Deterministic workspace rollback via shadow git snapshots |
### 5) Attestation and audit
Each verification can emit signed evidence for traceability and compliance workflows.
```python theme={null}
{
"query_hash": "sha256(...)",
"verification_result": true,
"engine": "QWED-Math-v2",
"timestamp": 1735689600
}
```
**v5.2.0** introduces the unified `DiagnosticResult` model with 3-layer diagnostics — agent-safe, developer, and proof. See the [Verification Diagnostics guide](/advanced/diagnostics) for the full model.
## Request lifecycle
```mermaid theme={null}
sequenceDiagram
participant Client
participant API as Gateway
participant T as Translator
participant E as Engine
participant A as Attestation
Client->>API: Submit query/action
API->>T: Prepare structured claim
T-->>API: Untrusted translation
API->>E: Verify deterministically
E-->>API: VERIFIED / FAILED / BLOCKED
API->>A: Optional signed attestation
API-->>Client: Result + proof metadata
```
## Security model snapshot
| Threat | QWED response |
| --------------------- | -------------------------------------------------------------------------- |
| Hallucinated claim | Rejected or corrected by deterministic check |
| Prompt injection | Translation can be poisoned; verifier and guards enforce policy regardless |
| Unsafe code or SQL | Blocked by parser, AST checks, and guard rules |
| Untrusted tool action | Guarded and policy-checked before execution |
## Related verification guides
The 3-layer DiagnosticResult model — agent-safe, developer, and proof diagnostics.
See how QWED verifies LLM outputs with formal methods instead of probability-only confidence.
Apply policy enforcement and pre-execution checks to autonomous agents.
Review production guidance for prompt injection defense and OWASP LLM risks.
## Deployment modes
| Mode | Fit |
| ----------- | -------------------------------------------- |
| Cloud API | Fastest start, hosted control plane |
| Self-hosted | Data control in your VPC/Kubernetes |
| Hybrid | Mix cloud scale with local policy boundaries |
## Next steps
1. [Core concepts](/getting-started/concepts)
2. [Architecture diagrams](/advanced/architecture-diagrams)
3. [SDK guards](/sdks/guards)
4. [Self-hosting](/advanced/self-hosting)