Skip to main content
Preflight is the core VerifiedX check. When a protected boundary is about to run, VerifiedX evaluates whether that exact side effect is justified by the current run context before it executes. In product terms, preflight usually applies to:
  • high-impact actions
  • durable memory writes
If you are using the Python or TypeScript SDKs, or any native adapter, you do not call preflight manually. VerifiedX runs it automatically at the right boundary.

​
What gets preflighted

Preflight is not just for methods named actions. Depending on the integration, VerifiedX can preflight:
  • Protected actions
    • record mutations
    • system changes
    • external messages
    • webhook-like effects
  • Durable memory writes
    • memory or long-lived state that should only change when justified
In runtime terms, those protected boundaries are typically:
  • action_execute
  • memory_write

​
What preflight considers

Preflight evaluates the pending side effect in context. That can include:
  • what the agent is about to do
  • what the agent has already done in this run
  • the evidence the agent gathered before the action
  • upstream context when the run is part of a multi-agent or agent+human system
This is why the same action can be allowed in one run and require replanning in another.

​
What the SDK does automatically

When a protected boundary is reached, the SDK or native adapter automatically:
  1. builds the current decision context
  2. runs the preflight check
  3. receives the decision and decision receipt
  4. either lets the side effect proceed or returns a structured blocked loopback result
If the boundary is allowed, VerifiedX can also observe whether the effect actually happened after execution.

​
Possible outcomes

A preflight check returns one of these outcomes:
  • allow
  • allow_with_warning
  • replan_required
  • goal_fail_terminal
Every outcome includes a structured Decision Receipt.

​
What happens after preflight

​
If allowed

If the outcome is allow or allow_with_warning:
  • the side effect may execute
  • the workflow can continue
  • VerifiedX can report the observed execution afterward

​
If replanning is required

If the outcome is replan_required:
  • the requested side effect does not execute
  • the workflow gets a structured blocked result and decision receipt
  • the system should keep moving toward the same goal through a safer or better-grounded next step
That replan can stay:
  • local to the current node or agent
  • upstream to a parent orchestrator when the missing support has to be gathered there

​
If terminally blocked

If the outcome is goal_fail_terminal:
  • the requested path must not execute
  • the workflow should fail truthfully or hand off cleanly to a human or upstream system

​
Why this matters

Preflight is not only about stopping obviously malicious behavior. It also catches cases where the agent is:
  • weakly grounded
  • acting on stale or partial context
  • retrying the wrong side effect
  • trying to mutate state without enough trustworthy support
The goal is to stop the wrong side effect while keeping the system moving safely toward the same goal state whenever that is still possible.

​
Direct API usage

Advanced custom integrations can use the VerifiedX API directly, but most builders should use an SDK or native adapter instead. The SDK path is the recommended path because it already handles:
  • context accumulation
  • protected-boundary checks
  • decision receipts
  • execution reporting
  • runtime loopbacks