> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ironbee.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Verifications

> Browser, Node, and backend verification cycles how the agent tests its changes before completing.

A **verification** is a complete testing cycle the agent runs to prove that its code changes work. Before any task can complete, every affected code path must be exercised with real tools.

Verifications are accessed through the [Session Timeline](/console/session-timeline) and they appear as labeled intervals (Verification 1, Verification 2, …) nested inside activity bars. Click a verification interval to open the [Verification Detail](/console/verification-detail) panel.

***

## Verification types

IronBee supports three cycle types that can run in parallel:

### Browser cycle

The agent uses browser devtools to verify frontend and full-stack changes:

* Navigates to affected pages
* Takes screenshots at key states
* Checks the browser console for errors
* Tests user interactions (clicks, forms, navigation)
* Records a browser session video
* Submits a verdict with evidence

The browser cycle is active by default for most code file types. Disable it with `ironbee browser disable`.

### Node cycle

The agent connects to a running Node.js process to verify backend changes via V8 inspector:

* Connects to the Node inspector
* Sets tracepoints or logpoints at changed code paths
* Exercises those paths via API calls or UI interactions
* Reads back execution snapshots or runtime logs
* Submits verdict with backend evidence

The Node cycle is opt-in and enable it with [`ironbee node enable`](/cli/guides/verification#enable-or-disable-a-platform).

### Backend cycle

The agent drives real HTTP, gRPC, GraphQL, or WebSocket requests against a running backend service and verifies the responses. Works for any backend runtime (Node, Java, Python, Go, Rust, and more). Evidence is collected across three domains:

| Domain             | Tools                                                       | What is captured                                         |
| ------------------ | ----------------------------------------------------------- | -------------------------------------------------------- |
| Protocol calls     | `bedt_http_*`, `bedt_grpc_*`, `bedt_graphql_*`, `bedt_ws_*` | Request/response pairs, status codes, payloads           |
| Observability logs | `bedt_log_*`                                                | Runtime log lines emitted by the service during the call |
| Database queries   | `bedt_db_*`                                                 | SQL or NoSQL queries executed as a side effect           |

The backend cycle is opt-in and enable it with [`ironbee backend enable`](/cli/guides/verification#enable-or-disable-a-platform).

***

## Verification status

| Status        | Meaning                                        |
| ------------- | ---------------------------------------------- |
| `in-progress` | The agent is actively running this cycle       |
| `pass`        | All evidence checks passed                     |
| `fail`        | One or more checks failed                      |
| `abandoned`   | The cycle ended before a verdict was submitted |

***

## Retry behavior

If a verification fails, the agent must fix the issues and re-verify. By default, it gets 3 attempts (`maxRetries`). After the limit is reached, the session can complete but must report unresolved issues.

Each retry creates a new verification cycle, you can see the full history in the timeline.