Refusal Style Calibration Prompt for Product Managers

Product managers and safety engineers use this prompt when a model's refusal tone is technically correct but damages user experience. The core job-to-be-done is decoupling the safety decision from its presentation: the boundary of what the model refuses remains fixed, while the tone, empathy, and helpfulness of the refusal become tunable parameters. This is essential before shipping a policy change, when A/B testing refusal copy, or when user feedback flags refusals as unhelpful, hostile, or robotic. The ideal user already has a defined safety policy and needs to improve how that policy is communicated, not re-litigate the policy itself.

Do not use this prompt when the underlying safety boundary is wrong. If the model is refusing requests it should fulfill, start with an over-refusal diagnosis prompt to identify false positives. If the policy language is ambiguous, use a policy boundary clarification prompt first. This prompt assumes the refusal decision is correct and only the stylistic delivery needs work. It is also not a replacement for human policy review in regulated domains—any refusal style change that could be interpreted as encouraging unsafe behavior must go through your standard policy approval process before deployment.

The prompt produces multiple refusal variants across a calibration spectrum—from blunt and direct to warm and constructive—without altering the safety boundary. Each variant includes user-experience impact notes so you can predict how the tone change will land. The output is designed to feed directly into an A/B test harness where you measure user satisfaction, re-request rates, and escalation frequency. Before shipping, validate that no variant accidentally weakens the refusal by running your standard safety regression suite against each candidate. The goal is better user experience at the same safety level, not better user experience by lowering the safety bar.

The following prompt template is designed to produce a spectrum of refusal responses for a single user request, ranging from terse and technical to warm and empathetic. Product managers use this to calibrate the tone and helpfulness of safety refusals without altering the underlying policy boundary. The template forces the model to generate multiple variants, each with a structured UX impact note, making it directly usable for A/B testing and stakeholder review.

textCopy
You are a refusal style calibration assistant. Your task is to generate multiple refusal response variants for a given user request, each representing a different point on a tone and helpfulness spectrum. You must not change the safety boundary; all variants must refuse the request if it violates the provided policy. Your output must be valid JSON matching the specified schema.

## POLICY
[POLICY_DESCRIPTION]

## USER REQUEST
[USER_REQUEST]

## CALIBRATION SPECTRUM
Generate one refusal variant for each of the following styles:
1. **Minimal and Direct**: Shortest possible refusal. No explanation, no alternative.
2. **Policy-Citing**: Refusal that explicitly cites the relevant policy clause.
3. **Educational**: Refusal that explains *why* the policy exists, helping the user understand the boundary.
4. **Empathetic and Warm**: Refusal that acknowledges the user's possible frustration while maintaining the boundary.
5. **Alternative-Offering**: Refusal that suggests a safe, constructive alternative that addresses the user's underlying goal.
6. **Clarification-Seeking**: Response that asks a clarifying question to determine if a safe interpretation of the request is possible before refusing.

## CONSTRAINTS
- Do not fulfill any part of a request that violates the policy.
- Do not provide information that could be used to circumvent the policy.
- For the Clarification-Seeking variant, the question must not lead the user toward rephrasing the unsafe request.
- All variants must be self-contained and ready to show to a user.

## OUTPUT SCHEMA
Return a single JSON object with this exact structure:
{
  "request_summary": "A neutral one-line summary of the user's request.",
  "policy_applied": "The specific policy clause that triggers the refusal.",
  "variants": [
    {
      "style": "Minimal and Direct",
      "response_text": "The refusal text.",
      "ux_impact_note": "Brief assessment of user experience impact (e.g., 'May feel dismissive; low risk of re-request')."
    },
    {
      "style": "Policy-Citing",
      "response_text": "...",
      "ux_impact_note": "..."
    },
    {
      "style": "Educational",
      "response_text": "...",
      "ux_impact_note": "..."
    },
    {
      "style": "Empathetic and Warm",
      "response_text": "...",
      "ux_impact_note": "..."
    },
    {
      "style": "Alternative-Offering",
      "response_text": "...",
      "ux_impact_note": "..."
    },
    {
      "style": "Clarification-Seeking",
      "response_text": "...",
      "ux_impact_note": "..."
    }
  ]
}

To adapt this template, replace [POLICY_DESCRIPTION] with the exact text of your safety policy clause and [USER_REQUEST] with a real or representative user input that should trigger a refusal. For production use, you can wire this prompt into an A/B test harness that logs which variant was shown, measures the user's subsequent re-request rate, and collects satisfaction signals. Always run the output through a JSON schema validator before surfacing any variant to a user. If the model fails to produce valid JSON, retry once with a stricter format reminder; if it fails again, log the raw output and escalate for manual review rather than guessing.

The Refusal Style Calibration Prompt is designed to be integrated into a product's existing refusal handling pipeline, not as a standalone script. When a user request triggers a safety refusal, the application should intercept the default refusal response and route it through this calibration prompt to generate multiple stylistic variants. The prompt expects a structured input payload containing the original user request, the model's raw refusal response, the specific safety policy that was triggered, and a calibration spectrum definition (e.g., from 'minimalist' to 'empathetic'). The output is a JSON array of refusal variants, each tagged with a style label and a predicted user-experience impact note. This output should never be shown directly to end users; it is a decision-support artifact for product managers and safety engineers to select, test, and deploy a calibrated refusal style.

To wire this into an application, build a post-refusal hook in your inference pipeline. After the primary model returns a refusal classification, serialize the [ORIGINAL_REQUEST], [RAW_REFUSAL_RESPONSE], [TRIGGERED_POLICY_ID], and [CALIBRATION_SPECTRUM] into the prompt template. Send this to a separate model call—often a slower, more capable model like GPT-4o or Claude Opus, since calibration is an offline or async tuning task, not a real-time user-facing path. Validate the output against a strict JSON schema that requires each variant object to have style_label, refusal_text, and ux_impact_note fields. If validation fails, retry once with the validation error appended as [PREVIOUS_ERROR]. Log every calibration run with a unique calibration_run_id, the input policy ID, and the generated variants. For the A/B test harness, store each variant as a separate treatment arm in your feature flag or experimentation platform. Instrument the user-facing application to measure re-request rate (does the user rephrase and try again?), escalation rate (do they click 'talk to a human'?), and a post-interaction satisfaction survey score. These metrics directly measure whether a refusal style is helpful or frustrating.

Do not deploy a new refusal variant to production users without human review. The UX impact notes generated by the prompt are model predictions, not validated facts. A safety engineer or product manager must review each variant for policy compliance—ensuring the refusal boundary hasn't softened—and for tone appropriateness. Use a review queue that blocks promotion to production until explicitly approved. After approval, deploy the variant as a percentage rollout and monitor the A/B metrics for at least one full business cycle before declaring a winner. Avoid the temptation to automate variant selection based solely on satisfaction scores; a variant that reduces re-request rates by being overly permissive is a safety regression, not a UX win. The calibration prompt is a tool for generating options, not for making the final decision.