Confidence-Informed Refusal Prompt

This prompt is designed for safety engineers and platform developers who need an AI system to refuse a request not because it violates a hard policy, but because the model's internal confidence in its ability to execute the task correctly falls below a defined operational threshold. The core job-to-be-done is to prevent silent, low-quality, or potentially harmful outputs by converting an internal uncertainty signal into a structured, user-facing refusal that is honest about its limitations. The ideal user is an engineer integrating this into an agent loop, a customer-support AI, or a clinical summarization tool where a wrong answer is far more costly than no answer.

Use this prompt when your application has a reliable upstream method for extracting or computing a model's confidence score (e.g., logprobs, a separate self-assessment prompt, or a calibrated classifier) and you need a downstream policy that acts on it. It is appropriate for high-stakes domains—healthcare, finance, legal, or infrastructure operations—where an incorrect autonomous action can cause real harm. The prompt is specifically built for scenarios where the refusal reason is 'I am not sure enough to do this safely,' which is distinct from a policy violation refusal like 'I cannot help with illegal activities.' You should not use this prompt if you lack a trustworthy confidence signal; feeding it an arbitrary or uncalibrated score will produce misleading refusals and erode user trust.

Before implementing, ensure you have defined a clear, static [CONFIDENCE_THRESHOLD] that has been validated against your specific use case and model. Do not use this prompt as a generic catch-all for bad outputs. It is a precision tool for gating actions based on uncertainty. The next step is to wire this prompt into your application's decision harness, ensuring that the refusal output is logged, the user is given a clear path forward, and the event is available for human review and threshold calibration.

This prompt template implements a confidence-informed refusal policy. Instead of refusing based on a content policy violation, it refuses because the model's internal confidence in producing a correct, grounded answer is below a specified threshold. The key distinction is in the explanation: the refusal language must frame the issue as an epistemic limitation ('I am not confident enough to answer this correctly') rather than a deontic one ('I am not allowed to answer this'). This preserves user trust and clearly signals that the system is optimizing for accuracy over fluency. The template is designed to be inserted into a larger system prompt or used as a standalone instruction for a stateless API call, with placeholders for the specific threshold, output schema, and escalation path.

markdownCopy
You are an AI assistant operating under a strict confidence-informed refusal policy.

Your primary directive is accuracy. You must refuse to produce an answer if your internal confidence in the correctness and factual grounding of that answer is below [CONFIDENCE_THRESHOLD].

When you receive [USER_INPUT], perform the following steps internally before generating any user-facing output:
1. Assess your confidence in providing a correct, well-grounded response to [USER_INPUT] on a scale of 0.0 to 1.0.
2. If your confidence is >= [CONFIDENCE_THRESHOLD], proceed to generate the answer following all other instructions.
3. If your confidence is < [CONFIDENCE_THRESHOLD], you MUST refuse to answer the question directly.

When refusing, you MUST generate a response that conforms to the following [OUTPUT_SCHEMA]:
{
  "status": "refused",
  "confidence_score": <float 0.0-1.0>,
  "refusal_reason": "<Explain the refusal in terms of uncertainty, e.g., 'Insufficient confidence due to ambiguous query', 'Knowledge boundary reached', 'Conflicting evidence in provided context'>",
  "user_message": "<A concise, helpful message to the user explaining that you cannot answer this confidently. Frame this as an uncertainty issue, not a policy block.>",
  "alternatives": [
    "<A bounded, specific suggestion for how the user could rephrase or what you *can* help with, e.g., 'Try asking for a summary of known facts about X instead of a definitive prediction.'>"
  ],
  "escalation": <true if this requires human review based on [RISK_LEVEL], else false>
}

[CONSTRAINTS]
- Never fabricate a confidence score. Your self-assessment must be honest.
- Do not use policy-violation language (e.g., 'I cannot fulfill that request', 'This goes against my guidelines').
- The 'user_message' must be polite, helpful, and must not hallucinate information to appear more capable.
- If [RISK_LEVEL] is 'high', always set 'escalation' to true and include a specific question for a human reviewer in the 'refusal_reason'.

To adapt this template, start by tuning [CONFIDENCE_THRESHOLD]. A threshold of 0.7 is a common starting point for high-stakes factual domains, while 0.5 might be acceptable for creative brainstorming tasks. The [RISK_LEVEL] placeholder should be wired to a context variable in your application, not hardcoded, so that the escalation behavior automatically tightens for regulated or irreversible actions. The [OUTPUT_SCHEMA] is provided as JSON for programmatic consumption; if your application requires plain text, replace the JSON block with a structured text format but retain the same fields. The most critical adaptation is ensuring that the model's self-assessed confidence is calibrated. This prompt alone does not guarantee calibration; you must pair it with an evaluation harness that measures the correlation between stated confidence and actual correctness on a golden dataset. If the model is consistently overconfident, you may need to adjust the threshold upward or add few-shot examples of honest refusal to the [EXAMPLES] placeholder.

The Confidence-Informed Refusal Prompt is not a standalone chat interaction; it is a decision gate in a larger AI pipeline. In production, this prompt sits between the model's primary output and the user-facing response. The application layer must capture the model's confidence score, compare it against a configured policy threshold, and branch the workflow: if confidence is above the threshold, the primary output is delivered; if below, the refusal response generated by this prompt is surfaced instead. This means the prompt must be called conditionally, not on every request, and its output must be treated as a structured payload that the application can parse and act on.

To implement this reliably, wrap the prompt call in a function that accepts the original user input, the model's primary output, and the confidence score as arguments. The function should first check if the confidence score is below the threshold before invoking the LLM to generate the refusal. This avoids unnecessary inference costs. The refusal prompt should return a structured JSON object with fields like refusal_message, uncertainty_reason, bounded_alternatives, and escalation_flag. Validate this schema immediately after the LLM call using a JSON schema validator. If validation fails, retry once with a stricter output constraint instruction appended to the prompt. If the retry also fails, fall back to a static, pre-approved refusal message and log the failure for investigation. Never pass an unvalidated refusal response directly to a user in a high-stakes context.

Logging and observability are critical for this pattern. Every refusal event should be logged with the original input hash, the confidence score that triggered the refusal, the refusal reason, the bounded alternatives offered, and whether the user accepted an alternative or escalated. This data lets you monitor refusal rates, detect threshold miscalibration, and identify topics where the model is frequently uncertain. For high-risk domains such as healthcare or legal, route refusal events to a human review queue with the full context package. The review queue item should include the original input, the model's primary output, the confidence score, and the generated refusal, allowing a human to override the refusal if the model was overly cautious. This closes the loop between automated refusal and human judgment, preventing the system from becoming a bottleneck while maintaining safety.