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

# HITL Gates

> When sureops pauses to ask for your approval, what those requests look like, and how to configure timeout behavior.

HITL (Human-in-the-Loop) gates are the specific moments when sureops stops and waits for a human decision before proceeding. Every approval gate creates a durable record: who approved what, when, and from which stage.

## When does sureops pause?

sureops pauses for approval at the following trigger points:

### Post-diagnosis: recommendation approval

After the Diagnosis Specialist produces root cause analysis and proposes remediation actions, the agent always pauses before any fix is attempted. This is the primary gate in the incident pipeline.

The approval request includes:

* The proposed root cause(s) with confidence scores
* Each recommended action with its risk classification
* The executor for each action (runtime execution vs. fix PR vs. human)
* Supporting evidence (metric data, log excerpts, trace analysis)

### P1 / P2 severity incidents

Critical and high-severity incidents have additional approval requirements, even in Self-Driving mode. The agent cannot auto-execute anything for a P1 or P2 incident regardless of your `autonomous_execution` settings.

### High-risk or destructive actions

Any recommendation classified as high risk always gates, regardless of severity or mode. This includes:

* Rollbacks that affect production traffic
* Scaling operations above a defined threshold
* Configuration changes to security-sensitive surfaces
* Any action the diagnosis agent marks as potentially irreversible

### Before sending wide-audience incident communications

When the Resolution Specialist proposes an external communication — such as a war-room message, a customer notification, or a status page update — sureops gates before sending. You approve the content and target audience.

### Before closing an incident

When the Verification Agent confirms recovery and the commander proposes closure, there is an optional gate (configurable per org) that requires a human to sign off before the incident is marked resolved.

***

## What an approval request looks like

### In-app

Pending approvals appear in two places:

1. **Command Center → Pending Approvals panel** — a list of all open approval requests across all active incidents.
2. **Incident detail page → Recommendations section** — inline approve/reject controls with full context.

Each approval card shows:

* The incident name and severity
* The stage the request originated from
* Proposed actions with risk labels
* The AI's reasoning summary
* A confidence score

### Slack notification

If you have Slack connected, sureops posts an approval request to your configured incident notification channel. The message includes:

* Incident name and link
* The proposed action summary
* Approve and Reject buttons (requires the sureops Slack app)

### Email

If no Slack approval is received within the notification window, sureops sends an email notification to members with Commander, Admin, or Owner roles.

***

## Who can approve?

Approvals require the **`approvals:grant`** capability, which is granted to:

* Commander
* Admin
* Owner

Responders and Observers cannot approve HITL gates. See [Roles & Permissions](/next/administration/roles-and-permissions) for the full capability matrix.

***

## Timeout behavior

Approval gates have a configurable timeout. When a gate goes unanswered, sureops acts according to the `hitl_timeout_action` setting for your environment.

| Setting              | Behavior on timeout                                                                                                                                                                                           |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `escalate` (default) | The incident is handed to a human. The approval is not silently auto-approved. Sends a notification via Slack, email, or both.                                                                                |
| `extend`             | Resets the timer once and sends another notification. On the second timeout, falls back to `escalate`.                                                                                                        |
| `auto_decide`        | Only applies when the incident is in Self-Driving mode and the proposed action is below the high-risk threshold. Never applies to P1/P2 incidents or destructive actions. Falls back to `escalate` otherwise. |

<Warning>
  The `escalate` default means an unanswered approval never silently proceeds. The incident enters a waiting-for-human state, visible on the Command Center dashboard and via Slack and email notifications.
</Warning>

To configure, go to **Settings → Environment → \[environment] → AI Behavior → Approval timeout**.

***

## HITL gates by mode

Both Self-Driving and Supervised modes have gates, but the set differs.

### Self-Driving mode

Gates fire at the specific triggers listed above: post-diagnosis recommendation approval, high-risk actions, P1/P2 severity, wide communications, and closure (if enabled).

Auto-approve settings can reduce the number of gates for lower-risk actions on P3/P4 incidents. See [Supervised vs Self-Driving](/next/operating-modes/supervised-vs-self-driving) for configuration details.

### Supervised mode

In Supervised mode, every stage transition is a gate — the agent presents its findings and waits for you to approve the next step. The same action-specific gates (high-risk, P1/P2, communications, closure) also apply on top of the stage-transition gates.

This means Supervised mode has more gates than Self-Driving mode, giving you more decision points and a more complete audit trail.

***

## What happens if no one approves

When a gate times out and the action is `escalate`:

1. The incident moves to a **waiting for human** state
2. The graph is suspended — no further agent actions run
3. The pending approval remains visible on the dashboard
4. Any team member with Commander role or above can claim the incident and resume

To claim a system-escalated incident: open the incident, click **Take Control**. This adopts the suspended state — you become the controlling user, the auto-release timer starts, and you can act on the pending approval or navigate the incident manually.

After taking control and resolving the approval (approve or reject), release control to let the AI resume, or continue in Supervised mode.

***

## Mixed approval batches

When the Diagnosis Specialist proposes multiple recommendations, you can approve some and reject others. A few rules apply:

* You cannot approve both an **execute-fix** recommendation and a **reinvestigate** recommendation in the same batch. These have opposite meanings (act vs. dig deeper), so the system forces you to choose one direction.
* Approving a `reinvestigate` recommendation sends the agent back to the Diagnosis stage with focus on what you flagged. The maximum number of re-investigation rounds is configurable (default: 2) to prevent infinite loops.
* Each approved recommendation's intent determines the routing: `execute_fix` proceeds to resolution; `reinvestigate` returns to diagnosis; `monitor` moves to a watch-and-wait closure; `escalate` suspends to human takeover.