Refusal Tone Selection Prompt Template

This prompt is for product teams, safety engineers, and conversation designers who need to select a consistent refusal tone for an AI product before writing individual refusal messages. The job-to-be-done is not generating a single refusal, but producing a reusable tone profile—a set of stylistic rules, vocabulary constraints, and behavioral guidelines—that downstream prompts and human reviewers can apply across every refusal surface in the product. The ideal user is someone who owns the refusal experience for a feature or platform and needs a documented, testable tone decision rather than an ad-hoc style guess.

Use this prompt when you are designing a new AI product surface, adding refusal handling to an existing assistant, or auditing an inconsistent refusal experience that generates user complaints or escalation tickets. It is appropriate when you have clarity on your product context (e.g., consumer chat, enterprise compliance dashboard, clinical summarization tool), your user relationship (transactional, ongoing trusted advisor, regulated professional), and your risk tolerance. The prompt requires you to supply these inputs explicitly, along with examples of disallowed request categories the system will face. Do not use this prompt for generating individual refusal messages—use one of the tone-specific refusal templates (empathetic, firm, neutral, educational) after this prompt has produced the tone profile. Do not use it when you lack product context or when the refusal tone is already locked in a style guide; this is a design-time decision tool, not a runtime generation tool.

The output is a structured tone profile, not a single refusal string. Expect fields like tone_name, style_directives, vocabulary_constraints, example_refusal_snippets, and evaluation_criteria. Wire this profile into your system prompt, refusal generation templates, and human review rubrics. Before shipping, test the profile against a golden set of disallowed requests and measure whether downstream refusals consistently match the intended tone. Common failure modes include producing a profile that sounds reasonable but generates refusals that users perceive as evasive, robotic, or judgmental. If the profile will govern refusals in regulated domains, include a legal or compliance reviewer in the approval loop before locking the tone.

This template is the core instruction set for producing a refusal tone profile. It takes structured inputs about your product, user base, and risk tolerance and outputs a concrete tone specification that downstream prompts can reference. The template is designed to be copied directly into your prompt management system, with square-bracket placeholders replaced by your application's configuration values at runtime. Do not treat this as a one-time design exercise—store the output as a reusable tone profile that your refusal prompts, escalation prompts, and safe-alternative prompts all reference for consistency.

textCopy
You are a refusal tone designer for AI product teams. Your job is to produce a concrete, implementable tone profile that downstream refusal prompts will follow.

## INPUTS
- Product Context: [PRODUCT_CONTEXT]
- Primary User Base: [USER_BASE_DESCRIPTION]
- User Relationship Type: [RELATIONSHIP_TYPE]  // e.g., consumer, enterprise, patient, student, developer
- Risk Level: [RISK_LEVEL]  // low, medium, high, regulated
- Brand Voice Guidelines (if any): [BRAND_VOICE]
- Regulatory Requirements (if any): [REGULATORY_REQUIREMENTS]
- Refusal Scenarios to Cover: [REFUSAL_SCENARIOS]  // e.g., harmful content, out-of-scope, gated feature, legal boundary

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "tone_profile": {
    "primary_style": "empathetic" | "firm" | "neutral" | "educational" | "custom",
    "style_rationale": "string explaining why this style fits the product context and risk level",
    "voice_attributes": {
      "directness": "low" | "medium" | "high",
      "formality": "low" | "medium" | "high",
      "warmth": "low" | "medium" | "high",
      "authority": "low" | "medium" | "high"
    },
    "refusal_structure": {
      "acknowledgment_required": true | false,
      "boundary_statement_required": true | false,
      "policy_citation_required": true | false,
      "alternative_offering_required": true | false,
      "escalation_path_required": true | false
    },
    "language_constraints": [
      "list of specific phrases to avoid",
      "list of required disclaimers"
    ],
    "example_refusal": "A sample refusal in the recommended tone for the most common scenario",
    "anti_patterns": [
      "list of tone patterns that would undermine trust or compliance"
    ]
  },
  "evaluation_criteria": {
    "trust_preservation_indicators": ["list of signals that the refusal maintains user trust"],
    "escalation_risk_factors": ["list of tone choices that could increase escalation or support tickets"],
    "compliance_checks": ["list of regulatory or policy requirements the tone must satisfy"]
  },
  "implementation_notes": {
    "consistency_requirements": "How this tone should be applied across surfaces (chat, API, voice)",
    "override_scenarios": ["Situations where the primary tone should be overridden"],
    "cultural_adaptation_notes": "Any locale-specific adjustments needed"
  }
}

