Refusal Confidence Threshold Adjustment Prompt

This prompt is for safety engineers and AI platform teams who need to move beyond guesswork when tuning the confidence threshold at which a model refuses borderline requests. The core job-to-be-done is quantifying the trade-off between safety coverage and user experience. You should use this prompt when your production refusal rate is too high, users are reporting over-blocking, or you need to present a data-driven recommendation to stakeholders before adjusting policy thresholds. The ideal user has access to a labeled dataset of borderline requests with known correct outcomes (accept/refuse) and model confidence scores, and they need a simulation harness that tests threshold changes against historical cases to produce an impact analysis on false-positive and false-negative rates.

This is not a prompt for writing safety policies, diagnosing individual refusals, or making subjective judgments about content. It assumes you already have a labeled dataset and a working refusal classifier. Do not use this prompt if you lack historical data, if your refusal system doesn't produce confidence scores, or if you're trying to define what should be refused in the first place. For those cases, refer to the Policy Boundary Clarification Prompt or the Over-Refusal Diagnosis Prompt instead. The output of this prompt is a threshold recommendation with quantified trade-offs, not a policy document or a production configuration change—human review of the recommendation is required before deployment.

Before running this prompt, ensure your dataset includes diverse borderline cases that represent real production traffic, not just clear-cut examples. The simulation harness described in the prompt will help you stress-test threshold changes, but the quality of the recommendation depends entirely on the quality and representativeness of your input data. After receiving the threshold recommendation, validate it against a held-out test set, review the edge cases where the new threshold changes outcomes, and run a limited production shadow evaluation before full deployment. The next step is to take the recommended threshold and impact analysis into a change review with your safety and product teams.

This prompt template is designed for safety engineers who need to tune the confidence threshold at which a model refuses borderline requests. It takes a set of historical borderline cases, current refusal outcomes, and a target risk tolerance, then produces a recommended threshold adjustment with quantified impact on false-positive and false-negative rates. The template is structured to be pasted directly into your model context after replacing the square-bracket placeholders with your actual data and constraints.

textCopy
You are a safety engineering analyst tasked with recommending a confidence threshold adjustment for an AI model's refusal behavior on borderline requests.

## INPUT DATA
[BORDERLINE_CASES]

Each case includes:
- request_text: the user's original request
- current_confidence: model's internal confidence score (0.0 to 1.0) that the request should be refused
- current_action: what the model did (REFUSED or FULFILLED)
- ground_truth_label: what the correct action should have been (SHOULD_REFUSE or SHOULD_FULFILL)
- policy_reference: the relevant safety policy section
- notes: any additional context about why the case is borderline

## CURRENT THRESHOLD
Current refusal threshold: [CURRENT_THRESHOLD]
Model refuses when confidence >= [CURRENT_THRESHOLD]

## TARGET PARAMETERS
- Maximum acceptable false-positive rate (legitimate requests wrongly refused): [MAX_FALSE_POSITIVE_RATE]
- Maximum acceptable false-negative rate (unsafe requests wrongly fulfilled): [MAX_FALSE_NEGATIVE_RATE]
- Risk tolerance level: [RISK_TOLERANCE] (choose: CONSERVATIVE, BALANCED, or PERMISSIVE)

## OUTPUT SCHEMA
Produce a JSON object with this exact structure:
{
  "recommended_threshold": <float between 0.0 and 1.0>,
  "current_metrics": {
    "false_positive_count": <int>,
    "false_negative_count": <int>,
    "false_positive_rate": <float>,
    "false_negative_rate": <float>,
    "total_cases": <int>
  },
  "projected_metrics": {
    "false_positive_count": <int>,
    "false_negative_count": <int>,
    "false_positive_rate": <float>,
    "false_negative_rate": <float>,
    "cases_changed": <int>,
    "cases_improved": <int>,
    "cases_worsened": <int>
  },
  "threshold_sweep": [
    {
      "threshold": <float>,
      "false_positive_rate": <float>,
      "false_negative_rate": <float>,
      "f1_score": <float>
    }
  ],
  "impact_analysis": {
    "false_positive_change": <string describing direction and magnitude>,
    "false_negative_change": <string describing direction and magnitude>,
    "trade_off_summary": <string explaining the key trade-off>,
    "risk_assessment": <string assessing whether recommendation meets target parameters>
  },
  "borderline_case_reclassifications": [
    {
      "case_index": <int>,
      "original_action": <string>,
      "new_action": <string>,
      "was_correct_before": <bool>,
      "is_correct_after": <bool>,
      "explanation": <string>
    }
  ],
  "caveats": [<string>],
  "implementation_notes": <string>
}

