Policy Engine

Evaluation tells you what the score is. The policy engine tells your application what to do about it: “if the safety score drops below 7.5, block the response.” There are two ways to apply a policy:

Application policy (recommended). Configure enforcement mode, thresholds, dimension weights, compliance frameworks, and safe-regeneration fallback once per application in the dashboard. It’s enforced automatically for every evaluation made with that application’s keys — no per-request logic in your code. Inspect the live policy with GET /config; every evaluation reports the outcome as policy_outcome.
SDK policy (local). Set a policy= on RAILSession or RAILMiddleware and let the SDK enforce it in your process. Useful for local-only logic, or enforcement you don’t want to manage centrally.

Application policy: GET /config | SDK policy: Python: Policy Engine | Sessions: RAILSession

Evaluation vs policy

	Evaluation	Policy Engine
Returns	Scores, confidence, explanations	An enforcement outcome: `log_only` / `block` / `regenerate`
Role	Observation	Enforcement
When to use	You want scores and will decide what to do	You want the platform (or the SDK) to enforce a threshold automatically

Application policy

Every evaluation is checked against your application’s configured policy and reports the outcome. The policy itself is three things:

enforcement — log_only (record outcomes only), block (reject content below threshold), or regenerate (attempt a safe rewrite via /safe-regenerate, then apply a configured fallback if that doesn’t pass either).
Thresholds — an overallThreshold for the combined score, plus optional dimensionThresholds so an individual dimension (e.g. safety) can fail the policy even when the overall score passes.
Enforcement mode — a policy can be active (able to block/regenerate responses) or in monitor mode (outcomes are recorded and returned but responses are never altered). Monitor mode is how you validate a new threshold against real traffic before turning it on.

See GET /config for the full policy shape and how to read the current enforcement mode, and policy_outcome for what each evaluation response reports.

SDK policy (local)

The Python SDK’s local equivalent is a five-value Policy enum — LOG_ONLY, BLOCK, REGENERATE, CUSTOM (call your own callback), and DPDP_ENFORCE (run a DPDP scan before the threshold check). You attach it to RAILSession (multi-turn conversations) or RAILMiddleware (wrapping a single generation call), and the SDK enforces it in your process — independent of, and in addition to, any application policy configured in the dashboard.

from rail_score_sdk import RAILMiddleware, Policy

mw = RAILMiddleware(
    api_key="YOUR_RAIL_API_KEY",
    generate_fn=my_model_call,
    threshold=7.0,
    policy=Policy.BLOCK,
)

result = await mw.run(messages=[{"role": "user", "content": "..."}])

RAILSession applies the same policy= per turn, and exposes running conversation stats (session.average_score, session.lowest_score, session.scores_summary()) so you can react to drift across a whole conversation rather than just one turn — see Python: Sessions. See Python: Policy Engine for the full Policy reference, RAILBlockedError handling, and how to drive PolicyEngine standalone.

Getting Started

Core concepts

Governance

Specialized checks

Evaluation vs policy

Application policy

SDK policy (local)

​Evaluation vs policy

​Application policy

​SDK policy (local)

Evaluation vs policy

Application policy

SDK policy (local)