Multi-Policy Conflict Resolution Prompt

This prompt is designed for the specific job of resolving conflicts when three or more safety policies fire simultaneously on a single user request, producing contradictory guidance. The ideal user is a safety engineer or AI platform architect who has already built individual policy evaluation steps and is now facing inconsistent user experiences—one policy demands a refusal while another permits fulfillment, or two policies require incompatible response formats. The required context includes the original user request, the full text of each triggered policy, and the conflicting outputs from each policy evaluator. Without this upstream context, the resolution prompt cannot produce a reliable conflict analysis.

You should not use this prompt when only one or two policies are in conflict, as a simpler priority-ordered conditional in application code will be faster, cheaper, and more auditable. Do not use it when the conflict stems from ambiguous policy language rather than genuine overlap—that situation calls for the Policy Boundary Clarification Prompt instead. Avoid this prompt when the policies themselves are unstable or under active revision, because the resolution rationale will become stale as policy text changes. In high-throughput systems where latency is critical, consider whether policy conflicts can be pre-resolved at the policy-authoring stage through explicit precedence rules, reducing the need for runtime conflict resolution. This prompt belongs in the safety decision layer of your AI pipeline, after individual policy evaluations but before the final response is delivered to the user, and it should always produce a structured, auditable record of how the conflict was resolved.

Before deploying this prompt, ensure you have a defined policy hierarchy that establishes which policy takes precedence in common conflict categories. Without this hierarchy, the model will invent its own precedence, leading to inconsistent resolutions. Wire the output into your observability pipeline so that conflict patterns can be tracked over time—frequent conflicts between specific policy pairs often indicate that the policies themselves need refinement. Finally, treat the resolution output as a candidate decision, not a final action: for high-risk domains, route resolutions that overturn a refusal to a human reviewer before the response is returned to the user.

This template is the core instruction set you send to the model when your policy engine detects that two or more safety policies are in conflict for a given request. It forces the model to surface the conflict explicitly, apply a defined policy hierarchy, and produce a reasoned final decision rather than defaulting to the safest-but-wrong refusal or silently violating one policy to satisfy another. Copy the block below, replace each square-bracket placeholder with your production data, and integrate it into your decision pipeline.

textCopy
You are a policy conflict resolution engine. Your job is to analyze a user request that triggers conflicting guidance from multiple safety policies, resolve the conflict using a defined policy hierarchy, and produce a final decision with clear rationale.

## INPUT
User Request: [USER_REQUEST]

Conflicting Policies:
[POLICY_LIST]

Policy Hierarchy (highest priority first):
[POLICY_HIERARCHY]

## INSTRUCTIONS
1. Identify the specific conflict between the listed policies for this request. State what each policy requires and why they cannot both be satisfied simultaneously.
2. Apply the policy hierarchy. Explain which policy takes precedence and why, citing the hierarchy order.
3. If the conflict cannot be fully resolved by hierarchy alone, identify any additional principles that should govern the resolution (e.g., least harm, user safety, legal obligation).
4. Produce a final decision: ALLOW, REFUSE, or PARTIAL with explicit scope boundaries.
5. If PARTIAL, specify exactly which portions of the request are allowed and which are refused, with policy citations for each.

## OUTPUT FORMAT
Return a JSON object with this exact schema:
{
  "conflict_summary": "string describing the policy conflict",
  "policy_requirements": [
    {"policy_name": "string", "requirement": "string", "action": "ALLOW|REFUSE|FLAG"}
  ],
  "hierarchy_application": "string explaining precedence reasoning",
  "resolution_principles": ["string"],
  "final_decision": "ALLOW|REFUSE|PARTIAL",
  "allowed_scope": "string or null if REFUSE",
  "refused_scope": "string or null if ALLOW",
  "decision_rationale": "string",
  "escalation_recommended": true|false,
  "escalation_reason": "string or null"
}

## CONSTRAINTS
- Do not default to refusal just because policies conflict. Apply the hierarchy.
- If the hierarchy does not clearly resolve the conflict, set escalation_recommended to true and explain why.
- Never fabricate policy content. Only reference policies provided in the input.
- If the user request itself is ambiguous, note the ambiguity but resolve based on the most reasonable interpretation.

To adapt this template for your production system, start by populating [POLICY_LIST] with the actual policy names and their conflicting requirements extracted from your policy engine. The [POLICY_HIERARCHY] should reflect your organization's real precedence rules—for example, legal compliance policies typically outrank content quality policies, and user-safety policies outrank user-experience policies. If your system uses a dynamic hierarchy that varies by request type or jurisdiction, inject the resolved hierarchy before sending the prompt rather than hardcoding it. The output schema is designed for machine consumption; wire the final_decision field directly into your routing logic and use escalation_recommended to trigger human review queues.

Before deploying, validate this prompt against a golden set of known conflict cases where the correct resolution is unambiguous. Test edge cases including: conflicts where the hierarchy is circular or incomplete, requests that sit exactly on a policy boundary, and scenarios where the highest-priority policy would produce a clearly unreasonable outcome if applied rigidly. If your eval set shows the model deferring to refusal more than 10% of the time when hierarchy should have produced an ALLOW or PARTIAL decision, revisit the instruction emphasis in step 3. Log every conflict_summary and decision_rationale to your observability pipeline so you can detect policy gaps and hierarchy design flaws from production patterns.

This prompt is not a standalone chatbot. It is a decision-layer component that sits between your policy engine and the model's final response. When multiple safety policies fire on a single user request and produce contradictory guidance—one policy says 'block,' another says 'allow with caution'—this prompt resolves the conflict. The harness must capture the conflicting policy outputs, pass them as structured input, and enforce the resolution decision downstream.

Wire the prompt into your safety pipeline after individual policy checks complete but before the final response is generated. Collect each policy's output as a structured object with fields: policy_id, policy_name, decision (block | allow | warn | escalate), confidence (0.0–1.0), and rationale. Pass this array as [CONFLICTING_POLICIES]. Include the original user request as [USER_REQUEST] and your policy hierarchy rules as [POLICY_HIERARCHY]—a ranked list specifying which policies override others and under what conditions. The model returns a JSON decision object with final_decision, resolution_rationale, overridden_policies, and escalation_flag. Validate this output against a strict schema before acting on it. If validation fails, retry once with the schema error injected into [CONSTRAINTS]; if it fails again, escalate to a human reviewer with the full conflict context.

Log every conflict resolution event with a unique conflict_id, timestamp, model version, input policies, resolution output, and whether the decision was applied or overridden by a human. This audit trail is essential for detecting policy drift, identifying over-refusal patterns, and tuning your hierarchy rules. Never silently apply a resolution that overrides a high-severity safety policy (e.g., self-harm, child safety) without human review, regardless of what the hierarchy says. Implement a hard-coded circuit breaker: if the resolution would override a policy tagged severity: critical, force escalation. The prompt's [RISK_LEVEL] placeholder should be set to high when critical policies are in conflict, which instructs the model to recommend escalation rather than autonomous resolution. For model choice, use a capable instruction-following model with strong JSON output discipline (e.g., GPT-4o, Claude 3.5 Sonnet) and set temperature=0 to maximize deterministic policy application. Do not use this prompt with small or locally fine-tuned models unless you have validated their ability to follow the output schema and respect the hierarchy rules under adversarial conflict scenarios.