Risk Score vs. Refusal Decision Mapping Prompt

This prompt is designed for product and safety engineering teams who need to translate a continuous numeric risk score into a discrete, defensible refusal action. The core job-to-be-done is not just classification, but policy mapping: taking a calibrated score from an upstream safety classifier and producing a structured decision table that defines exactly which score ranges map to 'allow', 'warn', 'redirect', 'escalate for human review', or 'block'. The ideal user is an ML engineer, safety platform builder, or trust-and-safety product manager who already has a risk scoring model and needs to operationalize it into a production gating function. Required context includes the upstream classifier's score range and semantics, the organization's safety policy categories, and the available response actions the system can take.

Use this prompt when you are defining threshold boundaries for the first time, recalibrating thresholds after a model update, or documenting the rationale for audit and compliance review. It is particularly valuable when multiple stakeholders—safety, legal, product—need to agree on where the lines are drawn. The prompt forces explicit justification for each boundary, which makes the decision-making process reviewable. It also handles edge cases near decision boundaries through sensitivity analysis, helping teams anticipate where small score fluctuations could flip a decision and where guard bands or tie-breaking rules are needed. Do not use this prompt if you do not yet have a calibrated risk score to map. It assumes the score exists and is meaningful; it does not build the classifier itself. For building the classifier, refer to the Safety Classification Confidence Scoring Prompt Template in this content group.

This prompt is not a replacement for A/B testing or production monitoring. The mapping table it produces is a design artifact—a hypothesis about where thresholds should be. Before shipping, you must validate the proposed thresholds against a labeled golden dataset, measure refusal rates and false-positive/false-negative trade-offs, and run the Confidence Threshold A/B Test Configuration Prompt to compare alternatives in production. Also avoid using this prompt for real-time per-request gating; it is a design-time tool for producing a configuration that your application code then enforces. For runtime gating, use the Risk Threshold Gating Decision Prompt, which consumes the threshold configuration this prompt produces and applies it to individual requests with audit trail generation.

This template translates a numeric risk score into a binary refusal decision while producing a structured justification for the chosen threshold boundary. It is designed for product teams who need to define and document the relationship between continuous risk scores and discrete actions. The prompt forces explicit reasoning about edge cases where scores fall near decision boundaries, making the mapping auditable and debuggable rather than a black-box threshold.

textCopy
You are a safety decision analyst. Your task is to map a numeric risk score to a binary refusal decision and produce a structured justification for the threshold boundary.

## INPUT
Risk Score: [RISK_SCORE]
Score Range: [SCORE_RANGE_MIN] to [SCORE_RANGE_MAX]
Risk Category: [RISK_CATEGORY]
User Context: [USER_CONTEXT]

## THRESHOLD CONFIGURATION
Refusal Threshold: [REFUSAL_THRESHOLD]
Threshold Sensitivity Zone: [SENSITIVITY_ZONE] (scores within this range of the threshold require additional scrutiny)

## CONSTRAINTS
- If the risk score is at or above the refusal threshold, the decision must be REFUSE.
- If the risk score is below the refusal threshold but within the sensitivity zone, you must flag the case for review and explain the proximity risk.
- If the risk score is below the threshold and outside the sensitivity zone, the decision must be ALLOW.
- Do not override the threshold based on intuition. If you believe the threshold is wrong for this case, note it in the threshold_feedback field.
- Provide specific evidence from the risk score and category to support your decision.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "decision": "REFUSE" | "ALLOW" | "FLAG_FOR_REVIEW",
  "risk_score": number,
  "threshold_applied": number,
  "proximity_to_threshold": number (distance from threshold, negative if below),
  "sensitivity_zone_triggered": boolean,
  "justification": "string explaining why this score maps to this decision",
  "edge_case_analysis": "string describing any boundary concerns or ambiguity",
  "threshold_feedback": "string or null - note if the threshold seems inappropriate for this case",
  "recommended_action": "string - concrete next step for the system or reviewer"
}

## EXAMPLES
[EXAMPLES]

## OUTPUT

Adapt this template by adjusting the threshold configuration block to match your organization's risk tolerance. For high-stakes domains such as healthcare or finance, set a wider sensitivity zone and route all FLAG_FOR_REVIEW cases to human reviewers. The threshold_feedback field is critical for detecting threshold drift: aggregate these notes across decisions to identify when your thresholds need recalibration. Before deploying, validate that the output JSON matches the schema exactly and test edge cases where the risk score equals the threshold value or falls exactly at the sensitivity zone boundary.

This prompt is designed to sit between a safety classifier that outputs numeric risk scores and a decision engine that enforces binary allow/block actions. The implementation harness must treat the mapping table as a configuration artifact—not a one-time generation. Store the output as a versioned JSON document in your safety policy repository, with each threshold boundary accompanied by its justification and edge-case handling rules. The mapping table should be loaded at runtime by your decision service, which compares incoming risk scores against the defined buckets and applies the corresponding action. This separation ensures that threshold tuning does not require prompt changes or model redeployment; only the mapping artifact is updated.

Validation and schema enforcement is critical before the mapping table enters production. After the model returns the JSON, validate that every bucket covers a contiguous numeric range with no gaps or overlaps, that boundary values are monotonically increasing, and that each action field matches your allowed enum (e.g., allow, warn, redirect, review, block). Reject any output where the sensitivity_analysis section fails to identify at least one boundary where small score changes would flip the decision. If validation fails, retry the prompt once with the validation errors injected into the [CONSTRAINTS] field. After two failures, escalate to a human reviewer rather than deploying a broken mapping. Logging should capture the full prompt input, the raw model output, the validation result, and the final deployed mapping version. This audit trail is essential for governance reviews and incident postmortems.

Model choice matters. Use a model with strong structured output capabilities and low refusal rates on policy content. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are suitable defaults. Avoid small or instruction-tuned-only models that may hallucinate numeric ranges or skip the sensitivity analysis. Set temperature=0 to maximize deterministic threshold placement. If your safety classifier's score distribution shifts over time (e.g., after a model update), re-run this prompt with the new score distribution statistics in [CONTEXT] and compare the resulting mapping against the previous version using a diff tool. Human review is required before any mapping table goes live in a production refusal path. A safety engineer or product policy owner must sign off on the threshold boundaries, the edge-case handling rules, and the sensitivity analysis. Automate the diff presentation but not the approval decision.

Integration pattern: Your decision service should load the mapping table at startup or from a hot-reloadable config store. For each incoming request, extract the risk score from your classifier, iterate through the buckets in order, and return the action for the first bucket whose range contains the score. If no bucket matches, default to the most conservative action (review or block) and fire an alert—this indicates a mapping gap. Monitor the distribution of scores landing in each bucket, especially the boundary-adjacent regions identified in the sensitivity analysis. If more than 5% of scores fall within 0.05 of a threshold boundary, flag for human review and consider adjusting the boundary or adding a review bucket. Do not use this prompt to generate per-request decisions at inference time; it is a configuration-generation tool, not a runtime classifier.