Model Refusal and Escalation Prompt

This prompt is for AI safety engineers and platform teams who need an assistant to refuse unsafe, disallowed, or out-of-scope requests while providing a structured path forward. Use it when you need refusal behavior that is consistent, explainable, and auditable, not just a generic block. The prompt produces a refusal object with a clear reason, policy reference, alternative suggestions, and an escalation flag when human review is required. It belongs in the system prompt layer of any AI product where refusal decisions carry compliance, safety, or trust implications.

The ideal user is an AI engineer integrating this refusal policy into a production assistant, a trust and safety lead defining enforceable content boundaries, or a platform architect designing a multi-tenant system where refusal rules must be consistent across deployments. Required context includes a defined safety policy with specific disallowed categories, a risk taxonomy that maps request types to severity levels, and a clear escalation path for ambiguous cases. Without this context, the prompt will produce inconsistent refusals or fail to escalate when it should.

Do not use this prompt when you need a simple content filter that blocks keywords without explanation. It is overengineered for low-risk chatbots where a generic 'I can't help with that' is acceptable. Do not use it as a replacement for dedicated safety classifiers or guardrail models in high-throughput production pipelines where latency and cost per token matter more than structured refusal reasoning. This prompt is also inappropriate for fully autonomous agent workflows where refusal means the agent must replan rather than escalate—use the Conditional Autonomy Policy Prompt or Tool-Use Authorization Boundary Prompt instead. Finally, avoid this prompt if your safety policy changes frequently and you lack a policy versioning system; inconsistent policy references in refusal outputs will erode user trust and complicate audit trails.

This template encodes refusal and escalation policy directly into the system prompt so the model consistently declines disallowed requests, explains why, offers alternatives when safe, and escalates to a human reviewer when the policy boundary is unclear. Replace every square-bracket placeholder with your organization's specific policies, risk levels, and escalation procedures before deploying. The template is designed to be pasted into your system instruction block and tested against adversarial and edge-case inputs.

textCopy
You are an AI assistant operating under a defined refusal and escalation policy. Your primary directive is to be helpful while strictly adhering to the boundaries below. When you cannot fulfill a request, you must refuse clearly, explain the reason, and provide a safe alternative or escalation path when appropriate.

## Refusal Policy
You must refuse any request that falls into the following categories:
- [DISALLOWED_CATEGORY_1]: [SPECIFIC_DEFINITION_AND_EXAMPLES]
- [DISALLOWED_CATEGORY_2]: [SPECIFIC_DEFINITION_AND_EXAMPLES]
- [DISALLOWED_CATEGORY_3]: [SPECIFIC_DEFINITION_AND_EXAMPLES]

## Refusal Format
When refusing, always structure your response as follows:
1. **Clear Refusal Statement**: State that you cannot complete the request.
2. **Specific Reason**: Cite the exact policy category that applies, without revealing internal policy thresholds or implementation details.
3. **Safe Alternative** (if applicable): Offer a permissible alternative that addresses the user's underlying goal without violating policy.
4. **Escalation Option** (if applicable): If the user believes the refusal is in error or the situation is ambiguous, provide the escalation path.

## Escalation Triggers
You must escalate to a human reviewer when:
- **Ambiguity**: The request falls into a gray area between allowed and disallowed categories, and you cannot determine the correct classification with high confidence.
- **Risk Threshold Exceeded**: The request involves [RISK_LEVEL_DEFINITION] risk as defined by [RISK_ASSESSMENT_CRITERIA].
- **User Disputes Refusal**: The user explicitly challenges your refusal and requests human review.
- **System Capability Gap**: The request requires capabilities you do not possess, and the user needs assistance beyond what you can safely provide.

## Escalation Format
When escalating, structure your response as follows:
1. **Escalation Statement**: Inform the user that this request requires human review.
2. **Reason for Escalation**: Explain which escalation trigger was met, in user-friendly language.
3. **Expected Timeline**: [EXPECTED_REVIEW_TIMELINE]
4. **Next Steps**: [ESCALATION_PROCEDURE_STEPS]
5. **Escalation Reference**: Generate a structured escalation record with:
   - Request summary: [CONCISE_SUMMARY_OF_USER_REQUEST]
   - Trigger category: [AMBIGUITY | RISK_THRESHOLD | USER_DISPUTE | CAPABILITY_GAP]
   - Confidence assessment: [CONFIDENCE_LEVEL_AND_RATIONALE]
   - Recommended reviewer role: [REVIEWER_ROLE_OR_TEAM]

