User Trust Preservation Refusal Prompt Template

This prompt template is for product designers and safety engineers who need an AI system to refuse a disallowed or unsafe request while actively preserving the user relationship. Use it when a blunt refusal would damage trust, increase escalation rates, or cause user churn. The template structures the refusal into three deliberate moves: acknowledge the user's underlying intent without endorsing the disallowed action, explain the boundary clearly and without moralizing, and offer a constructive path forward within policy limits.

This is not a prompt for detecting unsafe requests. It assumes an upstream classifier or policy engine has already determined that a refusal is required and has provided the policy reference and risk level. The prompt is designed to be inserted into a system message or as a structured instruction block within a larger agent or chat pipeline. Do not use this template when the upstream classification is uncertain, when the user has not yet been informed of the policy, or when the request is ambiguous enough to warrant clarification rather than refusal. In those cases, use a clarification or escalation prompt instead.

Before deploying this prompt, ensure your pipeline provides the required inputs: the original user request, the specific policy being invoked, the risk level, and any allowed alternatives. Without these inputs, the refusal will sound generic and erode trust rather than preserve it. Pair this prompt with a refusal tone selection step if your product supports multiple tones (empathetic, firm, neutral, educational) based on user context. After implementation, evaluate outputs using trust preservation metrics such as user sentiment trajectory, escalation rate, and session continuation rate rather than relying solely on policy compliance checks.

This template is designed to be pasted directly into your system prompt or used as a structured instruction block within your application's prompt assembly pipeline. It instructs the model to refuse disallowed requests in a way that explicitly acknowledges the user's underlying intent, explains the boundary without moralizing or judging the user, and preserves a helpful posture by offering permissible alternatives where possible. The template uses square-bracket placeholders that you must replace with your specific policy definitions, product context, and output requirements before deployment.

textCopy
You are an assistant that prioritizes long-term user trust. When you must refuse a request, follow these rules in order:

1. ACKNOWLEDGE the user's underlying goal or intent in one sentence. Show you understood what they were trying to accomplish. Do not repeat the disallowed request verbatim if it contains harmful content.

2. EXPLAIN the boundary clearly and without judgment. Reference the specific policy category from [POLICY_CATEGORIES] that applies. Use neutral, factual language. Never imply the user is bad, wrong, or malicious for asking.

3. OFFER a constructive path forward when one exists within policy. This can be a permissible alternative approach, a related task you can help with, or information about what would need to change for the request to become allowable. If no alternative exists, state that clearly without false hope.

4. MAINTAIN helpfulness posture. End with an open question or offer related to the user's broader goal, signaling you remain available for permissible assistance.

POLICY_CATEGORIES: [POLICY_CATEGORIES]

REFUSAL TONE PARAMETERS:
- Empathy level: [EMPATHY_LEVEL] (low/medium/high)
- Directness: [DIRECTNESS] (firm/balanced/gentle)
- Maximum refusal length: [MAX_LENGTH] sentences

OUTPUT FORMAT:
Return only the refusal response. Do not include meta-commentary, labels, or explanations about the refusal itself.

EXAMPLES:
[REFUSAL_EXAMPLES]

CONSTRAINTS:
- Never use sarcasm, passive-aggressive language, or moralizing tone.
- Never imply the policy is negotiable or that you wish you could help.
- Never repeat disallowed content verbatim in your acknowledgment.
- If the request involves [HIGH_RISK_DOMAINS], append: "If you believe this refusal was made in error, [ESCALATION_PATH]."

To adapt this template, start by defining your [POLICY_CATEGORIES] as a structured list of named boundaries (e.g., "Content Generation Restrictions," "Personal Advice Limitations," "Regulated Activity Boundaries"). Each category should map to a specific, auditable policy document. The [REFUSAL_EXAMPLES] placeholder is critical for model behavior: provide 2-4 few-shot examples showing the full acknowledgment-explain-offer pattern for your most common refusal scenarios. Include at least one example where no alternative exists and one where a partial alternative is offered. Set [EMPATHY_LEVEL] and [DIRECTNESS] based on your product's voice guidelines and the risk context of the deployment surface. For high-risk domains such as healthcare, legal, or financial contexts, populate [HIGH_RISK_DOMAINS] with the specific categories that require escalation language, and define [ESCALATION_PATH] as a concrete instruction (e.g., "contact your administrator at support@example.com" or "use the /review command to request human evaluation"). Test the adapted prompt against a golden set of disallowed requests and verify that outputs consistently follow the four-step pattern without drifting into over-refusal on benign adjacent requests.

The User Trust Preservation Refusal Prompt is designed to sit behind a safety classifier, not as the first line of defense. In a production harness, the application should first run the user input through a dedicated unsafe-request detection step. Only inputs that are classified as disallowed—and where the product policy requires a refusal rather than a silent drop or redirect—should reach this prompt. The prompt itself expects the original user request, the specific policy that was violated, and any relevant session context. Wire these as structured inputs, not as free-text concatenation, to avoid prompt injection through the policy description field.

Model choice matters for trust preservation. Use a model with strong instruction-following and tone control (e.g., Claude 3.5 Sonnet or GPT-4o) rather than a smaller, less steerable model. Set temperature between 0.2 and 0.4—low enough to avoid creative rewording that introduces ambiguity, high enough to produce natural acknowledgment language. Implement a validation layer after the model responds: check that the output contains no policy loophole language (e.g., 'I can't do that right now'), no judgmental framing, and no fabricated policy citations. A regex scan for phrases like 'as an AI' or 'I apologize, but' can flag outputs that drift into generic refusal territory. For high-stakes domains, route outputs scoring below a trust-preservation threshold to a human review queue before returning to the user.

Log every refusal with the input classification, the policy ID triggered, the raw prompt, the model response, and the validation result. This audit trail is essential for over-refusal calibration and for defending refusal decisions to compliance reviewers. Avoid logging the full user input if it contains sensitive or disallowed content—instead, log a content hash and the classification label. For multi-turn conversations, pass the refusal turn and the user's next message back through the safety classifier before deciding whether to continue the refusal posture or resume normal interaction. The most common production failure mode is a user rephrasing the request in a way that bypasses the classifier but still violates policy intent; session-level risk scoring mitigates this.