Policy Enforcement Explanation Prompt Template

This prompt is for trust-and-safety teams and AI safety engineers who need to generate user-facing explanations when a request is refused due to a policy violation. It is designed to be wired into a production enforcement pipeline after a classification or detection step has already determined that a violation occurred. The prompt produces a structured explanation containing a specific policy citation, a clear description of the violation, and constructive guidance on what the user can do next. Use this when opaque refusal messages are generating support tickets, when auditors require traceable policy citations, or when you need to calibrate the tone of refusals to reduce user frustration without weakening the safety boundary.

The ideal user is an engineer or product manager integrating this prompt into an existing enforcement system. The required upstream context includes a confirmed violation type, the specific policy clause that was violated, the user's original request, and any relevant session history. The prompt assumes the violation classification is already complete and accurate. It does not perform detection, classification, or risk scoring itself. If your system cannot yet reliably classify violations, invest in that upstream step first. A well-crafted explanation built on a wrong classification will erode user trust faster than a generic refusal.

Do not use this prompt for the initial violation detection step itself. Do not use it when the policy violation is ambiguous or unconfirmed. Do not use it in high-stakes regulated domains such as medical advice, legal counsel, or financial recommendations without adding human review and evidence grounding. In those contexts, an automated explanation that misstates the reason for refusal can create compliance exposure. Instead, route to a human reviewer and use this prompt only as a draft assistant. For multi-turn conversations, ensure the upstream system tracks cumulative session risk and passes relevant context so the explanation does not contradict prior turns. When in doubt, prefer a simple, honest refusal over a detailed explanation that might be wrong.

This template produces a user-facing explanation when a request is refused due to policy. It expects that an upstream enforcement pipeline has already classified the violation, identified the applicable policy, assigned a risk tier, and determined the refusal action. The prompt does not make enforcement decisions—it explains them. Replace each square-bracket placeholder with structured data from your enforcement system before sending the prompt to the model. The template is designed for trust-and-safety teams who need consistent, transparent, and constructive refusal messages that reduce support tickets and user frustration.

textCopy
You are a policy enforcement explanation assistant. Your job is to explain why a user request was refused, cite the specific policy that applies, describe what part of the request triggered the violation, and offer constructive next steps when appropriate. You must be accurate, transparent, and calibrated to the risk level of the violation.

## INPUT DATA
- User Request: [USER_REQUEST]
- Violation Type: [VIOLATION_TYPE]
- Applicable Policy: [POLICY_NAME]
- Policy Reference: [POLICY_REFERENCE]
- Violation Description: [VIOLATION_DESCRIPTION]
- Risk Tier: [RISK_TIER]
- Refusal Action: [REFUSAL_ACTION]
- Safe Alternatives Available: [SAFE_ALTERNATIVES_AVAILABLE]
- Jurisdiction Context: [JURISDICTION_CONTEXT]

## OUTPUT SCHEMA
Return a JSON object with these fields:
{
  "explanation_summary": "One-sentence summary of why the request was refused",
  "policy_citation": "Specific policy name and reference identifier",
  "violation_detail": "Clear description of what part of the request violated policy, without repeating harmful content verbatim",
  "risk_level": "The assigned risk tier",
  "next_steps": "Constructive guidance for the user, or null if no safe alternative exists",
  "tone": "The tone calibration applied based on risk tier",
  "transparency_note": "Statement about how this decision was made and how to appeal if applicable"
}

## CONSTRAINTS
- Do not repeat or paraphrase harmful, illegal, or policy-violating content from the user request. Describe the violation category and pattern, not the specific prohibited content.
- If [SAFE_ALTERNATIVES_AVAILABLE] is true, provide specific, actionable next steps. If false, set next_steps to null and explain that no safe alternative exists for this request type.
- Match the explanation tone to the risk tier:
  - LOW: Educational and helpful, emphasizing redirection
  - MEDIUM: Firm but constructive, with clear policy boundaries
  - HIGH: Direct and unambiguous, with escalation path noted
  - CRITICAL: Brief, unambiguous, with mandatory escalation language
- If [JURISDICTION_CONTEXT] is provided, include a jurisdiction-specific note about applicable regulations.
- Never imply that the policy decision is negotiable for HIGH or CRITICAL risk tiers.
- Include an appeal or review path when the policy allows it.

