What VerifiedX attaches to
VerifiedX can see and protect work through more than one surface:| Surface | What it means |
|---|---|
| Prompt and ingress context | Conversation windows, user turns, system prompts, and selected external or retrieved content |
| Support inputs | Retrievals, memory reads, tool history, selected tool calls, and other contextual evidence gathered during the run |
| Protected boundaries | High-impact memory_write and action_execute boundaries |
| Native adapters | Framework-native tool loops such as OpenAI, Anthropic, Claude Agent SDK, OpenAI Agents SDK, LangGraph, Vercel AI SDK, LangChain, and MCP |
| Raw runtimes | Explicitly bound harness methods like llm, retrievals, actions, memories, and tools |
| Lower-seam fallbacks | Runtime-level file, fetch, database, queue, browser, and similar side effects when supported by the SDK |
Visibility does not come only from explicitly declared
actions. It can come from bound harness methods, native adapter hooks, or installed lower-seam runtime fallbacks, depending on the integration path you use.The execution flow
Context is observed continuously
VerifiedX records conversation anchors, support inputs, tool history, retrieval history, memory reads, and taint signals from user-controlled or externally retrieved context as the run unfolds.
A protected boundary is identified
When a high-impact step is about to happen, VerifiedX constructs an observed boundary. In practice that is usually either a
memory_write or an action_execute boundary.The pending effect is normalized
VerifiedX turns the pending step into a structured effect description. For actions, that often resolves to classes such as
record_mutation, system_change, external_message_send, webhook_call, browser_submit, or upload. Durable memory writes use memory_write.Boundary preflight is sent
VerifiedX sends the observed boundary plus the accumulated decision context to the VerifiedX API for evaluation.
A decision receipt comes back
VerifiedX receives a decision with an outcome, reasons, safe next steps, and a structured decision receipt describing how the run should continue.
When a native adapter already surfaces the selected tool before execution, VerifiedX can preflight at selection time and reuse that decision at execution time instead of double-preflighting the same boundary.
Decision outcomes
VerifiedX boundary decisions use the same core outcome model across runtimes and adapters:| Outcome | What it means |
|---|---|
allow | The boundary can execute normally |
allow_with_warning | The boundary can execute, but the decision still carries warnings and safe-next-step guidance |
replan_required | The requested boundary must not execute as-is; the run should continue through a safer or better-grounded path |
goal_fail_terminal | The requested boundary path is terminally blocked for the current goal state |
decision_receipt. That receipt includes:
dispositionroutingresume_contractsafe_next_stepswhat_would_change_thisruntime_loopback
Base and composed loopbacks
VerifiedX supports both local and upstream replanning.Base or local loopback
In a direct runtime or single-node flow, a denied boundary usually becomes a local loopback:- the side effect does not execute
- the tool returns
ok: false - the result carries
blocked: true,boundary_outcome,safe_next_steps, anddecision_receipt - the same node or agent can keep working toward the same goal through a safer path
local_replan path.
Composed upstream loopback
In a composed system with upstream context, the samereplan_required outcome can become an upstream_replan:
- the local node stops work
- it does not keep making local downstream calls
- it returns the
decision_receiptupstream - the parent orchestrator or supervisor gathers the missing evidence, approvals, or context
- the blocked node is retried later with new upstream context
Execution confirmation matters
A successful preflight is not the same thing as a successful side effect. After an allowed boundary runs, VerifiedX reports the observed execution. If the tool throws, or returns a result that does not confirm the effect actually happened, VerifiedX keeps the runtime loopback active rather than silently treating the step as complete. In practice, results like these do not count as confirmed success:ok: falseblocked: trueside_effect_executed: falsemust_not_claim_success: true- failed or not-executed step status
What VerifiedX does not do
- It does not replace your orchestrator, framework, or tool loop.
- It does not own your memory store, database, queue, or message bus.
- It does not require you to flatten your system into one special “action node.”
- It does not treat a preflight allow as proof that the mutation actually happened.
- It does not magically observe every part of your program with no install surface at all. Visibility still comes from your chosen adapter, bound harness methods, or lower-seam runtime fallbacks.