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

# Logs

> Access and use your VerifiedX decision logs.

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](https://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

| Plan         | Retention |
| ------------ | --------- |
| Free Sandbox | 7 days    |
| Startup      | 30 days   |
| Enterprise   | Custom    |

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

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