Skip to main content
VerifiedX records a decision every time it preflights a protected boundary. In practice, decision logs are where you inspect:
  • what boundary was checked
  • what outcome VerifiedX returned
  • why it returned that outcome
  • how the workflow was expected to continue
This is useful both for production monitoring and for tightening an integration after the first rollout.

​
What a decision log entry contains

A decision log entry is centered on the protected boundary decision itself. Typical fields include:
  • The decision_id
  • The outcome, such as:
    • allow
    • allow_with_warning
    • replan_required
    • goal_fail_terminal
  • The protected class involved, such as:
    • memory_write
    • record_mutation
    • system_change
    • external_message_send
  • The primary reasons for the decision
  • Safe next steps
  • Viewer guidance
  • What would change the decision
  • The exact machine-readable decision_receipt
In the builder app, decision entries are shown with outcome, receipt mode, action class, created time, primary reason, and the full decision receipt.

​
What to look for first

When you open a decision log, the fastest way to understand it is usually:
  1. Check the outcome.
  2. Check the action class.
  3. Read the reasons.
  4. Read the safe next steps.
  5. Inspect the decision_receipt.
That tells you whether the workflow should have:
  • continued downstream
  • replanned locally
  • routed upstream
  • paused for review
  • or stopped

​
Why logs are useful

Decision logs help answer questions like:
  • Which protected boundaries are actually firing in production?
  • Are agents being blocked for the reasons we expect?
  • Are we seeing local replans or upstream replans?
  • Which actions are high-friction and need better grounding or better upstream support?
  • Are we incorrectly treating a retrieval, helper, or tool as the wrong kind of boundary?
They are especially useful right after the first integration, because they show the real runtime behavior instead of what the prompts or code were supposed to do.

​
What the builder app surfaces

The builder app has a decision logs view for browsing recent decisions. From the current app surface, log entries expose:
  • outcome
  • receipt mode
  • action_class
  • created_at
  • primary reason
  • full decision_receipt
  • viewer_guidance
  • what_would_change_this
  • safe_next_steps
That makes the decision log the main place to inspect how VerifiedX wants the workflow to recover.

​
What logs tell you about recovery

Decision logs are especially important for replans. If a boundary returns replan_required, the receipt will tell you whether the system should:
  • recover locally on the same node
  • route the receipt upstream
  • or pause for human review
That is usually more useful than just knowing something was “blocked,” because VerifiedX is optimized to keep the workflow moving safely toward the same goal state.

​
Local debug diagnostics

If you need lower-level runtime diagnostics during development, both SDKs can also write a local JSONL debug file when debug logging is enabled. That file is separate from the builder app decision logs and can include records such as:
  • verifiedx_boundary_request
  • verifiedx_boundary_diagnostic
  • verifiedx_ingress_diagnostic
  • verifiedx_runtime_loopback
This is mainly for debugging integration behavior, request shape, and runtime loopback handling.

​
Practical usage

Use decision logs to:
  • Review unexpected replan_required outcomes
  • Confirm that high-impact actions are being classified correctly
  • Inspect whether a blocked step should have recovered locally or upstream
  • Validate that your protected boundaries are the right ones
  • Spot workflows that need stronger grounding, better retrieval support, or cleaner upstream approvals
After the first integration, read a handful of real decision logs before changing prompts or tool definitions. The logs usually show whether the problem is weak grounding, missing support, the wrong boundary shape, or a workflow that should recover upstream instead of locally.