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

# Operator view

> The browser interface: what is waiting, what it would do, and the buttons that decide.

The gateway serves an operator interface at `/` on its own port. Sign in with an operator token.

```
http://127.0.0.1:9470/
```

It is served by the gateway itself — no separate process, no build step, no external assets. A governance console that needs its own deployment is one that is not running when you need it.

## What it shows

> [card] Pending operations
>
> Everything waiting for a human, with the statement as it will run, the agent's stated reason, the blast radius, hazards, and the deadline.

> [card] The diff panel
>
> What the change would do, per record, with the fidelity label always visible.

> [card] Connections
>
> Each connection's capability ladder — what is enforced here, and by whom.

> [card] Agents and leases
>
> Who can touch the database right now, their state, and the buttons that end it.

Updates arrive over a live event stream (server-sent events), so a change proposed by an agent appears without a refresh. A console that connects mid-session is sent everything already waiting, rather than showing an empty screen until the next event.

## Reading the diff panel

Every preview carries a fidelity label, and the panel never hides it:

| Label | Means |
| - | - |
| `exact` | The change was executed in a transaction and rolled back. This is what will happen |
| `estimated` | The engine could predict it but not run it |
| `static` | Derived from the statement's shape alone |
| *No preview* | Nobody could produce one, and the panel says why |

"No records change" and "no preview was possible" look completely different, deliberately. A reviewer who cannot tell a measured diff from a guess is being given false confidence.

> [!NOTE]
>
> **Previews are masked.** A preview reads the table directly, so its rows are masked and column-restricted exactly as an agent's results would be before a reviewer ever sees them. A review queue lives in browsers and outlives the operation; it must not become a way to read what the agent itself cannot.

## What you can do

| Action | Capability required |
| - | - |
| View pending, connections, agents, leases, audit | read |
| Approve or reject a change | review |
| Revoke a lease | review |
| Freeze or reinstate an agent | manage |
| Start a debug session | manage |
| Step, continue, or stop a session | review |

Revocation is deliberately a review capability rather than a manage one: severing an agent's access mid-incident is exactly what a reviewer is on call to do, and making them find someone else first is how it fails to happen in time.

Every decision is attributed. Approvals, rejections, freezes, and reinstatements all record who did it and why, and the agent's own response names the person who approved its change.

> [!WARNING]
>
> The operator view is served over the same listener as the API. On anything but loopback that means TLS — see [TLS and state](https://warden.buildlab.in/configure/tls-and-state.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.