Refusal Recovery with Partial Fulfillment Prompt

This prompt is for production AI systems that must handle requests where only a portion triggers a safety or policy boundary. Instead of refusing the entire request and frustrating the user, the system should fulfill the safe components while clearly marking and explaining the refused portion. The ideal user is a safety engineer, product manager, or AI reliability engineer who needs to improve user experience without weakening genuine safety constraints. The required context includes the original user request, the specific safety policy that was triggered, and a clear demarcation of which parts of the request are safe versus unsafe.

Do not use this prompt when the entire request is unsafe and partial fulfillment would leak harmful content through context or implication. It is also inappropriate when the safe and unsafe components are so intertwined that separating them distorts the original intent or creates a misleadingly helpful response. This prompt assumes you already have a reliable mechanism for classifying which parts of a request are safe; it does not replace that classification step. In regulated domains such as healthcare or legal, partial fulfillment must still meet evidence-grounding and human-review requirements for the fulfilled portions.

Before implementing this prompt, ensure your safety classifier can segment requests at the appropriate granularity. If your classifier only provides a binary safe/unsafe label for the entire request, you will need to add segmentation capability first. The prompt works best when paired with structured refusal logging so you can measure whether partial fulfillment reduces user re-request rates and false-positive escalations. Start with a shadow evaluation pipeline that compares partial-fulfillment responses against full-refusal baselines before routing real user traffic.

This prompt template implements refusal recovery with partial fulfillment. When a model initially refuses an entire request that contains both safe and unsafe components, this prompt instructs the model to re-evaluate the request, fulfill the safe portions completely, and refuse only the specific unsafe component with a clear reason. The template is designed for production systems where blanket refusals degrade user experience and partial fulfillment preserves helpfulness without weakening safety boundaries.

textCopy
You are a helpful assistant with safety policies that sometimes require refusing parts of a request. Your task is to re-evaluate a request that was initially refused and produce a partial fulfillment response.

## Original Request
[ORIGINAL_REQUEST]

## Initial Refusal Reason
[REFUSAL_REASON]

## Safety Policy Reference
[POLICY_REFERENCE]

## Instructions
1. Identify which components of the original request are safe to fulfill and which are unsafe.
2. Fulfill all safe components completely and helpfully. Do not degrade the quality of safe portions.
3. For each unsafe component, clearly mark the refusal with:
   - The specific component being refused
   - The policy reason for refusal
   - A brief explanation the user can understand
4. Maintain overall helpfulness. The user should feel assisted, not blocked.
5. Do not fulfill, hint at, or provide workarounds for any refused component.
6. If the entire request is unsafe, refuse completely with explanation. Do not fabricate safe portions.

## Output Format
[OUTPUT_SCHEMA]

## Constraints
[CONSTRAINTS]

## Examples
[EXAMPLES]

## Risk Level
[RISK_LEVEL]

Adaptation guidance: Replace [ORIGINAL_REQUEST] with the exact user request that triggered the initial refusal. Populate [REFUSAL_REASON] with the model's original refusal text or a structured refusal code. [POLICY_REFERENCE] should cite the specific safety policy that was applied, enabling the model to distinguish between correctly and incorrectly refused components. [OUTPUT_SCHEMA] should define the expected response structure—consider a JSON schema with fields for fulfilled_portions, refused_portions, and overall_response. [CONSTRAINTS] can include length limits, tone requirements, or domain-specific rules. [EXAMPLES] should provide at least one few-shot example showing a request with both safe and unsafe components and the correct partial fulfillment output. [RISK_LEVEL] should be set to high for regulated domains, triggering downstream human review of the partial fulfillment before it reaches the user.

Critical safety check: Before deploying this prompt, validate that partial fulfillment does not leak unsafe content through the fulfilled portions. For example, if a user asks for both a legitimate code review and an exploit script, fulfilling the code review must not inadvertently provide exploit-relevant information. Test with adversarial examples where the safe and unsafe components are semantically adjacent. Implement a post-generation validator that checks refused portions against the original request to confirm the refusal boundary is correctly drawn. For high-risk domains, route all partial fulfillments through human review until the boundary proves reliable in production.

Integrating a partial-fulfillment refusal recovery prompt into a production system requires treating it as a controlled safety-recovery path, not a generic retry. The harness must intercept a model's initial refusal, classify whether partial fulfillment is appropriate, inject the recovery prompt with the original request and refusal context, and then validate that the resulting response satisfies both the safe portions of the request and the refusal boundary for the unsafe portion. This prompt is not suitable for cases where the entire request is unsafe or where partial fulfillment would leak sensitive context—those scenarios should route to a full-refusal or escalation path instead.

The implementation should follow a structured pipeline: (1) A refusal detector classifies the initial model response as a refusal and extracts the reason. (2) A partial-fulfillment gate checks whether the request can be decomposed—if the refusal reason applies to the entire request, bypass this prompt and escalate. (3) The recovery prompt is assembled with [ORIGINAL_REQUEST], [REFUSAL_REASON], [SAFETY_POLICY], and [OUTPUT_SCHEMA] placeholders populated from the current session. (4) The model's recovery response is parsed to extract safe_response and refused_portion fields. (5) A safety validator checks that the refused portion does not appear in the safe response, that the refusal reason is consistent with the policy, and that no new unsafe content was introduced. (6) If validation fails, increment a retry counter (maximum 2 recovery attempts) and re-invoke with the validation error appended as [CORRECTION_FEEDBACK]. After the retry budget is exhausted, escalate to a human reviewer with the full attempt history. Log every recovery attempt with the original request, refusal reason, recovery response, and validation result for audit and policy improvement.

Model choice matters here: use a model with strong instruction-following and safety boundary awareness, such as Claude 3.5 Sonnet or GPT-4o, because weaker models may either refuse the recovery prompt itself or fail to maintain the separation between safe and unsafe content. Set temperature low (0.0–0.2) to reduce variance in safety-critical recovery. The output schema should be strict—require a JSON object with safe_response (string), refused_portion (object with content and reason), and recovery_confidence (0–1 float). Validate the schema before surfacing any content to the user. Never bypass the safety validator, even if the model expresses high confidence, because partial fulfillment creates a vector where an overly helpful model might accidentally include refused content in the safe portion. For high-risk domains such as healthcare or finance, always require human review of the recovery response before it reaches the end user.