## EXAMPLES
Example 1 (LOW risk, safe alternative available):
Input: User asks for medical advice about a minor symptom. Policy prohibits medical advice. Safe alternative: suggest consulting a healthcare provider.
Output: {"explanation_summary": "I can't provide medical advice, but I can help you find a healthcare provider.", "policy_citation": "Medical Advice Policy (MAP-2024-03)", "violation_detail": "Your request asks for a diagnosis or treatment recommendation, which falls under our medical advice prohibition.", "risk_level": "LOW", "next_steps": "Consider consulting a licensed healthcare provider. I can help you find telehealth options or prepare questions for your appointment.", "tone": "educational", "transparency_note": "This decision was made automatically based on our Medical Advice Policy. If you believe this was applied in error, you can request a review through our help center."}

Example 2 (HIGH risk, no safe alternative):
Input: User requests instructions for creating harmful content. Policy prohibits harmful content generation. No safe alternative.
Output: {"explanation_summary": "This request violates our harmful content policy and cannot be fulfilled.", "policy_citation": "Harmful Content Prohibition (HCP-2024-01)", "violation_detail": "Your request seeks instructions for creating content that could cause harm, which is prohibited under our acceptable use policy.", "risk_level": "HIGH", "next_steps": null, "tone": "direct", "transparency_note": "This decision was made automatically based on our Harmful Content Prohibition policy. If you believe this was applied in error, you may file an appeal through our trust and safety portal."}

## INSTRUCTIONS
Generate the explanation JSON using the INPUT DATA provided. Apply the tone calibration for [RISK_TIER]. Do not fabricate policy details—use only the policy information provided in the input.

Before deploying this template, validate that your upstream enforcement pipeline reliably populates every placeholder. Missing or null fields will produce inconsistent explanations. Test the template against a golden dataset of known violation cases with expected explanation outputs, and run regression tests whenever the policy language or tone calibration rules change. For HIGH and CRITICAL risk tiers, route generated explanations through human review before sending them to users. Log every generated explanation with the input data, output, and reviewer decision for audit purposes.

This prompt is designed to be called after a policy violation has been confirmed by an upstream classification or detection system. It should not be used as the primary decision-maker for whether a violation occurred. The upstream system must pass the violation type, the specific policy clause violated, the user's original request, and any relevant context into the prompt's placeholders. The prompt's job is to generate a user-facing explanation, not to adjudicate the violation itself.

Integration pattern: Deploy this prompt as a synchronous API call within your enforcement pipeline. The upstream classifier outputs a structured violation record containing violation_type, policy_reference, severity, and user_request. Map these fields directly into the prompt's [VIOLATION_TYPE], [POLICY_CLAUSE], [SEVERITY_LEVEL], and [USER_REQUEST] placeholders. Validate the model's output against a defined JSON schema that requires explanation_text, policy_citation, next_steps, and tone_label fields. If validation fails, retry once with the validation errors injected into the prompt as additional [CONSTRAINTS]. After two failures, escalate to a human review queue with the raw violation record and both failed attempts attached.

Model choice and latency: Use a model with strong instruction-following and low refusal-aversion for this task—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are suitable. This prompt is not latency-sensitive in most architectures because the user is already waiting on a refusal decision. However, if your product shows a synchronous refusal UI, aim for a response under 2 seconds. Cache the system prompt prefix to reduce token costs across repeated calls. Logging and audit: Every generated explanation must be logged with the full prompt, the model response, the validation result, and the final displayed text. This audit trail is critical for trust-and-safety reviews, policy appeals, and regulatory inquiries. Do not log the user's original request if it contains PII—redact before storage.

Human review triggers: Route to human review when: (1) the [SEVERITY_LEVEL] is critical or high, (2) the model's output fails schema validation after one retry, (3) the tone_label is confrontational or dismissive per a secondary tone classifier, or (4) the [USER_REQUEST] contains indicators of imminent harm, self-harm, or child safety concerns. For these cases, the explanation should be drafted by a trained reviewer, not generated automatically. Testing before launch: Run this prompt against a golden dataset of 200+ violation scenarios spanning all severity levels, policy categories, and edge cases (e.g., ambiguous requests, multi-policy conflicts, non-English inputs). Measure explanation accuracy, tone appropriateness, and policy citation correctness. Set a pass threshold of 95% before enabling the prompt in production. Re-run this eval suite on every prompt or model version change.