Refusal Tone Style Selection Prompt for Product Teams

This prompt is a design-phase decision tool for product teams, safety engineers, and policy owners who need to align on a refusal voice before writing a single line of runtime refusal text. Its job is to take your product context, user expectations, and risk profile as structured inputs and return a recommended tone style—such as empathetic, firm, neutral, or educational—with a clear rationale and trade-off analysis. The ideal user is a product manager or safety lead facilitating a cross-functional decision with engineering, design, legal, and trust-and-safety stakeholders. You should use this prompt when you are defining safety guidelines for a new product surface, updating refusal behavior after a policy change, or resolving a disagreement about how the system should sound when it says no.

The prompt requires concrete inputs to produce a useful recommendation. You must provide a description of the product and its primary use case, the expected user base and their relationship to the product, the types of requests that will be refused, the risk level of an incorrect or overly permissive response, and any existing brand voice or tone guidelines. The output is not a refusal template. It is a tone profile that downstream prompts—such as the Empathetic Refusal Prompt Template for Consumer Apps or the Firm Refusal Prompt Template for Enterprise Compliance—will implement. This separation ensures that the tone decision is documented, reviewable, and consistent across all refusal surfaces before implementation begins.

Do not use this prompt when you need an immediate runtime refusal for a specific user request. It is not designed to generate refusal text, handle multi-turn conversation state, or evaluate the safety of a particular input. For those needs, use the runtime refusal prompts in this pillar. Also avoid this prompt when the refusal tone is already locked by a regulatory requirement that leaves no room for stylistic choice—for example, a legally mandated disclosure that must appear verbatim. In that case, skip the tone selection step and proceed directly to the compliance refusal template. After running this prompt, the next step is to document the chosen tone style in your safety guidelines and feed it as a [TONE_PROFILE] input into your refusal generation prompts.

This prompt is designed for product managers and safety engineers who need to define a consistent refusal voice for their AI system. Instead of guessing which tone will preserve trust and minimize escalation, you provide structured product context and the prompt returns a recommended style with rationale, trade-offs, and implementation considerations. The output is meant to be a decision-support artifact, not a final policy document, so always review the recommendation against your organization's specific legal and brand requirements before adopting it.

textCopy
You are a refusal tone design advisor for production AI systems. Your task is to recommend a primary refusal tone style for an AI product based on its context, user base, and risk profile. You will analyze the inputs and return a structured recommendation with rationale and trade-off analysis.

## INPUTS
- Product Description: [PRODUCT_DESCRIPTION]
- Primary User Base: [USER_BASE]
- Risk Profile (Low, Medium, High, Critical): [RISK_PROFILE]
- Regulatory Context (if any): [REGULATORY_CONTEXT]
- Brand Voice Guidelines (if any): [BRAND_VOICE_GUIDELINES]
- Example Disallowed Request: [EXAMPLE_DISALLOWED_REQUEST]

## REFUSAL TONE STYLES
Consider these primary styles:
- **Empathetic**: Acknowledges user intent, explains the boundary with care, and offers constructive redirection. Best for consumer apps where user trust and retention are paramount.
- **Firm**: Unambiguous, policy-citing, and procedurally correct. Best for enterprise compliance and regulated environments where ambiguity creates liability.
- **Neutral**: Flat-affect, factual, and avoids implying endorsement or interpretation. Best for legal, financial, and healthcare contexts where tone must not be construed as advice.
- **Educational**: Transforms the refusal into a teaching moment, explaining why the request cannot be fulfilled and pointing to legitimate resources. Best for edtech and information platforms.
- **Direct**: Brief, no-ambiguity refusal without softening language. Best for clear policy violations where any softening could be interpreted as negotiable.

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "recommended_style": "string (one of the styles above)",
  "confidence": "string (High, Medium, Low)",
  "rationale": "string (2-3 sentences explaining why this style fits the product context)",
  "trade_offs": [
    {
      "risk": "string (what could go wrong with this style)",
      "mitigation": "string (how to reduce that risk)"
    }
  ],
  "example_refusal": "string (a sample refusal for the provided disallowed request using the recommended style)",
  "implementation_notes": [
    "string (concrete guidance for prompt engineers implementing this tone)"
  ],
  "escalation_triggers": [
    "string (conditions where the system should escalate to human review instead of refusing)"
  ]
}