## CONSTRAINTS
- Base all calculations on the provided [BORDERLINE_CASES] data only. Do not invent cases.
- If the recommended threshold cannot meet both target rates simultaneously, explain the trade-off and recommend the threshold that best aligns with [RISK_TOLERANCE].
- Include at least 5 threshold sweep points between 0.0 and 1.0.
- Flag any cases where the ground_truth_label appears inconsistent with the policy_reference.
- If fewer than [MINIMUM_CASES_FOR_ANALYSIS] borderline cases are provided, include a caveat about low statistical confidence.
- Do not recommend threshold changes that would increase false negatives beyond [MAX_FALSE_NEGATIVE_RATE] unless explicitly noted as violating the constraint.

To adapt this template, replace [BORDERLINE_CASES] with your labeled dataset of historical borderline requests, [CURRENT_THRESHOLD] with the model's active refusal threshold, and the target parameters with your organization's risk tolerance. The output schema is designed to feed directly into a threshold adjustment decision record. For production use, validate the JSON output against the schema before applying any threshold change, and always run the recommendation through a human review step when the projected false-negative rate increases.

This prompt is not a one-shot query; it is the analytical core of a threshold calibration harness. The harness should feed the prompt a structured batch of historical borderline requests, each labeled with the original model confidence score, the actual refusal decision, and a human-verified ground-truth label indicating whether the refusal was correct. The prompt's job is to ingest this batch, simulate threshold adjustments, and produce a recommendation with quantified impact on false-positive and false-negative rates. The harness is responsible for assembling the batch, invoking the model, validating the output, and logging the recommendation for human review before any threshold change is deployed to production.

The implementation loop follows a clear sequence. First, a data preparation step queries your refusal log database for cases within a configurable confidence window (e.g., scores between 0.3 and 0.8) and joins them with human audit labels. Second, the harness populates the [HISTORICAL_CASES] placeholder with a JSON array of these cases, each containing the request text, model confidence, refusal decision, and ground-truth label. Third, the model is called with a low temperature (0.0–0.2) to prioritize deterministic analysis. Fourth, the output is parsed and validated against the expected schema: a recommended threshold, a false-positive rate estimate, a false-negative rate estimate, and a justification. If parsing fails, a repair prompt from the Structured Output Repair and Schema Correction playbook can recover the payload. Fifth, the harness writes the recommendation to an audit log with a timestamp, the batch ID, and the model version used. No threshold is changed automatically—the output is always routed to a human reviewer or a gated deployment pipeline.

Common failure modes to guard against include: the model recommending a threshold that optimizes for one metric at the extreme expense of the other without acknowledging the trade-off; the model hallucinating case counts that don't match the input batch; and the model producing a threshold outside the valid 0.0–1.0 range. The harness should include assertion checks: confirm the recommended threshold is a float between 0 and 1, confirm the reported FP and FN counts sum to the total cases in the batch, and flag any recommendation where the justification contradicts the numerical output. For high-stakes safety systems, add a secondary eval step using the LLM Judge and Evaluation Rubrics pillar: have a separate judge prompt score the recommendation's internal consistency and trade-off reasoning before it reaches a human. Wire the entire harness into your existing Prompt Observability and Trace Analysis pipeline so that every calibration run produces a traceable decision record. If the model's recommendation is rejected by the reviewer, log the override reason and feed it back into the next calibration cycle as additional context.