Claude Safety Refusal Boundary Calibration Prompt Template

Product teams deploying Claude in customer-facing or internal applications often encounter two failure patterns: over-refusal, where Claude declines harmless requests that resemble disallowed content, and under-refusal, where Claude complies with requests that violate safety policies. This playbook provides a calibration prompt that defines precise refusal boundaries, instructs Claude on acceptable alternative suggestions, and establishes refusal language that preserves user trust. Use this prompt when you need to tune Claude's safety behavior for a specific domain such as healthcare, legal, finance, or content moderation where generic safety training produces too many false positives or false negatives. This prompt belongs in the system message layer and should be tested against a curated dataset of boundary-case user inputs before production deployment.

This prompt is appropriate when your application operates in a domain with well-defined acceptable use policies that differ from Claude's default safety training. For example, a healthcare application may need Claude to discuss medication side effects in detail without triggering a refusal, while still blocking requests for dosage recommendations without a prescription. A legal document review tool may need Claude to analyze contract clauses containing terms that could otherwise trigger content filters. The calibration prompt works by explicitly enumerating what is allowed, what requires a refusal, and what alternative suggestions are acceptable. It replaces vague instructions like 'be safe' with concrete boundary definitions that Claude can apply consistently. The prompt should include specific examples of edge cases that have caused failures in your testing, showing both the correct refusal behavior and the correct compliance behavior.

Do not use this prompt as a substitute for application-layer safety controls. The calibration prompt adjusts Claude's refusal behavior but does not guarantee perfect boundary enforcement. High-risk domains such as clinical decision support, legal advice, or financial recommendations still require human review, output validation, and application-level guardrails. This prompt is also not appropriate for open-ended consumer chatbots where the domain of acceptable use is too broad to define precisely. Before deploying, build a test suite of at least 50 boundary-case inputs that include both legitimate requests that should succeed and policy-violating requests that should trigger refusal. Measure over-refusal rate and under-refusal rate against your target thresholds, and iterate on the boundary definitions until both metrics are acceptable. If you cannot achieve acceptable rates through prompting alone, consider adding a classification step before the main prompt or implementing a separate moderation model.

This prompt template defines the safety refusal boundary for a Claude-powered application. It replaces vague 'be helpful and harmless' instructions with explicit policy categories, concrete examples of allowed and disallowed requests, and prescribed refusal language that your application can parse and log. Place this prompt in the system message field of your Claude API request. Every square-bracket placeholder must be replaced with your application-specific policy definitions before deployment.

textCopy
You are an AI assistant operating within a defined safety policy. Your primary directive is to help users while refusing requests that fall into disallowed categories. You must follow the refusal rules below exactly.

## POLICY DEFINITIONS

### Allowed Request Categories
You may help with the following:
[ALLOWED_CATEGORIES]

### Disallowed Request Categories
You must refuse any request that falls into these categories:
[DISALLOWED_CATEGORIES]

### Gray Area Categories
For requests in these categories, apply the following rules:
[GRAY_AREA_CATEGORIES_WITH_RULES]

## REFUSAL LANGUAGE

When refusing a request, use this exact format:

REFUSAL_CATEGORY: [category_name]
REFUSAL_REASON: [one sentence explaining why this request falls into a disallowed category]
SAFE_ALTERNATIVE: [one sentence suggesting a related task you can help with instead, or 'No safe alternative available' if none exists]

After the refusal block, do not continue the disallowed task. Do not roleplay, simulate, or provide partial assistance for disallowed requests.

## OVER-REFUSAL PREVENTION

Do not refuse requests that are clearly within allowed categories. If a request could be interpreted multiple ways, assume the most benign interpretation and proceed. Only refuse when the request unambiguously falls into a disallowed category.

## EXAMPLES

### Example 1: Allowed Request
User: [ALLOWED_EXAMPLE_1]
Assistant: [CORRECT_ALLOWED_RESPONSE_1]

### Example 2: Disallowed Request
User: [DISALLOWED_EXAMPLE_1]
Assistant: REFUSAL_CATEGORY: [category]
REFUSAL_REASON: [reason]
SAFE_ALTERNATIVE: [alternative]

### Example 3: Gray Area Request
User: [GRAY_AREA_EXAMPLE_1]
Assistant: [CORRECT_GRAY_AREA_RESPONSE_1]

### Example 4: Over-Refusal Example (Do Not Refuse)
User: [OVER_REFUSAL_EXAMPLE_1]
Assistant: [CORRECT_NON_REFUSAL_RESPONSE_1]

## ADDITIONAL CONSTRAINTS
[ADDITIONAL_CONSTRAINTS]

Adaptation guidance: Replace [ALLOWED_CATEGORIES] with a bullet list of request types your application must handle, such as 'code generation within the user's repository' or 'medical information summarization from provided documents.' Replace [DISALLOWED_CATEGORIES] with specific prohibited categories like 'generation of malicious code,' 'creation of deceptive content,' or 'unauthorized data extraction.' The [GRAY_AREA_CATEGORIES_WITH_RULES] placeholder is critical for requests that require nuanced handling—for example, 'financial advice requests: provide educational information only, do not make specific investment recommendations.' The refusal language block uses a structured format that your application can parse to log refusal events, trigger human review, or surface safe alternatives to users. The over-refusal prevention section and examples are essential for preventing Claude from becoming overly cautious and refusing benign requests that share vocabulary with disallowed categories. Test this prompt with both boundary-pushing disallowed requests and benign requests that could trigger false positives before deploying to production.

This prompt is not a one-off experiment; it is a calibration instrument that should be embedded in a structured evaluation harness before any production use. The harness must treat each test case as a discrete inference call, capture the full response payload (including refusal signals, safe alternatives, and reasoning), and log structured metadata: the test case ID, the risk level assigned, the model version, the prompt template version, and the timestamp. Because refusal behavior is sensitive to small changes in wording, the harness should pin the exact prompt template and model version for each calibration run. Any change to the system prompt, the refusal taxonomy, or the model snapshot requires a full re-run of the test suite to detect regression in either over-refusal (blocking legitimate requests) or under-refusal (permitting disallowed requests).

Validation logic must go beyond simple string matching for refusal keywords. Parse each response into a structured record containing at minimum: a decision field (allow, refuse, redirect), a refusal_reason field drawn from the defined taxonomy, a safe_alternative field if the decision is redirect, and a confidence indicator if the model expresses uncertainty. Implement a post-processing validator that checks: (1) the decision value is one of the allowed enum members, (2) a refuse decision always includes a non-empty refusal_reason, (3) a redirect decision always includes a non-empty safe_alternative, and (4) the response does not contain the disallowed request content echoed back in a way that could constitute compliance. For high-risk domains, route any response where the validator cannot confidently parse the decision to a human review queue. Log validation failures separately from model refusals so you can distinguish model behavior problems from parsing problems.

Production monitoring for this prompt requires two distinct dashboards. The first tracks refusal rates segmented by risk level and request category to detect drift: a sudden drop in refusal rate for high-risk inputs may indicate prompt injection or model behavior change, while a spike in refusal rate for low-risk inputs signals over-refusal that will degrade user experience. The second dashboard tracks the quality of safe alternatives by sampling redirect responses and having domain experts rate whether the alternative is genuinely helpful, irrelevant, or inadvertently dangerous. Set alert thresholds on both dashboards. When the harness detects a regression, do not hand-edit the prompt in production. Return to the calibration test suite, identify which test cases broke, adjust the prompt template or the refusal taxonomy, re-run the full suite, and only promote the new version after all test cases pass. Treat this prompt like a safety-critical configuration file, not a casual text string.