> ## 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.

# Preflight

> How VerifiedX checks a protected boundary before it executes.

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

<Note>
  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.
</Note>

## 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

## 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](/concepts/decision-receipts).

## 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