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

# Handle gate outcomes

> Map every gate status to a safe dispatch action.

Policy outcomes normally return HTTP `200`. Treat the response body status as a
state machine, not as an HTTP success signal.

| Status        | Required action                                                 |
| ------------- | --------------------------------------------------------------- |
| `BLOCKED`     | Stop permanently. Record the violations.                        |
| `QUEUED`      | Hold. Send the reviewer to `review_url` or poll by `action_id`. |
| `DISPATCHING` | Hold. Delivery is in progress; poll without duplicating work.   |
| `APPROVED`    | Continue only when your workflow owns the final dispatch.       |
| `SENT`        | DataVibe dispatch completed; do not send again.                 |
| `REJECTED`    | Stop. A reviewer rejected the submission.                       |
| `FAILED`      | Stop and inspect failure metadata before a safe retry.          |

<Warning>
  Only `APPROVED` or `SENT` represents a successful release. A `QUEUED` response
  is not permission to enqueue the message in a sequencer.
</Warning>

## Policy violations

Each violation identifies the rule, severity, matched content, reasoning, and
mitigation. `BLOCK` is a hard stop. `WARN` may route to human review depending
on workspace configuration.

## Infrastructure failures

Authentication, validation, quota, rate-limit, and snapshot failures use non-2xx
responses. Follow `Retry-After`, `next_step`, `reset_at`, and `X-Usage-*`
metadata when present. See [Errors](/api-reference/errors).