Skip to main content
Decision logs let you inspect how VerifiedX is behaving on real protected boundaries. Use them to understand:
  • which boundaries are firing
  • what outcomes VerifiedX is returning
  • why a workflow continued, replanned, or stopped
  • what would need to change before a blocked step should be retried

​
Where to view logs

Decision logs are available in the builder app at api.verifiedx.me. They are grouped around real protected-boundary decisions, not just raw event streams.

​
What you see in the logs view

In the main logs list, VerifiedX surfaces summary fields such as:
  • outcome
  • receipt mode
  • action class
  • created time
  • primary reason
When you open a decision, the detail view includes:
  • the full decision_receipt
  • safe_next_steps
  • viewer_guidance
  • what_would_change_this
That gives you both the high-level result and the exact recovery contract for the workflow.

​
Log retention

PlanRetention
Free Sandbox7 days
Startup30 days
EnterpriseCustom

​
What to look for first

When reviewing a log entry, the fastest path is usually:
  1. Check the outcome.
  2. Check the receipt mode.
  3. Read the primary reason.
  4. Inspect safe_next_steps.
  5. Open the full decision_receipt if you need the exact routing and resume semantics.

​
Practical use

Logs are most useful for questions like:
  • Are we protecting the right boundaries?
  • Are agents hitting replan_required for the reasons we expect?
  • Is recovery staying local or routing upstream?
  • Which actions need better grounding, retrieval support, or cleaner approvals?
  • Are we seeing the same blocked action retried without meaningful new support?

​
Key idea

Decision logs are not just for auditing. They are how you understand how VerifiedX expects the workflow to continue:
  • downstream when execution is allowed
  • locally when the current node should replan
  • upstream when a parent stage needs to gather missing support
  • truthfully when a path has to stop
After your first integration, read a handful of real decision logs before changing prompts or tool definitions. The logs usually show whether the issue is weak grounding, missing support, or a workflow that should recover upstream instead of locally.