Skip to main content
The official TypeScript/JavaScript SDK for QWED.

Installation

Quick start

Configuration

Reading a result

Every verify* method except verifyAgent returns a VerificationResponse that models the server’s DiagnosticResult envelope. Numbers come from JSON.parse, so an integer above 2^53 or a long decimal is rounded. JSON.stringify of a parsed response writes the server’s status text back as status when status is UNKNOWN, so a cached or logged response keeps it.

Gate on isAdmitted()

Use isAdmitted(result) to decide whether to act on a result. Don’t gate on status alone. VERIFIED means the engine reached a deterministic answer, not that the claim holds. 2 + 2 = 5 returns VERIFIED · BLOCKED because it’s proven false. Unsafe code returns VERIFIED · BLOCKED because it’s proven unsafe. isAdmitted() returns true only when all of these hold:
  • admission is ADMIT
  • status is VERIFIED
  • proof_ref is a non-empty string
A missing or unknown admission is never admitted. Endpoints that make no admission decision (/verify/logic, /verify/fact, /verify/rag, /verify/process, and batch logic and fact items) are therefore never admitted. The top-level verified that /verify/rag and /verify/process send is their guard’s own result. The parser replaces it, and the guard’s value stays in developer_fields.verified.
The verified field and isVerified() are deprecated. The parser always sets verified to isAdmitted(result), whatever the body says, and isVerified() returns isAdmitted().

Parsing responses yourself

If you call the QWED API without the client, pass the parsed JSON body to parseVerificationResponse() or parseBatchResponse(). The client uses the same functions. They throw a QWEDError with code QWED-SDK-PARSE-001 when a body isn’t a verification result, and QWED-SDK-PARSE-002 when a body isn’t a batch job.

Verification methods

Every method returns a promise that rejects with a QWEDError on a network error or a non-2xx response. The short examples below leave that out; wrap your calls as the examples above and Error handling show, and treat a rejected call as not admitted.

verify(query)

Auto-detect and verify any claim.

verifyMath(expression)

Verify mathematical expressions.

verifyLogic(query)

Verify logical constraints using QWED-Logic DSL.

verifyCode(code, options)

Check code for security vulnerabilities.

verifyFact(claim, context)

Verify factual claims against a provided context.

verifySQL(query, schema)

Validate SQL queries against a schema.

verifyProcess(reasoningTrace, options)

New in v4.0.1
Validate the structural integrity of LLM reasoning traces. Use this to ensure workflows follow deterministic process steps with IRAC pattern matching or custom milestone validation.
You can also verify custom milestones:

verifyRAG(targetDocumentId, retrievedChunks, options)

New in v4.0.1
Verify that retrieved RAG chunks originate from the expected source document. This prevents Document-Level Retrieval Mismatch (DRM) hallucinations in RAG pipelines.

verifyBatch(items)

Verify multiple items at once. The response is a BatchResponse that mirrors the server’s batch job: job_id, status (the job state: pending, processing, completed, partial, or failed), progress_percent, total_items, completed_items, failed_items, and items. There is no aggregate summary. Each item has an id, a status (the item state, such as completed or failed), and a result holding its DiagnosticResult. Gate each item with isAdmitted(item.result). Math, code and SQL items carry their route’s admission, so an item can be admitted. Natural-language items carry one too, but it is always BLOCKED, because nothing proves the translation. Logic and fact items make no decision, so they’re never admitted.
A batch SQL item needs params.schema_ddl. The server fails an item without it with Missing 'schema_ddl'. The SDK’s batch items send only a query and a type, so verify SQL with verifySQL() instead of in a batch.
For math items, supply equality claims (e.g., 'x + x = 2*x') to receive proof results. Expressions without an = return status: 'UNVERIFIABLE' with the simplified form in developer_fields.simplified. The legacy is_valid boolean is preserved inside developer_fields.is_valid for backward compatibility.

Agent verification

New in v4.0.1
The TypeScript SDK supports the QWED Agent API for registering AI agents and verifying their actions with per-tenant rate limiting and server-enforced security checks.

registerAgent(registration)

Register an agent and receive credentials for subsequent verification calls.

verifyAgent(agentId, agentToken, query, options)

Updated in v5.0.0
Verify an agent action. Security checks (exfiltration detection and MCP poisoning) are enforced server-side and cannot be disabled by the client.
Breaking change (v5.0.0): The checkExfiltration and checkMcpPoison options have been removed. Exfiltration detection always runs. MCP poison detection runs automatically when you provide a toolSchema.
Breaking change (v5.0.0): The context option with conversationId and stepNumber is now required. Requests without these fields are rejected with error code QWED-AGENT-CTX-001.

getAgentBudget(agentId, agentToken)

Check the remaining budget for a registered agent.

IRAC audit fields

All guard-related verification responses include IRAC-compliant audit fields for compliance reporting:

Risk codes

Security-related responses may include a risk field indicating the type of threat detected:

TypeScript types

VerificationType enum

VerificationStatus enum

VerificationStatus is the diagnostic status of a verification (DiagnosticResult.status).
AgentVerificationResponse.verification.status uses AgentVerificationStatus, which adds the math engine’s DISPROVEN, INCONCLUSIVE, and SYNTAX_ERROR.

Admission enum

Admission is the server’s decision at its enforcement boundary. It’s absent where the endpoint makes no decision.

Error handling