Risk Score Bucketing and Routing Prompt

This prompt is for platform engineers and safety system builders who need to move beyond a binary refuse/allow decision. It takes a pre-calculated risk score and a configurable set of bucket boundaries, then assigns the request to a response strategy: allow, warn, redirect, review, or block. Use this when your safety architecture already produces a numeric risk score and you need consistent, auditable routing logic that can be tuned per environment, A/B tested, and explained to reviewers.

This is not a prompt for generating the risk score itself. Pair it with a safety classification prompt that outputs a calibrated score first, such as the Safety Classification Confidence Scoring Prompt Template or the Multi-Class Safety Risk Scoring Prompt Template. The bucketing prompt assumes the score exists and focuses entirely on the mapping from score to action. You should also avoid this prompt when your routing logic is simple enough to express as a single threshold in application code—if you only need to block scores above 0.8 and allow everything else, a code-level if statement is cheaper, faster, and easier to audit than an LLM call.

The ideal user is someone operating a production safety system who needs to change routing behavior without redeploying code, explain decisions to auditors, or run experiments comparing different threshold configurations. Before using this prompt, ensure you have defined your bucket boundaries, response templates per bucket, and a logging schema that captures the input score, assigned bucket, and final action for every request. If you cannot articulate why a score of 0.65 should route to review while 0.64 routes to warn, your boundaries need more definition before this prompt will add value.

This prompt template is designed to be the core instruction set for a model acting as a safety router. It takes a pre-computed risk score and a set of configurable bucket definitions, then outputs a structured routing decision. The primary job is to eliminate ambiguity in tiered safety responses, ensuring that every decision is deterministic, explainable, and auditable. Use this when you need to move beyond a binary allow/block and implement a graduated response strategy (e.g., allow, warn, redirect, review, block). Do not use this prompt for generating the initial risk score itself; it assumes that classification has already occurred upstream.

codeCopy
You are a safety routing engine. Your task is to assign a response bucket to a user request based on a provided risk score and a set of configurable thresholds. You must output a strict JSON object with no additional text.

## INPUT
- **User Request:** [USER_REQUEST]
- **Risk Score:** [RISK_SCORE] (a float between 0.0 and 1.0)
- **Risk Category:** [RISK_CATEGORY]

## BUCKET CONFIGURATION
[BUCKET_CONFIGURATION]

## ROUTING RULES
1. Compare the [RISK_SCORE] against the `threshold` of each bucket in [BUCKET_CONFIGURATION].
2. Assign the request to the first bucket where the [RISK_SCORE] is greater than or equal to the `threshold`.
3. If the score is below the lowest threshold, assign it to the first bucket (the lowest risk tier).
4. Select the appropriate `response_template` from the assigned bucket.
5. Populate the template with the [USER_REQUEST] and [RISK_CATEGORY] to create the `final_response`.

## OUTPUT SCHEMA
{
  "bucket_id": "string",
  "bucket_label": "string",
  "applied_threshold": number,
  "routing_decision": "allow" | "warn" | "redirect" | "review" | "block",
  "final_response": "string",
  "audit_trail": {
    "risk_score_input": number,
    "decision_rationale": "string",
    "timestamp_utc": "string"
  }
}

## CONSTRAINTS
- Do not modify the [RISK_SCORE].
- Do not invent new bucket labels or routing decisions.
- The `final_response` must be the exact text from the `response_template` with placeholders replaced.
- The `decision_rationale` must cite the specific threshold that was met.

To adapt this template, replace the [BUCKET_CONFIGURATION] placeholder with a JSON array of bucket objects, each containing a label, threshold, routing_decision, and response_template. For example, a warn bucket might have a threshold of 0.4 and a template like "I need to be careful about [RISK_CATEGORY] topics. [USER_REQUEST] is a sensitive area." The final_response is generated server-side by simple string replacement, but you can also instruct the model to do this for a fully self-contained prompt. Before deploying, validate the output against the JSON schema and test boundary conditions, such as a risk score exactly matching a threshold, to prevent off-by-one routing errors.

The Risk Score Bucketing and Routing Prompt is designed to sit between a safety classifier and the response delivery layer. It consumes a risk score (and optionally a harm category and confidence level) and produces a deterministic routing decision: allow, warn, redirect, review, or block. The implementation harness must treat this prompt as a policy execution engine, not a suggestion box. Every bucket assignment must be logged, every threshold crossing must be auditable, and every review-queue routing decision must carry enough context for a human reviewer to act without re-investigating the original request.

Wire the prompt into a decision service with the following contract. Input: a structured JSON payload containing risk_score (float 0.0–1.0), harm_category (string), confidence (float 0.0–1.0), and request_id (string). Output: a structured JSON payload with bucket (enum: allow, warn, redirect, review, block), response_template (string), escalation_path (string or null), and audit_context (object). Validate the output schema before acting on it. If the model returns an invalid bucket or a malformed response_template, retry once with a stricter schema constraint. If the retry also fails, default to the review bucket and log the failure as a routing_fallback event. Use a model with strong JSON-mode support (GPT-4o, Claude 3.5 Sonnet, or equivalent) and set temperature=0 to maximize deterministic behavior. Do not use this prompt with models that lack reliable structured output capabilities.

The bucket boundaries themselves should be configuration, not prompt content. Store thresholds in a config service or environment variables: allow_max, warn_max, redirect_max, review_max, and block_min. Pass these values into the prompt's [THRESHOLDS] placeholder at runtime. This separation lets you A/B test threshold changes without touching the prompt template. Log every routing decision with: request_id, risk_score, confidence, harm_category, assigned_bucket, thresholds_used, model_version, prompt_version, and timestamp. If the review or block bucket is assigned, also log the escalation_path and audit_context. For high-severity harm categories (child safety, self-harm, violence), consider a hard override in the application layer that forces block regardless of the model's output—this is a safety-critical circuit breaker, not a prompt concern.

Human review integration requires the review bucket to carry a reviewer-ready payload. The response_template field should contain a pre-drafted message for the reviewer (not the end user) summarizing the request, the risk score, the harm category, and the policy clause triggered. The escalation_path should specify which review queue, SLA tier, and priority level applies. Build a review tool that consumes this payload and presents it alongside the original user request. Measure review queue volume and false-positive rate per threshold configuration. If more than 5% of review-bucket decisions are overturned by human reviewers, your thresholds are too conservative—recalibrate. If any allow-bucket decision later results in a safety incident, your thresholds are too permissive—tighten immediately and conduct a root-cause analysis on the missed classification.

Avoid wiring this prompt directly into a synchronous user-facing response path without a safety buffer. The routing decision should gate the response, not decorate it. If the bucket is block or review, the user should receive a canned holding response while the review or refusal workflow executes. Never stream the model's raw output to the user before the bucket assignment is validated. Finally, treat this prompt as a versioned artifact in your CI/CD pipeline. Any change to the prompt template, threshold defaults, or output schema must pass a regression suite of known risk-score inputs with expected bucket assignments before deployment.