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 decision receipt is the structured result VerifiedX returns for every protected boundary check. It is not just a yes or no. It tells your system:
  • what outcome VerifiedX reached
  • whether the side effect is safe to execute
  • how the workflow should continue
  • where recovery should happen
  • what would need to change before retrying
Receipts are designed so your agent or orchestrator can keep working toward the same goal state safely instead of guessing what to do next.

​
What a receipt contains

Every receipt includes the decision in a machine-readable form. In practice, a receipt gives your system:
  • a stable identifier for the decision
  • the outcome of the check
  • whether the requested side effect is safe to execute now
  • structured reasons explaining the decision
  • safe next steps the workflow can take
  • guidance on where the workflow should continue
  • retry or resume guidance when the boundary should be attempted again
  • optional metadata from the runtime or adapter

​
Decision outcomes

VerifiedX uses the same core outcome model across runtimes and adapters:
OutcomeWhat it means
allowThe boundary can execute normally
allow_with_warningThe boundary can execute, but the receipt still carries warnings and guidance
replan_requiredThe requested boundary must not execute as requested; the workflow should continue through a safer or better-grounded path
goal_fail_terminalThe requested boundary path is terminally blocked for the current goal state

​
Disposition modes

The most important part of the receipt is usually the disposition.
ModeWhat it means
continue_downstreamThe boundary is allowed and the workflow can continue normally
local_replanThe current node should keep working locally toward the same goal without executing the denied effect
upstream_replanThe current node should stop local work and return the receipt upstream so missing support or approvals can be gathered
human_reviewThe workflow should pause for human review
terminal_blockThe current path is terminally blocked

​
Example receipt

This is a representative replan_required receipt for a workflow that needs safer recovery instead of immediate execution: 
{
  "decision_id": "dec_example_1",
  "outcome": "replan_required",
  "safe_to_execute": false,
  "reasons": [
    {
      "code": "missing_required_support",
      "message": "The requested action is missing required support."
    }
  ],
  "safe_next_steps": [
    {
      "code": "GATHER_MISSING_SUPPORT",
      "message": "Gather the missing approval, evidence, or corroboration before retrying."
    }
  ],
  "disposition": {
    "mode": "upstream_replan"
  }
}

​
How to use receipts

Receipts are synchronous outputs of the protected-boundary flow. Your system should branch on the receipt, not guess from prose. Typical handling looks like this:
  • continue_downstream
    • The boundary is allowed.
    • The side effect may execute.
    • The workflow can continue normally.
  • local_replan
    • Do not execute the denied side effect.
    • Keep the receipt local.
    • Replan inside the same node or agent using the reasons and safe next steps in the receipt.
  • upstream_replan
    • Do not keep pushing locally.
    • Return the receipt upstream.
    • Let the parent orchestrator or supervisor gather the missing evidence, approval, or context before retrying this node.
  • human_review
    • Surface the receipt to a reviewer.
    • Use the receipt to guide the review step and the eventual retry path.
  • terminal_block
    • Do not claim success.
    • Fail truthfully.
    • Hand off to a human or upstream workflow if appropriate.

​
Receipts and blocked results

When a protected boundary is blocked at runtime, VerifiedX usually returns a runtime-friendly blocked result as well as the receipt. The receipt is the routing and recovery contract. The blocked result is the immediate payload your agent or workflow can act on right away.

​
Key idea

A receipt is not just an audit artifact. It is the machine-readable contract that lets your system continue safely:
  • downstream when execution is allowed
  • locally when replanning should stay on the current node
  • upstream when the blocker must be resolved by a parent stage
  • truthfully when the workflow has to pause or stop