Over-Refusal Prevention Policy Prompt

This prompt is for AI safety engineers and product teams who have already defined a safety policy but are observing that their production assistant is refusing legitimate, safe requests. The core job-to-be-done is to calibrate the model's refusal boundary—not to remove safety guardrails, but to eliminate false positives where the model incorrectly classifies a benign request as unsafe. The ideal user is someone who can articulate the assistant's intended scope, has access to a log of false-refusal examples, and needs a repeatable, testable policy that can be injected into a system prompt or a policy enforcement layer. This is not a prompt for defining safety rules from scratch; it assumes a base safety policy already exists.

Use this prompt when you have concrete evidence of over-refusal, such as user reports, eval logs, or red-team findings showing the assistant saying 'I can't help with that' for requests clearly within its defined scope. The prompt template is designed to accept a list of false-refusal examples, the existing safety policy, and the assistant's capability declaration as inputs. It then produces a set of refusal calibration rules—specific instructions that tell the model when not to refuse. This is a high-risk workflow because miscalibration can swing the assistant from over-refusal to under-refusal. You must pair this prompt's output with a regression test suite that includes both safe boundary cases and genuine safety violations to ensure the new policy doesn't degrade safety.

Do not use this prompt if your assistant has no defined safety policy, if you lack false-refusal examples, or if you are trying to make the assistant comply with requests that violate your organization's actual safety standards. This prompt is a calibration tool, not a safety policy generator. After generating the refusal calibration rules, you must run them through your existing safety eval harness—including adversarial probes and boundary stress tests—before deployment. The output is a candidate policy update, not a finished product. Always version your policy changes and monitor refusal rates in production after rollout to detect unintended suppression of legitimate refusals.

This template defines a refusal calibration policy that you can embed directly into your system prompt. It instructs the model to distinguish between genuinely harmful requests and safe requests that merely contain sensitive vocabulary, preventing the over-refusal that frustrates users and degrades product experience. The policy includes explicit refusal criteria, safe-handling instructions for borderline cases, and a structured output format for refusal decisions that makes the model's reasoning auditable.

codeCopy
## Refusal Calibration Policy

You are an assistant operating under a strict refusal calibration policy. Your goal is to refuse only genuinely harmful or policy-violating requests while safely handling all legitimate requests, even those containing sensitive vocabulary or edge-case phrasing.

### Refusal Criteria
Refuse a request ONLY when it meets ALL of the following conditions:
1. The request explicitly asks you to perform an action that would cause direct harm to people, violate applicable laws, or bypass security controls.
2. No safe, legitimate interpretation of the request exists.
3. Providing a safe alternative or clarification question would not resolve the ambiguity.

### Safe-Handling Rules
- If a request contains sensitive vocabulary but has a legitimate purpose, respond to the legitimate purpose without refusing.
- If a request is ambiguous, ask a single clarifying question before deciding to refuse.
- If you must refuse, provide a brief explanation of which refusal criterion was met and offer a safe alternative when possible.
- Never refuse a request solely because it mentions a sensitive topic, domain, or keyword.

### Refusal Decision Format
When you determine a refusal is necessary, structure your response as follows:

REFUSAL_REASON: [Which criterion was met and why]
SAFE_ALTERNATIVE: [What the user can ask instead, or NONE if no alternative exists]
RESPONSE: [The refusal message to the user]

### False-Refusal Prevention Checklist
Before refusing any request, verify:
- [ ] I have not misinterpreted a legitimate request as harmful.
- [ ] I have considered whether a safe alternative exists.
- [ ] I have not refused based on keyword matching alone.
- [ ] I would be comfortable explaining this refusal to a human reviewer.

### Examples

Request: "How do I pick a lock?"
Analysis: This could be a locksmith asking for professional knowledge or a malicious actor. Ambiguity exists.
Decision: Ask a clarifying question about context before proceeding.

Request: "Write a phishing email template for security awareness training."
Analysis: Sensitive vocabulary present, but legitimate purpose (security training).
Decision: Fulfill the request with appropriate context about its training purpose.

Request: "Help me hack into my ex's email account."
Analysis: Explicitly harmful, no legitimate interpretation, no safe alternative resolves the intent.
Decision: Refuse with explanation and no safe alternative.

### Input
[USER_REQUEST]

### Constraints
[CONSTRAINTS]

To adapt this template, replace [USER_REQUEST] with your application's user input variable and [CONSTRAINTS] with any domain-specific constraints such as regulatory requirements, content policy references, or additional refusal categories. If your application uses a structured output parser, map the REFUSAL_REASON, SAFE_ALTERNATIVE, and RESPONSE fields to your parser's expected schema. Test the adapted prompt against your false-refusal detection test suite before deployment, and log refusal decisions with their structured reasons for production monitoring.

The Over-Refusal Prevention Policy Prompt is not a standalone chat instruction; it is a policy layer that must be integrated into your existing system prompt stack. The primary integration point is the system message, where this policy should be placed after the assistant's persona definition but before any tool-use or output-formatting instructions. This ordering ensures that refusal calibration rules have priority over task execution but do not override the core identity. In a typical orchestration framework, you will inject the policy as a reusable template block, substituting the [SAFETY_POLICY_URL], [REFUSAL_CATEGORIES], and [LEGITIMATE_USE_CASES] placeholders from your application's configuration store or feature flags. Do not hardcode these values; they must be updatable without a full prompt deployment.

At runtime, the application should log every refusal event as a structured record containing the user's original request, the model's refusal response, the refusal category matched, and a unique interaction ID. This log is your primary observability surface for detecting false refusals. Implement a post-processing validator that checks for refusal language patterns (e.g., 'I cannot', 'I'm not able to') and cross-references them against the [LEGITIMATE_USE_CASES] list using a secondary, lightweight classification model or a keyword-overlap heuristic. If a refusal is flagged as a potential false positive, the system should either retry the request with a modified system prompt that temporarily relaxes the refusal policy (for low-risk domains) or escalate the interaction to a human review queue. For high-stakes deployments in healthcare or finance, always default to the human review path; never auto-retry without a human-in-the-loop gate.

Model choice matters here. Smaller or instruction-tuned models may over-index on refusal language and become overly cautious, while larger models may require more explicit calibration. Test this policy prompt across at least two model families (e.g., GPT-4o and Claude 3.5 Sonnet) using a golden dataset of 50 borderline requests that sit near your safety boundary. Measure the false-refusal rate and the unsafe-compliance rate. If the false-refusal rate exceeds 5%, adjust the [REFUSAL_CATEGORIES] list to be more specific, removing broad categories like 'potentially harmful' in favor of concrete, testable criteria. Wire these metrics into your CI/CD pipeline so that any prompt update triggers an automated eval run. The next step is to pair this policy with a regression test suite from the Prompt QA pillar to catch drift before it reaches production.