## CONSTRAINTS
- Do not recommend a tone that contradicts the stated risk level or regulatory requirements.
- If the risk level is "high" or "regulated," prioritize clarity and compliance over warmth.
- If the user relationship is "enterprise" or "patient," avoid language that could be interpreted as legal or medical advice.
- Every tone recommendation must be defensible with a rationale tied to the inputs.
- Do not produce generic advice. Every field must reference specific details from the provided inputs.

To adapt this template, replace each placeholder with data from your application's configuration layer. [PRODUCT_CONTEXT] should describe what your product does and the relationship users have with it—for example, "a telehealth platform connecting patients with licensed providers" or "a developer tool for infrastructure-as-code generation." [REFUSAL_SCENARIOS] should list the concrete situations where your system must refuse, such as "requests for medical dosage without provider review" or "generation of production database credentials." The output JSON becomes a reference document that your refusal prompt templates consume as a [TONE_PROFILE] input, ensuring every refusal across your product surfaces follows the same voice attributes, structure, and language constraints.

Before deploying the generated tone profile, validate it against your actual refusal scenarios. Run the example refusal through your safety review process and check whether the evaluation_criteria are measurable in your observability stack. If your product operates in multiple locales, generate a separate profile for each market using locale-specific [USER_BASE_DESCRIPTION] and [BRAND_VOICE] inputs, then run the Refusal Tone Cultural Sensitivity Adjustment Prompt against each variant. Store the profile as a versioned artifact in your prompt registry so that refusal prompt updates can reference a specific tone profile version and regressions can be traced.

This prompt is designed to be called programmatically as part of a product configuration or safety policy setup workflow, not as a real-time user-facing endpoint. It should be triggered when a product team is defining or updating the refusal experience for a new feature, surface, or user segment. The primary integration point is a configuration service or admin panel where product managers or safety engineers input the product context, user relationship, and risk level. The output—a tone profile with rationale, example language, and evaluation criteria—should be stored as a structured configuration object that downstream refusal prompts reference at runtime.

Integration pattern: Wrap the prompt in a service function that accepts [PRODUCT_CONTEXT], [USER_RELATIONSHIP], [RISK_LEVEL], and [BRAND_VOICE_GUIDELINES] as structured inputs. Validate inputs before calling the model: [RISK_LEVEL] must be one of low, medium, high, or critical; [USER_RELATIONSHIP] must be one of consumer, enterprise, regulated-professional, or public; and [PRODUCT_CONTEXT] must be a non-empty string under 500 characters. Reject malformed inputs before incurring model cost. On the output side, parse the JSON response and validate that all required fields are present: primary_tone, tone_attributes, example_refusal_phrasing, evaluation_criteria, and trade_off_notes. If parsing fails or required fields are missing, retry once with a repair prompt that includes the raw output and the expected schema. After two failures, escalate to a human reviewer through your configuration review queue.

Model selection and latency: This is a low-frequency, high-judgment configuration task. Use a capable model with strong instruction-following and structured output support, such as gpt-4o or claude-3.5-sonnet. Latency is not critical since this runs during setup, not during user requests. Set temperature to 0.3 to balance creativity in tone suggestions with consistency across runs. Enable structured output mode if your provider supports it, passing the expected JSON schema directly rather than relying on prompt-based format instructions alone. Logging and audit: Log every invocation with the input parameters, model version, raw output, parsed tone profile, and validation result. This audit trail is essential when refusal tone decisions are reviewed during safety policy audits or incident postmortems. Store logs in your prompt observability system with the tag refusal-tone-selection for traceability.

Human review gate: The generated tone profile should not be deployed directly to production without review. Route the output to a human approval step where a product manager or safety engineer confirms the tone selection, edits example phrasing if needed, and signs off on the evaluation criteria. Only after approval should the profile be written to the configuration store that downstream refusal prompts consume. Downstream wiring: The approved tone profile becomes an input to runtime refusal prompts. Pass primary_tone and tone_attributes into the system prompt of your refusal generation prompt as [REFUSAL_TONE] and [TONE_ATTRIBUTES]. Use example_refusal_phrasing as few-shot examples in the refusal prompt. Embed evaluation_criteria into your LLM-as-judge eval harness to automatically score refusal outputs for tone adherence. This creates a closed loop: the selection prompt defines the tone contract, runtime prompts execute it, and evals verify compliance.