Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.verifiedx.me/llms.txt

Use this file to discover all available pages before exploring further.

Start with the Free Sandbox to protect one risky node, see real decision logs, and only then widen the rollout.
Start with the highest-level surface your repo already uses. Only fall back to raw Python or raw TypeScript if no native adapter already owns the tool loop, graph, or runtime.Run doctor first:
  • TypeScript / OpenAI / OpenAI Agents SDK / Anthropic / Claude / Claude Agent SDK / Vercel AI SDK / MCP (TypeScript): npx @verifiedx-core/sdk doctor
  • Python / LangGraph / MCP (Python): verifiedx doctor
Protect one action free: verifiedx.me

​
Pick your stack first

Most common starting points: Other supported surfaces:
1

Install

Add the VerifiedX package for your runtime.
pip install verifiedx
This page shows the raw runtime path because it is the fastest universal install. If your app already uses OpenAI direct, OpenAI Agents SDK, Anthropic direct, Claude Agent SDK, LangGraph, LangChain, Vercel AI SDK, or MCP, prefer the native adapter page for that stack.
2

Set environment variables

For the hosted service, VERIFIEDX_API_KEY is the only required variable.
.env
VERIFIEDX_API_KEY=vxpk_your_runtime_key

# Optional
VERIFIEDX_BASE_URL=https://api.verifiedx.me
VERIFIEDX_ORG_ID=your_org_id
VERIFIEDX_PROJECT_ID=your_project_id
VERIFIEDX_ENVIRONMENT=prod
VERIFIEDX_BASE_URL already defaults to https://api.verifiedx.me. Org, project, and environment also have SDK defaults, so they are optional for a first install.
3

Bind your node

Bind the methods VerifiedX should observe and preflight. For the raw runtime, that usually means your LLM call, retrieval method, and the first risky action or durable memory write you want to protect.
from verifiedx import init_verifiedx

class WorkflowNode:
    def call_model(self, messages):
        ...

    def lookup_internal_workflow(self, workflow_id):
        ...

    def set_workflow_status(self, workflow_id, status):
        ...

vx = init_verifiedx()
node = WorkflowNode()

vx.install_runtime(
    node,
    llm={"call_model": {"model_name": "gpt-5.4-mini"}},
    retrievals={"lookup_internal_workflow": {"query": "internal workflow evidence"}},
    actions={"set_workflow_status": {"tool_name": "set_workflow_status"}},
)
If the first risky node you want to protect is a durable memory write instead of an action, bind it under memories instead of actions.
If the node you are protecting is part of a larger multi-agent or agent+human workflow, pass upstream context into VerifiedX so that node has better system and situational awareness before it takes a high-impact action. VerifiedX does not require a fixed schema for this. Pass the upstream context you already have in any JSON-serializable shape.
4

Run your agent and check your logs

Run your agent as normal. VerifiedX observes the run, preflights the protected side effect before it lands, and records a decision receipt you can inspect.Open the VerifiedX dashboard to inspect your decision logs. Each protected action check includes:
  • The action that was intercepted
  • The preflight outcome: allow, allow_with_warning, replan_required, or goal_fail_terminal
  • Structured reasons explaining the decision
  • A machine-readable decision receipt with routing and resume semantics
If a replan happens, the side effect does not execute. The agent gets loopback guidance and can keep working toward the same goal through a safer next step.

​
Tell your coding agent

Use this prompt to have a coding agent integrate VerifiedX into an existing codebase for you.

Agent integration prompt

You are integrating VerifiedX into an existing codebase.

Goal
Install VerifiedX with the smallest truthful integration. Keep the existing runtime, tools, prompts, orchestration, graph, business logic, and deployment shape. Use VERIFIEDX_API_KEY from env. Prefer the native VerifiedX adapter that exactly matches the runtime or framework already used by this codebase.

Before editing, you may run read-only commands to orient yourself:
- Python: `verifiedx doctor`
- TypeScript: `npx @verifiedx-core/sdk doctor`
- Optional repo scan: `npx -y @verifiedx-core/sdk@latest verify --json --cwd .`

Use these only for reconnaissance. They do not replace reading the code.

First step
Read the codebase and identify which VerifiedX integration surface matches it. Before editing, open the matching docs page:

