Helpfulness-Retention Refusal Prompt for Partial Denials

This prompt is designed for AI assistant products that must refuse a core disallowed request while preserving user trust by immediately pivoting to permissible, adjacent help. It is not a blanket refusal prompt. Use it when the user's input contains a mix of allowed and disallowed components, or when the disallowed request signals an underlying need that can be met through a safe alternative. The ideal user is a product team or safety engineer who already has a defined safety policy and a classification step that identifies which parts of a request are disallowed. The prompt assumes you can pass in the original user input, a structured breakdown of allowed vs. disallowed components, and your organization's policy language.

This prompt is the wrong tool when the entire request is disallowed with no permissible adjacent need, when you need a firm compliance refusal with no redirection, or when the user is actively attempting a jailbreak. In those cases, use a direct refusal prompt, a firm compliance template, or an injection defense prompt instead. You should also avoid this prompt when the classification of allowed vs. disallowed components is uncertain or when the permissible alternative would require capabilities your system does not have. The prompt works best when the refusal is partial and the pivot to help is genuine, not forced.

Before deploying this prompt, ensure you have a reliable classification step upstream. The prompt's effectiveness depends on accurate identification of which sub-requests are disallowed and which are safe to fulfill. If your classifier produces noisy boundaries, users will experience inconsistent refusals that erode trust. Wire the classifier output into the [DISALLOWED_COMPONENTS] and [ALLOWED_COMPONENTS] placeholders, and test the full pipeline against edge cases where the boundary is genuinely ambiguous. When in doubt, bias toward refusal with a clear explanation rather than attempting to fulfill a borderline request.

This template is designed for AI assistants that must handle partial denials—scenarios where a user's request contains both a disallowed component and a permissible component. Instead of a blanket refusal that frustrates the user, the prompt instructs the model to clearly refuse the disallowed part, cite the applicable policy, and immediately pivot to providing substantive help on the allowed part or a safe adjacent alternative. The output is a structured JSON object that can be parsed by an application layer for logging, auditing, and user-facing rendering.

textCopy
You are a helpful assistant. Your response must follow a strict structure: first, clearly refuse the disallowed component of the user's request, citing the specific policy. Then, immediately pivot to offering help with the allowed component or a safe adjacent alternative. Do not repeat the disallowed request verbatim. Do not provide instructions, workarounds, or justifications that could enable the disallowed behavior. Maintain a tone that is [TONE: empathetic and constructive, not apologetic or evasive].

User request: [USER_REQUEST]

Disallowed component: [DISALLOWED_COMPONENT]
Applicable policy: [POLICY_NAME]
Allowed component: [ALLOWED_COMPONENT]
Safe adjacent alternatives you can offer: [SAFE_ALTERNATIVES]

Your response must be a single JSON object with the following fields:
- "refusal_statement": A brief, clear refusal of the disallowed component, citing the policy.
- "pivot_statement": A sentence that transitions to the allowed help.
- "helpful_response": The substantive, helpful response to the allowed component or safe alternative.
- "helpfulness_score": A self-assessment from 1 to 5 of how well the response preserves a helpful posture (5 = fully addresses the permissible need, 1 = no helpful pivot).

Do not include any text outside the JSON object.

To adapt this template for your application, replace the square-bracket placeholders with values populated by your upstream safety classifier or policy engine. [USER_REQUEST] should contain the full user input. [DISALLOWED_COMPONENT] and [ALLOWED_COMPONENT] should be extracted by a classification step before this prompt runs—do not rely on the model to perform both classification and refusal in a single pass for high-risk domains. [POLICY_NAME] should reference a specific, auditable policy identifier from your governance system. [SAFE_ALTERNATIVES] should be a short list of permissible adjacent topics your system can actually handle. The [TONE] placeholder can be set to values like "empathetic and constructive," "neutral and procedural," or "firm and unambiguous" depending on your product's refusal style guidelines.

Before deploying, validate the JSON output against a schema in your application layer. Reject responses that contain text outside the JSON object, that repeat the disallowed request verbatim, or that produce a helpfulness_score below your configured threshold. For regulated domains, route responses with low helpfulness scores or ambiguous refusal language to a human review queue. Log the full JSON payload, including the self-assessed score, to monitor refusal quality and helpfulness retention over time. If the model produces a refusal without a meaningful pivot, treat it as a partial failure and consider retrying with a more explicit [SAFE_ALTERNATIVES] list or escalating to a fallback response.

Avoid using this template for requests where the entire input is disallowed with no permissible component to extract. In those cases, a simpler refusal prompt without the pivot structure is more appropriate and less likely to produce hallucinated helpful responses. Also avoid this template when the disallowed component is so entangled with the allowed component that separating them would require the model to restate or analyze the harmful content—those cases should be escalated to human review. Next, wire this prompt into an implementation harness that validates the output schema, checks the helpfulness score, and logs refusals for policy audit trails.

This prompt is designed to sit downstream of a safety classifier that has already identified the disallowed and allowed components of a user request. The classifier output feeds directly into the [DISALLOWED_COMPONENT] and [ALLOWED_COMPONENT] variables. Do not invoke this prompt unless the classifier has produced a structured breakdown. If the classifier confidence falls below your configured threshold, route the entire request to a human review queue instead of attempting a partial refusal. This gating step prevents the model from hallucinating policy boundaries on ambiguous inputs.

Parse the model's JSON output and validate it against the expected schema before surfacing any response to the user. The schema should require at minimum: refusal_statement (string), policy_name (string), helpful_continuation (string), and helpfulness_score (float 0-1). If the JSON is malformed or missing required fields, retry once with a stricter format instruction appended to the prompt—such as 'You must respond with valid JSON only. No explanatory text outside the JSON object.' If the retry also fails, log the failure and fall back to a static refusal message. Never show raw model output to the user.

Log the refusal_statement, policy_name, and helpfulness_score to your safety monitoring dashboard on every invocation. These fields enable trend analysis: rising helpfulness scores may indicate the model is getting too permissive, while consistently low scores signal user frustration. For multi-turn conversations, include the last two assistant messages in the prompt context to maintain refusal consistency across turns. Without this context, the model may contradict its own prior refusals, creating a jailbreak vector. For voice or multimodal surfaces, adapt the output contract to include spoken-word phrasing and remove JSON formatting entirely—the refusal should sound natural when read aloud, not like a structured data payload.