Risk Threshold Gating Decision Prompt

This prompt is for safety platform builders who need to convert raw risk scores into a deterministic, auditable routing decision. The job-to-be-done is not classification itself—it is the gating logic that sits between a safety classifier and the system's response path. You use this prompt when you have already produced a risk score (from a classifier, a heuristic, or a human label) and now need to decide whether to allow, block, flag, or escalate the request based on a configurable threshold policy. The ideal user is an ML engineer, trust-and-safety engineer, or platform operator who owns the refusal pipeline and needs decisions that are reproducible, explainable, and tunable without redeploying model weights.

Do not use this prompt as a classifier. It assumes risk scores already exist as input. Do not use it when you need nuanced natural-language refusal text—that belongs to a separate refusal generation prompt downstream of this gating decision. This prompt is also inappropriate when the risk assessment requires multi-turn context accumulation; for that, use the Multi-Turn Cumulative Risk Scoring Prompt first, then feed the aggregated score into this gating prompt. The prompt works best when your organization has defined explicit risk thresholds (for example, a score of 0.7 triggers review, 0.9 triggers block) and you need consistent enforcement across traffic. It is especially valuable when you are A/B testing threshold configurations, because the prompt can be parameterized with different threshold values while keeping the decision logic identical, enabling clean comparisons between experimental arms.

Before deploying this prompt, ensure you have a threshold configuration source—a JSON file, a feature flag, a database row—that defines the boundary values for each action tier. The prompt expects those thresholds as input, not hardcoded in the instructions. After implementing, monitor three signals: refusal rate drift (is the proportion of blocked requests changing unexpectedly?), threshold boundary crowding (are many scores clustering just above or below a threshold, indicating the classifier and threshold are misaligned?), and audit trail completeness (is every decision producing a valid, queryable record?). If you observe threshold boundary crowding, do not adjust the prompt—recalibrate the upstream classifier or revisit the threshold values themselves. The next step after reading this section is to copy the prompt template, wire it into your decision harness, and run the eval checks described in the implementation section.

This prompt template is the core decision engine for a configurable refusal gate. It takes pre-computed risk scores from an upstream safety classifier and compares them against adjustable thresholds to produce a deterministic routing decision: allow, warn, redirect, review, or block. The template is designed to be wrapped in application code that supplies the scores, thresholds, and routing table, so the model's job is narrow—apply the rules, justify the decision, and produce a structured audit record. Do not use this prompt to generate risk scores; it assumes scores already exist from a separate classification step.

textCopy
You are a safety routing decision engine. Your job is to compare provided risk scores against configured thresholds and produce a gated routing decision with a structured audit trail. You do not classify content or generate risk scores. You only apply threshold rules to scores that are already provided.

## INPUT
Risk Scores: [RISK_SCORES]
Threshold Configuration: [THRESHOLD_CONFIG]
Routing Table: [ROUTING_TABLE]
Request Summary: [REQUEST_SUMMARY]
Session Context: [SESSION_CONTEXT]

## RISK_SCORES format
A JSON object mapping harm categories to numeric scores between 0.0 and 1.0, with an optional aggregated severity level.

## THRESHOLD_CONFIG format
A JSON object defining threshold boundaries for each harm category and the aggregation rule for combining category scores into a single decision tier.

## ROUTING_TABLE format
A JSON object mapping decision tiers to routing actions: allow, warn, redirect, review, or block. Each action may include a destination queue, response template reference, and SLA priority.

## INSTRUCTIONS
1. Compare each category score in [RISK_SCORES] against the corresponding threshold in [THRESHOLD_CONFIG].
2. Apply the aggregation rule from [THRESHOLD_CONFIG] to determine the overall decision tier.
3. Map the decision tier to a routing action using [ROUTING_TABLE].
4. If any score falls within a configured uncertainty band near a threshold boundary, flag it for potential human review regardless of the computed tier.
5. Produce the output in the exact [OUTPUT_SCHEMA] format.

