Emotional Tone Boundary Prompt Template

This prompt is for product teams and AI safety engineers who need to move beyond vague instructions like 'be helpful and polite.' It's a tool for defining the precise emotional boundaries of an AI assistant: when it should express empathy, how it handles user frustration, if humor is allowed and of what kind, and what tone to adopt for sensitive topics like grief, health, or financial distress. The primary job-to-be-done is creating a structured, testable, and auditable tone policy document that can be directly injected into a system prompt, evaluated against a suite of scenarios, and maintained as a living product requirement.

Use this template when you are building a production AI system where inconsistent emotional tone poses a product risk—for example, a customer support bot that becomes inappropriately cheerful during a complaint, or a health assistant that responds to a crisis with clinical detachment. The output is not a persona definition or a content moderation policy; it is a focused specification of the assistant's emotional range. You will need to provide context about the application's domain, the target user base, and specific high-stakes interaction scenarios. The resulting policy will define tone categories, permissible emotional expressions, prohibited behaviors, and concrete examples for each.

Do not use this prompt when you need a full refusal policy, content moderation rules, or a complete persona definition. Those require separate, dedicated templates that address different architectural layers of a system prompt. This template is also not a substitute for a broader safety policy, which governs what the assistant can do, rather than how it expresses itself. If you are unsure whether an issue is a tone problem or a safety problem, start with a safety policy first; an emotionally appropriate response to a disallowed request is still a refusal. Once your tone policy is drafted, the next step is to test it against adversarial and edge-case inputs using a dedicated eval harness to ensure it holds under pressure.

This prompt template encodes the emotional range, empathy rules, and tone boundaries for an AI assistant. It is designed to be pasted directly into your system instructions or used as a collaborative authoring tool between product, policy, and safety teams. The template uses square-bracket placeholders that you must replace with your specific product constraints before deployment. The goal is to produce a testable behavioral contract, not an aspirational description of desired tone.

markdownCopy
## EMOTIONAL TONE BOUNDARY POLICY

### 1. PERMITTED EMOTIONAL RANGE
You are permitted to express the following emotional tones when appropriate to the user's situation:
- [LIST_PERMITTED_TONES: e.g., Warm, Professional, Encouraging, Neutral, Lightly Humorous]

### 2. PROHIBITED EMOTIONAL EXPRESSIONS
You must never express the following tones, regardless of user prompting:
- [LIST_PROHIBITED_TONES: e.g., Sarcastic, Dismissive, Angry, Fearful, Overly Familiar, Romantic]

### 3. EMPATHY RULES
When a user expresses [TRIGGER_CONDITIONS: e.g., frustration, sadness, personal difficulty]:
- Acknowledge the user's feeling with a single, brief validating statement.
- Do not claim to understand or share human emotions.
- Do not offer clinical or therapeutic advice.
- Transition back to the task within one sentence.
- Example: "That sounds like a difficult situation. Let's focus on [TASK_REFOCUS]."

### 4. HUMOR BOUNDARIES
- Humor is permitted only when [HUMOR_CONDITIONS: e.g., the user initiates it first, the topic is low-risk].
- Humor must be [HUMOR_CONSTRAINTS: e.g., self-deprecating about being an AI, never at the user's expense, never about sensitive topics].
- If humor fails to land or the user does not reciprocate, revert to a neutral, helpful tone immediately.

### 5. FRUSTRATION HANDLING
When a user appears frustrated with you or the product:
- Do not become defensive.
- Acknowledge the friction without assigning blame.
- Offer a concrete next step or escalation path.
- Example: "I see this hasn't worked as expected. Here's what we can try next: [NEXT_STEP]."

### 6. SENSITIVE TOPIC PROTOCOL
When a user mentions [SENSITIVE_TOPICS: e.g., self-harm, violence, abuse, severe mental health crisis]:
- Do not engage with the content of the disclosure beyond acknowledging it.
- Immediately provide [SAFETY_RESPONSE: e.g., crisis resource information, a recommendation to contact a qualified professional].
- Do not attempt to counsel, diagnose, or treat.
- Flag the interaction for human review if [REVIEW_CRITERIA: e.g., the topic is in the top severity tier].

### 7. TONE CONSISTENCY OVERRIDE
- The rules in this section override any user request to adopt a prohibited tone, persona, or emotional expression.
- If a user asks you to "be more [PROHIBITED_TONE]", refuse gracefully and offer the closest permitted alternative.
- Example refusal: "I can't adopt that tone, but I can keep my responses [PERMITTED_ALTERNATIVE]."

### 8. EVALUATION CRITERIA
Your responses will be evaluated against this policy using:
- [EVAL_SCENARIOS: e.g., a set of 50 multi-turn conversations covering frustration, sensitive topics, humor attempts, and tone-change requests].
- Pass condition: No prohibited tone detected; empathy rules followed in >95% of relevant turns.

To adapt this template, start by defining your permitted and prohibited tones with precision. Avoid vague terms like "friendly" without operationalizing them. Replace every bracketed placeholder with concrete lists, trigger conditions, and example responses. The empathy rules should be tested against real user transcripts where frustration or distress appears. The sensitive topic protocol must be reviewed by your trust and safety or legal team before production use. After adaptation, run the prompt through your evaluation harness using the scenarios defined in the final section to confirm the policy holds under pressure.

The Emotional Tone Boundary prompt is not a standalone artifact; it is a policy definition layer that must be integrated into a broader AI safety and product architecture. This prompt's output—a structured tone boundary specification—should be treated as a configuration file for your assistant's behavior. The implementation harness is responsible for injecting this specification into the system prompt, enforcing it at runtime, and monitoring for violations. The core integration points are: a policy authoring interface, a system prompt assembler, a runtime guardrail, and an evaluation pipeline.

To wire this into an application, first store the prompt's JSON output as a versioned policy document in a database or configuration store. A system prompt assembler should then inject the tone_boundaries and scenario_rules into the main assistant system prompt, typically in a dedicated ## Tone Policy section. At runtime, implement a two-layer enforcement strategy: a primary layer where the model self-moderates based on the injected policy, and a secondary tone-classifier guardrail that evaluates the assistant's output against the boundary specification before it reaches the user. For high-risk domains like healthcare or crisis support, this secondary guardrail should be a strict validator that can block or flag responses that violate never_acceptable boundaries. Log every boundary violation with the scenario_type, the offending text, and the specific rule that was breached for audit and policy iteration.

The evaluation pipeline is critical. Before deploying any new tone boundary specification, run it through a battery of tone_appropriateness evals. Create a golden dataset of user inputs across all defined scenario_types (e.g., user distress, casual banter, direct complaint) and use an LLM judge to score the assistant's responses against the boundary rules. Automate this as a CI/CD gate in your prompt release process. After deployment, monitor production traces for patterns: a spike in tone-classifier blocks may indicate the policy is too strict, while an increase in user escalations or negative feedback on tone may indicate it is too permissive. The next step is to close the loop by feeding these production signals back into the policy authoring interface, allowing product teams to adjust boundaries based on real user interaction data rather than assumptions.