- Python raw: https://docs.verifiedx.me/sdks/python
- TypeScript raw: https://docs.verifiedx.me/sdks/typescript
- OpenAI Agents SDK: https://docs.verifiedx.me/sdks/openai-agents-sdk
- Claude Agent SDK: https://docs.verifiedx.me/sdks/claude-agent-sdk
- Vercel AI SDK: https://docs.verifiedx.me/sdks/vercel-ai
- LangGraph: https://docs.verifiedx.me/sdks/langgraph
- OpenAI direct: https://docs.verifiedx.me/sdks/openai
- Anthropic direct: https://docs.verifiedx.me/sdks/anthropic
- LangGraph (OpenAI): https://docs.verifiedx.me/sdks/langgraph-openai
- LangGraph (Anthropic): https://docs.verifiedx.me/sdks/langgraph-anthropic
- MCP (Python): https://docs.verifiedx.me/sdks/mcp-python
- MCP (TypeScript): https://docs.verifiedx.me/sdks/mcp-typescript

Concept references
If you need the runtime model or blocked-result semantics while integrating, use these:

- How it works: https://docs.verifiedx.me/concepts/how-it-works
- Protected actions: https://docs.verifiedx.me/concepts/protected-actions
- Decision receipts: https://docs.verifiedx.me/concepts/decision-receipts

Use concept pages to understand what VerifiedX does. Do not use concept pages to invent API names. Use the matching SDK page for exact installation and code.

Selection rules
- Use the highest-level native adapter already owning the tool loop, graph, runtime, or MCP boundary.
- If the codebase uses LangGraph, use the LangGraph adapter, not direct OpenAI or Anthropic.
- If the codebase uses OpenAI Agents SDK, use the OpenAI Agents SDK adapter, not OpenAI direct.
- If the codebase uses Claude Agent SDK, use the Claude Agent SDK adapter, not Anthropic direct.
- If the codebase uses Vercel AI SDK, use the Vercel AI SDK adapter.
- If the codebase exposes standalone MCP tool handlers, use MCP Python or MCP TypeScript.
- Only use raw Python or raw TypeScript if no supported native adapter owns the loop.

Context
Start with one risky boundary only: a real action or durable memory write that can change business state, send a message, update a record, issue a refund, modify a subscription, change workflow status, write memory, run code, or affect an external system.

VerifiedX checks the pending action using what the agent is about to do, what it already did in the run, compact evidence from prior tool calls, and upstream context when the node is part of a multi-agent or agent+human workflow.

Composed systems
If the protected node is part of a composed system, pass upstream context already available in the codebase into VerifiedX. Do not invent a new schema. Upstream context may include parent workflow state, supervisor instruction, human approval, prior agent summary, task owner, workflow id, or routing context.

In Python, use `with_upstream_context(...)` or `set_upstream_context(...)` only when the matching SDK page supports it.
In TypeScript, use `withUpstreamContext(...)` or `setUpstreamContext(...)` only when the matching SDK page supports it.

Success criteria
- VerifiedX is installed through the exact supported surface already used by this codebase.
- The runtime key is loaded from env, not hardcoded.
- Existing app behavior stays the same except for VerifiedX action protection, blocked-result behavior, loopback, and decision receipts.
- One real risky boundary is protected first.
- A justified action still executes.
- An unjustified action does not execute and returns a decision receipt/replan/terminal result as the docs describe.

Implementation rules
- Read the existing code first, then edit.
- Apply the change in the real codebase. Do not stop at prose or TODO comments.
- Use exact VerifiedX API names from the matching SDK page.
- Do not add custom policy code.
- Do not redesign the workflow.
- Do not add fake fallback lanes.
- Do not rename the builder’s tools just to help VerifiedX.
- Do not send giant prompt/history dumps into VerifiedX.
- Do not protect read-only lookups as actions. Lookups are evidence/support input; high-impact side effects are the boundary.
- Do not invent old semantic config such as `userInstructions`, `pendingAction`, or `pendingMemoryWrite`.

When complete, report:
- detected integration surface,
- docs page used,
- files changed,
- first protected action or memory write,
- whether the system is single-agent or composed,
- how upstream context is passed, if applicable,
- validation run and result.