Overly Conservative Refusal Rewrite Prompt

This prompt is for product teams and safety engineers who need to fix refusal responses that are technically correct but unnecessarily harsh, unhelpful, or poorly explained. The model correctly identified a safety boundary, but the delivery damages user trust. Use this when you have a logged refusal that should remain a refusal, but the response language needs calibration—the refusal boundary was appropriate, but the tone, explanation quality, or constructive guidance fell short of product standards.

Ideal candidates for this prompt are refusals where: (1) the safety decision was correct and should be preserved, (2) the response reads as dismissive, robotic, or punitive, (3) the user received no explanation of why the refusal occurred, and (4) no safe alternative was offered when one exists. Do not use this prompt when the refusal itself was incorrect—that requires the Legitimate Request Recovery After False Refusal prompt instead. Also avoid this prompt when the underlying safety policy is genuinely ambiguous; use the Policy Boundary Clarification Prompt to resolve the policy question first, then calibrate refusal delivery.

Before applying this prompt, confirm that you have the original user request, the original refusal response, and the relevant safety policy citation that justified the refusal. Without the policy citation, the rewrite risks drifting from the original boundary. The prompt is designed to work on a single refusal-response pair at a time—batch processing requires the Refusal Audit and Log Review Prompt for scalable triage before individual rewrites. Always run the output through the Refusal Justification Quality Evaluation Prompt to verify that tone improvements didn't accidentally soften the safety boundary.

The following prompt template is designed to be pasted directly into your AI harness. It instructs the model to analyze a previous refusal that was technically correct but unnecessarily harsh, unhelpful, or poorly explained, and to produce a rewritten version that maintains the same safety boundary while improving tone, explanation quality, and user guidance. All dynamic values are represented as square-bracket placeholders that your application must replace with live data before inference.

textCopy
You are a safety response editor. Your task is to rewrite an overly conservative refusal into a response that maintains the same safety boundary while being more helpful, empathetic, and informative.

## ORIGINAL REFUSAL
[ORIGINAL_REFUSAL]

## USER REQUEST
[USER_REQUEST]

## APPLICABLE SAFETY POLICY
[SAFETY_POLICY]

## REWRITE CONSTRAINTS
- Do not weaken or remove the safety boundary. The refusal must still decline any unsafe portion of the request.
- Improve the tone: replace harsh, dismissive, or robotic language with respectful, empathetic phrasing.
- Add a clear, honest explanation of *why* the request cannot be fulfilled, referencing the specific policy concern without being evasive.
- Where possible, offer one or more constructive, safe alternatives that address the user's underlying intent.
- If the original refusal was a complete block but partial fulfillment is safe, provide the safe portion and clearly mark the refused portion with its reason.
- Maintain a professional and helpful tone throughout.

## OUTPUT FORMAT
Return a JSON object with the following structure:
{
  "rewritten_response": "The full rewritten response text.",
  "safety_boundary_preserved": true or false,
  "tone_improvements": ["List of specific tone changes made"],
  "alternatives_offered": ["List of safe alternatives provided, or empty array if none"],
  "partial_fulfillment_included": true or false,
  "explanation_added": "Summary of the explanation added for the refusal"
}

To adapt this template for your production system, replace each placeholder with live data from your application context. [ORIGINAL_REFUSAL] should contain the full text of the model response that was deemed overly conservative. [USER_REQUEST] should contain the original user input that triggered the refusal. [SAFETY_POLICY] should contain the relevant excerpt from your safety policy documentation that the model should reference when rewriting. If your system uses a policy database, retrieve the most relevant policy section programmatically rather than hardcoding it. The output schema is designed for programmatic consumption—validate that safety_boundary_preserved is true before serving the rewritten response to users, and log all fields for audit and policy improvement analysis. For high-risk domains, always route the rewritten response through human review before publishing.

The Overly Conservative Refusal Rewrite Prompt is designed to sit between the initial model refusal and the user-facing response. In a production harness, you intercept the model's first refusal output, classify it as a refusal, and route it through this rewrite prompt before returning the final response to the user. This architecture preserves the original safety decision while improving tone and helpfulness. The rewrite prompt should never be applied to refusals triggered by genuine safety violations—only to refusals flagged as overly conservative by a classifier or confidence threshold. Implement a pre-check that verifies the original refusal reason code before invoking the rewrite, and maintain an audit trail of both the original and rewritten responses for safety review.

Wire the prompt into your application as a post-processing step within the response pipeline. After the primary model generates a response, run a refusal classifier that checks for refusal signals and extracts a reason code. If the classifier returns a reason code in your allowlist for rewrite (e.g., policy_misinterpretation, overly_broad_scope, tone_only), pass the original user request, the original refusal text, and your policy context into the rewrite prompt. Use structured output to receive the rewritten response, a confidence score, and a safety boundary check. Validate the output against three criteria before returning it to the user: (1) the rewritten response must not fulfill a genuinely unsafe request, (2) the tone and helpfulness must improve over the original, and (3) the safety boundary must remain intact. If validation fails, fall back to the original refusal and log the failure for review.

For model choice, use a capable instruction-following model with strong safety alignment—GPT-4o, Claude 3.5 Sonnet, or equivalent. Avoid smaller or less-aligned models that might misinterpret the rewrite instruction as permission to weaken safety boundaries. Implement retry logic with a maximum of two rewrite attempts: if the first rewrite fails validation, retry once with explicit feedback from the validator. If both attempts fail, return the original refusal and escalate to the safety team. Log every rewrite attempt with the original request, original refusal, rewritten response, validation results, and final disposition. This audit trail is essential for safety governance and for identifying patterns that require policy updates. Never cache rewritten refusals across different user requests—each rewrite must be context-specific to avoid leaking safety decisions between conversations.

Testing this harness requires a dedicated eval suite. Build a golden dataset of 50–100 known overly conservative refusals with expected acceptable rewrites, and an equal number of genuine safety refusals that must not be rewritten. Run the full pipeline—classifier, rewrite prompt, validator—against both sets. Measure false-positive rewrite rate (genuine refusals incorrectly rewritten) and false-negative rate (overly conservative refusals not improved). Your false-positive rewrite rate must be zero before production deployment. For ongoing monitoring, track the rewrite rate as a percentage of total refusals, the validation failure rate, and user re-request rate after receiving a rewritten refusal. A rising re-request rate may indicate that rewrites are not adequately addressing user needs, while a rising validation failure rate may signal prompt drift or model behavior changes requiring investigation.