User Intent vs Safety Policy Conflict Prompt

This prompt is designed for safety engineers and AI product teams who must resolve a specific, high-stakes conflict: a user's request is legitimate and well-intentioned, but it triggers a safety policy that would normally block or refuse the interaction. The job-to-be-done is not to simply refuse the user, nor to silently bypass the policy. Instead, the prompt's job is to generate a safe, intent-preserving alternative that satisfies the user's underlying goal while remaining fully compliant with the system's safety constraints. The ideal user is an engineer integrating this prompt into a production AI gateway, a content moderation pipeline, or a customer-facing assistant where over-refusal degrades the user experience and under-refusal creates unacceptable risk.

You should use this prompt when you have a clear, pre-defined safety policy (e.g., 'do not provide medical diagnoses,' 'do not generate executable code for security testing without authorization') and a user request that is adjacent to, but not explicitly violating, that policy. For example, a user asking 'What are the symptoms of a heart attack?' triggers a medical advice policy, but their intent is informational. The prompt must be wired into a system that can first classify the user's intent and the triggered policy before this prompt is invoked. It requires the [USER_REQUEST], the [TRIGGERED_POLICY], and the [CLASSIFIED_INTENT] as mandatory inputs. Do not use this prompt for overtly malicious or clearly disallowed requests; those should be handled by a standard refusal prompt. Do not use it when the safety policy itself is ambiguous or untested—resolve the policy definition first.

The primary constraint is that the output must be measurable. You cannot ship this prompt without an evaluation harness that scores two competing metrics: intent preservation (did the alternative actually address what the user wanted?) and policy compliance (did the alternative violate the letter or spirit of the policy?). A common failure mode is generating a safe alternative that is so generic it fails to preserve intent, effectively becoming a polite refusal. The next step after reading this section is to review the prompt template and the implementation harness, which will show you how to validate the output against these two axes before it ever reaches a user.

This prompt template is designed for safety engineers and AI platform teams who need to handle cases where a user's legitimate request triggers a safety policy. The goal is not to simply refuse, but to produce an intent-preserving alternative that satisfies both the user's underlying goal and the safety constraints. The template uses square-bracket placeholders that must be populated with your specific policy definitions, user input, and output requirements before use. It is critical to test this prompt against adversarial examples and edge cases before deployment, as over-refusal breaks product utility and under-refusal creates liability.

codeCopy
SYSTEM:
You are a safety-aware assistant operating under strict policy constraints. Your primary directive is to help users achieve their legitimate goals while ensuring full compliance with the defined safety policies. When a user request triggers a policy conflict, you must not simply refuse. Instead, you must analyze the user's underlying intent and produce a safe alternative that preserves as much of that intent as possible.

## SAFETY POLICIES
[POLICIES]

## CONFLICT RESOLUTION RULES
1. Identify the specific policy or policies triggered by the user request.
2. Extract the user's underlying intent, separating it from the non-compliant surface request.
3. If an intent-preserving alternative exists that satisfies all policies, provide it.
4. If no alternative can satisfy the intent without violating policy, clearly explain the boundary and suggest the closest permissible action.
5. Never execute, simulate, or provide instructions for a policy-violating action, even as a hypothetical.

## OUTPUT FORMAT
Return a JSON object with the following schema:
{
  "conflict_detected": boolean,
  "triggered_policies": [string],
  "user_intent_summary": string,
  "resolution_type": "alternative_provided" | "boundary_explained" | "no_conflict",
  "safe_alternative": string | null,
  "explanation_to_user": string,
  "confidence": number (0-1)
}

## CONSTRAINTS
- [CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

USER:
[INPUT]

To adapt this template for your production environment, replace each placeholder with concrete content. The [POLICIES] block should contain your organization's specific safety rules, each with a unique identifier for traceability. The [CONSTRAINTS] block can include output length limits, tone requirements, or domain-specific restrictions. The [EXAMPLES] block is critical for calibration—include at least three few-shot examples covering: a clear policy violation with a good alternative, a borderline case, and a legitimate request that should not be blocked. The [INPUT] placeholder receives the user's request at runtime. Before shipping, run this prompt through a regression test suite that measures both intent preservation rate and policy compliance rate, and establish acceptable thresholds for each. For high-risk domains, always route low-confidence outputs to human review.

This prompt is designed to sit inside a safety evaluation gateway that intercepts user requests flagged by an upstream classifier. The classifier determines whether a request triggers a safety policy boundary. If it does, the request is routed to this prompt instead of being immediately refused. The prompt's job is to generate an intent-preserving alternative that satisfies both the user's stated goal and the safety policy. The output is a structured JSON decision that downstream systems can act on: either an approved alternative, a refusal with explanation, or an escalation flag.

To wire this into an application, wrap the prompt in a validation and retry layer. The model must return valid JSON matching the defined output schema. If parsing fails, retry once with the original prompt plus the raw model output and a clear error message. If the second attempt also fails, log the failure and escalate to a human review queue. For high-risk domains, implement a human-in-the-loop approval step before any generated alternative is shown to the user. Store the full prompt, model response, and validation result in an audit log with a unique request ID, timestamp, and model version. This traceability is essential for safety incident review and policy tuning.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities. If the deployment environment requires low latency, consider a smaller fine-tuned model that has been trained on your specific safety policy and alternative-generation examples. For offline or batch evaluation, run this prompt against a golden dataset of known conflict cases and measure both intent preservation (does the alternative achieve the user's original goal?) and policy compliance (does it violate any safety rules?). Track these metrics over time to detect policy drift or model degradation. Avoid deploying this prompt without a monitoring dashboard that surfaces refusal rates, escalation rates, and alternative acceptance rates by policy category.