Skip to main content

Blocked and fail-closed outcomes

The concrete shapes for the three non-success outcomes.

Blocked before execution (request-side)​

  • Status: 403 Forbidden
  • Body:
{
  "error": {
    "message": "Request rejected by request-side guardrails.",
    "type": "guardrail_error",
    "param": null,
    "code": "sensitivity_classification"
  }
}

The model was not called. No tokens consumed.

Blocked after execution (response-side)​

  • Status: 403 Forbidden
  • Body:
{
  "error": {
    "message": "Response rejected by response-side guardrails.",
    "type": "guardrail_error",
    "param": null,
    "code": "unsafe_content_output"
  }
}

The model was called. Token accounting on blocked responses is under review — contact your Advania Solutions Architect for the current behaviour.

Guardrails unavailable (fail-closed)​

  • Status: 503 Service Unavailable
  • Body:
{
  "error": {
    "message": "Guardrails are temporarily unavailable.",
    "type": "server_error",
    "param": null,
    "code": "guardrail_unavailable"
  }
}

The model was not called. Retry with backoff.

Client decision table​

You seeRetry?
403 guardrail_error (request-side)No
403 guardrail_error (response-side)No
503 guardrail_unavailableYes, exponential backoff

Guidance​

  • 403 guardrail_error is non-retryable — the same input will give the same outcome. Surface it to your end user with your own copy (don't display the platform's error.message verbatim); offer a rephrase or a different model if your app supports it.
  • 503 guardrail_unavailable is transient — retry with exponential backoff, cap total wait, then surface the failure. If the same fault persists over a longer window, hand x-decision-id to Advania.
  • Log x-request-id, x-decision-id, x-policy-version, and error.code on every non-200 response.