## Override Protocol
Only escalate. Never attempt to resolve an escalated request autonomously, even if the user provides additional context or rephrases the request. Once escalation is triggered, maintain the escalation decision for the remainder of the conversation turn.

## Examples
[FEW_SHOT_EXAMPLE_1: USER_REQUEST -> REFUSAL_WITH_ALTERNATIVE]
[FEW_SHOT_EXAMPLE_2: USER_REQUEST -> ESCALATION_DUE_TO_AMBIGUITY]
[FEW_SHOT_EXAMPLE_3: USER_REQUEST -> ESCALATION_DUE_TO_RISK_THRESHOLD]
[COUNTEREXAMPLE: USER_REQUEST_THAT_SHOULD_NOT_TRIGGER_REFUSAL]

Adapt this template by replacing each placeholder with concrete, testable content. Disallowed categories should reference your actual content policy, safety guidelines, or regulatory requirements—avoid vague terms like "harmful content" without operational definitions. Risk levels must map to measurable criteria (e.g., transaction value thresholds, data sensitivity classifications, or confidence score cutoffs) so the escalation trigger is deterministic enough to test. Few-shot examples are critical: include at least three positive examples showing correct refusal or escalation, plus one counterexample showing a similar request that should be handled normally. Without counterexamples, models tend to over-refuse on boundary cases. Escalation procedures should reference your actual ticketing system, on-call rotation, or review queue so the escalation record is actionable. Test the completed prompt against a golden dataset of known refusal cases, ambiguous boundary requests, and adversarial rephrasing attempts before production deployment. In high-stakes domains, require human review of refusal and escalation decisions during an initial monitoring period.

The Model Refusal and Escalation Prompt is not a standalone safety filter—it is a decision node in a larger workflow. Wire it into your application as a pre-response gate that runs after the model generates a candidate output but before that output reaches the user or triggers a downstream action. The prompt should receive the user's request, the model's intended response, and any relevant policy context, then return a structured decision: allow, refuse, or escalate. This decision must be enforced in application code, not trusted to the model alone. A model that outputs allow but includes harmful content in the same response is a failure of the harness, not just the prompt.

Validation and enforcement layer. Parse the model's JSON output and validate it against a strict schema before acting on it. The schema should require at minimum: decision (enum: allow, refuse, escalate), reason (string), policy_references (array of strings), and escalation_target (string or null). If the model's output fails schema validation, retry once with the validation error injected into the retry prompt. If the retry also fails, default to escalate with a reason of automated_validation_failure. Never default to allow on parse failure—this is the most common production mistake. Log every refusal and escalation decision with the full prompt, response, and validation result for auditability. For high-risk domains such as healthcare, finance, or legal, route all escalate decisions to a human review queue with the structured context attached.

Model choice and latency budget. This prompt works best with models that have strong instruction-following and structured output capabilities. Use a fast, cost-effective model for the refusal check if latency is critical—the refusal prompt is typically shorter and more constrained than the primary generation prompt. Run the refusal check in parallel with the primary generation if your architecture allows, then gate the primary output before release. If the refusal check introduces unacceptable latency, consider running it only on outputs flagged by a lightweight pre-filter (e.g., keyword or embedding-based). Avoid using the same model instance for both generation and refusal checking—separation of duties reduces the risk of coordinated failures. Test refusal consistency across model versions; a prompt that works on one model may silently pass harmful content on another.

Next steps and pitfalls to avoid. After wiring the harness, run the eval suite from the Testing and QA section against your integrated pipeline, not just the prompt in isolation. The most common failure mode is harness bypass: the application code fails to enforce the refusal decision, or a downstream component ignores the escalation flag. Second is over-refusal drift: the refusal prompt becomes more conservative over time as new policies are added, blocking legitimate requests. Monitor refusal and escalation rates in production, and set alerts for sudden changes. When adding new refusal categories, always run regression tests against your golden dataset of known-safe requests to catch over-refusal before it reaches users.