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.

A protected action check is the billable name for a real high-impact boundary check. VerifiedX runs that check before the side effect executes, returns a decision receipt, and then helps the system either execute safely, recover locally, or replan upstream without losing the goal state. Context from user-controlled inputs, external retrieval-like inputs, event ingest, execution reports, and decision reads are all included in that check.

​
What counts as a protected action

In product terms, protected actions include durable memory writes and other high-impact side effects. Common examples:
  • Durable memory writes such as saving agent memory, long-lived state, or knowledge-store entries
  • Record updates such as CRM changes, ticket changes, ledger writes, or workflow-state changes
  • Outbound messaging such as email, Slack, SMS, notifications, and similar message sends
  • External callbacks and submissions such as webhooks, browser submissions, queue publishes, and uploads
  • Internal system changes such as file writes, config changes, and other internal mutations

​
What does not count as a protected action

These do not usually create a billable protected action check on their own:
  • LLM calls
  • Retrievals and read-like lookups
  • Memory reads
  • Other support inputs that help build decision context but do not themselves create a protected side effect
They still matter. They help VerifiedX evaluate the next high-impact boundary with better context.

​
How protected actions are discovered

VerifiedX can discover protected actions through more than one surface:
  • Raw runtimes
    • You explicitly bind actions and memories
  • Native adapters
    • VerifiedX uses your existing tool names, descriptions, schemas, approval hints, and framework-native execution surfaces
  • Supported lower-level surfaces
    • When supported by the integration, VerifiedX can also protect lower-level side effects without requiring you to redesign your system
A write is not only protectable when you explicitly declare it under actions. Native adapters and supported lower-level surfaces can also expose real protected boundaries.

​
Declaring protected actions in the raw runtimes

If you are using the raw Python or TypeScript runtime, declare durable memory writes under memories and other high-impact effects under actions. 
from verifiedx import init_verifiedx

vx = init_verifiedx()

vx.install_runtime(
    node,
    memories={
        "write_memory": {"tool_name": "write_memory"},
    },
    actions={
        "send_email": {"tool_name": "send_email"},
        "set_workflow_status": {"tool_name": "set_workflow_status"},
    },
)
The method name is the method on your harness or node. The tool_name or toolName is the stable boundary name that appears in decision logs and receipts.

​
Native adapters

On native adapter surfaces, you usually do not declare separate actions and memories dictionaries. Instead, your existing native tool definitions are the source of truth. VerifiedX uses the tool name, schema, description, approval hints, and adapter-specific runtime signals to determine whether a tool should be treated as:
  • a protected action
  • a durable memory write
  • or only a support input
That is why native integrations can stay few-LOC while still protecting high-impact tools.

​
What happens during and after a protected action check

1

A high-impact step is about to run

VerifiedX sees that the agent is about to take a durable memory write or another high-impact action.
2

Decision context is assembled

VerifiedX evaluates the pending step using the surrounding run context, including what the agent has already done, what it has gathered, and any relevant upstream context.
3

The check runs

VerifiedX evaluates whether the pending action is justified before execution.
4

A decision receipt comes back

The result can be allow, allow_with_warning, replan_required, or goal_fail_terminal, along with reasons, safe next steps, and structured receipt data.
5

The system either executes, replans locally, or routes upstream

If allowed, the side effect may execute. If the boundary is blocked or needs replanning, the side effect does not execute and the workflow gets a structured recovery path instead.

​
Replan is the default recovery shape

VerifiedX is optimized to stop the wrong action, not stop the agent. If the current side effect is wrong but the goal is still valid, the usual outcome is replan_required. That means:
  • the requested side effect does not execute
  • the system gets a structured decision receipt
  • the workflow gets reasons and safer next steps
  • the run should continue toward the same goal state through a safer or better-grounded path

​
Local and upstream replan

VerifiedX supports both local and upstream recovery.

​
Local replan

In a direct or single-node flow, a denied protected action usually becomes a local replan first. That means:
  • the side effect stays unapplied
  • the current agent or node gets the blocked result
  • the same node can continue with a safer next step

​
Upstream replan

In a composed workflow, the same replan_required outcome can route upstream when the missing support, approvals, or corroboration has to come from a parent stage. That means:
  • the local node stops trying to complete this stage on its own
  • it returns the decision receipt upstream
  • the orchestrator or parent node gathers what is missing
  • the blocked node is retried later with better upstream context
This is how VerifiedX helps complex systems keep working toward the same goal state without pretending the blocked step succeeded.

​
A successful check is not the end of the story

A protected action check covers the preflight. After an allowed boundary runs, VerifiedX can also observe and report whether the side effect actually happened. If the action throws, fails, or does not confirm execution, VerifiedX keeps the workflow honest instead of silently counting that step as complete. That is why execution reports and runtime loopbacks are included in the same protected action check.

​
Pricing

Each protected action check counts as one billable unit. The following are included at no additional cost per check:
  • Context from user-controlled and retrieval-like inputs
  • Event ingest
  • Execution reports
  • Decision reads from your decision log
Start by protecting the boundary most likely to cause irreversible damage if the agent is hijacked, misgrounded, or hallucinating.