## CONSTRAINTS
- Do not re-score, re-classify, or interpret the content of [REQUEST_SUMMARY].
- Do not override threshold boundaries unless an uncertainty band rule applies.
- If [SESSION_CONTEXT] indicates a cumulative risk escalation, apply the escalation multiplier from [THRESHOLD_CONFIG] before comparing scores.
- If the input is malformed or missing required fields, output an error decision with reason "INVALID_INPUT" rather than guessing.

## OUTPUT_SCHEMA
{
  "decision_id": "string, unique identifier for this decision",
  "timestamp": "ISO 8601 timestamp",
  "routing_action": "allow | warn | redirect | review | block",
  "decision_tier": "string, the computed tier from threshold comparison",
  "routing_target": "string or null, destination queue or handler",
  "sla_priority": "string, from routing table",
  "category_decisions": [
    {
      "category": "string",
      "score": "number",
      "threshold": "number",
      "exceeded": "boolean",
      "in_uncertainty_band": "boolean"
    }
  ],
  "aggregation_method": "string, the rule used to combine category scores",
  "uncertainty_flags": ["string, categories or conditions flagged for review"],
  "session_escalation_applied": "boolean",
  "escalation_multiplier": "number or null",
  "decision_rationale": "string, concise explanation of how thresholds were applied",
  "error": "null or object with code and reason if input was invalid"
}

Adapt this template by replacing the placeholder descriptions with your actual data contracts. The [RISK_SCORES] should match the output schema of your upstream safety classifier. The [THRESHOLD_CONFIG] is your policy lever—store it in configuration, not in the prompt, so you can adjust thresholds without changing the prompt text. The [ROUTING_TABLE] defines what happens at each tier; keep it separate so operations teams can modify routing without touching model instructions. Wire [SESSION_CONTEXT] to your session store so cumulative risk scoring can escalate users who probe boundaries across multiple turns. Test with edge cases where scores land exactly on threshold boundaries and within uncertainty bands to verify the flagging behavior works as intended.

The Risk Threshold Gating Decision Prompt is designed to sit between a safety classifier and a downstream action handler—such as a refusal module, a human review queue, or a safe-alternative generator. In a production harness, you call this prompt after you have obtained per-category risk scores and a severity classification from an upstream safety scoring prompt. The prompt's job is not to re-score the input but to apply configurable threshold logic, produce a deterministic routing decision, and generate an audit trail. This separation of concerns keeps threshold configuration independent of classification logic, which is essential for A/B testing different gating policies without retraining or rewriting safety classifiers.

To wire this into an application, wrap the prompt call in a decision service that accepts a threshold_config object and a risk_assessment payload. The service should validate that all required fields—risk_scores, severity, harm_category, and uncertainty_flags—are present before calling the model. After receiving the model's structured output, run a post-processing validator that checks: (1) the routing_decision field matches one of the allowed enum values (allow, warn, redirect, review, block), (2) the threshold_comparisons array contains entries for every threshold rule that was active, and (3) the audit_trail includes a timestamp, model version, and threshold configuration hash. If validation fails, retry once with a more constrained output schema; if it fails again, default to the most conservative routing decision (review or block) and log the failure as a high-severity incident. For high-risk domains, always require that the audit_trail is written to an append-only log before the routing decision is acted upon.

For A/B testing, deploy two threshold configurations side by side and route traffic deterministically based on a session or request hash. Log the threshold_config_id alongside every decision so you can compare refusal rates, review queue volumes, and safety incident reports across arms. Monitor for threshold boundary crowding—a condition where many risk scores cluster just below or just above a decision boundary, indicating that small classifier drift could flip many decisions. Set up alerts when the proportion of scores within ±0.05 of any threshold exceeds 20% of traffic. For model choice, prefer models with strong instruction-following and structured output support (GPT-4o, Claude 3.5 Sonnet) because the prompt requires precise threshold comparison and no creative reinterpretation of the routing rules. Avoid using this prompt with models that have known difficulties with numeric comparison or multi-field structured output. Finally, never allow the model to override the threshold values provided in the configuration—the prompt must treat thresholds as immutable constraints, and your post-processing should verify that the decision matches what a deterministic threshold function would produce given the same inputs.