Policy and Guardrail Limits#

This page describes important limitations and runtime considerations for policies and guardrails in OptScale AI.

Use it when troubleshooting why a policy did not run, why traffic bypassed evaluation, or why guardrail results are not yet visible.

Policy evaluation#

Guardrails require a policy — A saved guardrail has no effect until it is linked to an Enabled policy and the policy Conditions match the request.
Condition mismatch — If Conditions or Request type are too narrow, matching traffic may never enter evaluation.
Sampling skips traffic — A Sampling rate below 100% means some matching requests are not evaluated. Review Bypass rate on the policy detail page to confirm how often traffic is skipped.
Disabled policies — A Disabled policy retains its configuration but does not evaluate traffic. Guardrails linked only through that policy do not run.

Stage alignment — The policy Evaluation scope → Stage and each guardrail Stage must match the point where evaluation should occur: Input, Output, or Both. An Output guardrail does not inspect user prompts.
Evaluation timeout — When guardrail evaluation exceeds Timeout, the policy's Pass on timeout setting determines whether the request continues or fails.
Threshold tradeoffs — Lower thresholds may increase false positives, while higher thresholds may miss borderline cases. Sentiment uses a different score scale than most other guardrail types. See Guardrail thresholds.
Non-score guardrails — Some guardrails, such as Token limit, apply configured limits directly instead of using a confidence score.

Metrics require matching traffic — Total invocations, Violation rate, and policy Usage Statistics may show 0 or No data until matching traffic has been evaluated.
Recent configuration changes may not appear immediately — Allow time for new matching traffic before expecting usage and violation metrics to reflect a policy or guardrail change.