## CONSTRAINTS
- Do not recommend a style that contradicts the regulatory context.
- For high-risk or critical-risk profiles, always include escalation triggers.
- If the brand voice guidelines conflict with the risk-appropriate tone, flag the conflict in implementation notes.
- The example refusal must be production-ready and directly usable as a template.
- If confidence is Low, explain what additional information would increase it.

To adapt this prompt, replace each square-bracket placeholder with your product's actual context. The [EXAMPLE_DISALLOWED_REQUEST] is critical: it grounds the recommendation in a concrete scenario and produces a sample refusal you can immediately evaluate. If your product spans multiple user bases or risk levels, run the prompt separately for each segment and compare the recommendations. For high-stakes domains, always have legal and policy reviewers validate the recommended tone and example refusal before implementation. After you have a recommended style, use the sibling refusal tone templates in this pillar to generate production-ready refusal prompts in that style.

The refusal tone style selection prompt is designed as a decision-support tool for product teams, not a runtime component. It should be integrated into the product design phase—typically during safety policy definition, UX review, or pre-launch readiness checks—rather than called per user request. The prompt consumes structured product context and outputs a recommended tone profile with rationale and trade-off analysis. This output should be treated as a design artifact that informs system prompt construction, refusal template authoring, and evaluation rubric design.

Integration pattern. Call this prompt once per product surface or user segment, not per session. Provide the full product context payload: [PRODUCT_TYPE], [USER_BASE_DESCRIPTION], [RISK_PROFILE], [REGULATORY_DOMAIN], [BRAND_VOICE_GUIDELINES], and [EXISTING_REFUSAL_EXAMPLES]. The model returns a structured tone recommendation. Validate the output against a schema that requires: a primary tone label from a closed enum (empathetic, firm, neutral, educational, direct, de-escalation, apologetic, humorous), a rationale paragraph, a trade-off analysis covering at least trust impact and escalation risk, and implementation notes. If the output fails schema validation, retry once with the validation errors injected into the prompt as [CONSTRAINTS]. After two failures, flag for human review rather than auto-accepting a malformed recommendation.

Model selection and cost. This is a low-frequency, high-judgment task. Use a capable model with strong reasoning and instruction-following (GPT-4o, Claude 3.5 Sonnet, or equivalent). Latency is not critical; correctness and nuance are. Do not use a small or quantized model for this prompt—tone recommendations require understanding of brand voice, user psychology, and regulatory context that smaller models handle unreliably. Cache the output as a design document in your prompt registry or policy repository with a version identifier and the input context that produced it.

Validation and evals. Before adopting the recommended tone, run it through a lightweight eval harness. Generate 10–15 representative refusal scenarios for your product domain and apply the recommended tone style to each. Have at least two reviewers (product, safety, or legal) score the outputs on: policy compliance (pass/fail), tone consistency with the recommendation (1–5), and user trust preservation (1–5). If inter-rater agreement drops below 0.7 or any scenario fails policy compliance, revisit the tone recommendation with additional context or constraints. Do not ship a refusal tone that hasn't passed scenario-based review.

What to avoid. Do not treat the model's recommendation as final policy without human review, especially in regulated domains. Do not feed this prompt live user data or PII—it operates on product-level abstractions, not individual requests. Do not use the output to auto-generate system prompts without manual inspection; the recommendation is a design input, not a deployable artifact. If your product serves multiple distinct user segments with different risk profiles, run the prompt separately for each segment rather than averaging recommendations into a single compromise tone that satisfies no one.