Limitations

This section highlights the current capability boundaries and important considerations of the OptScale AI. Reviewing these points helps better understand expected behavior, plan implementations more effectively, and get the best experience from the platform.

Policies + Guardrails

• Guardrails require a policy - A saved guardrail has no effect until it is linked to an Enabled policy and that policy's Conditions match the request.
• Condition mismatch - If Conditions or Request type are too narrow, traffic never enters evaluation even though the policy and guardrails are configured correctly.
• Sampling skips traffic - Sampling rate below 100% means some matching requests bypass evaluation; use Bypass rate on the policy detail page to confirm how often traffic is skipped.
• Evaluation timeout - When guardrail evaluation exceeds Timeout, behavior depends on Pass on timeout (request proceeds vs blocked or failed). Factor timeout into latency-sensitive Chat workloads.
• Stage alignment - Policy Evaluation scope Stage and each guardrail's Stage must fit the lifecycle point you intend (Input, Output, or Both). An Output guardrail does not inspect user prompts on its own.
• Threshold tradeoffs - Lower thresholds increase false positives; higher thresholds can miss borderline cases. Sentiment uses a different score scale than most other types - see Guardrail thresholds.
• Non-score guardrails - Token limit enforces configured limits directly rather than through a 0-1 confidence score.
• Disabled policies - A Disabled policy retains its configuration but does not evaluate traffic; linked guardrails on that policy do not run.
• Observability lag - Total invocations, Violation rate, and policy Usage statistics may show 0 or No data until matching traffic has flowed; use Traces to debug individual requests - see Core Services - Traces.