Policy Conflict Resolution Prompt

This prompt is designed for AI engineers and platform teams deploying complex assistants where multiple behavioral policies—such as tone constraints, compliance rules, refusal boundaries, and output format contracts—can produce contradictory guidance in a single turn. The core job-to-be-done is automated conflict detection and resolution: when two or more active policies demand incompatible actions, this prompt generates a resolved instruction, a priority rationale, an escalation flag, and a clear record of which policies were reconciled. The ideal user is a developer integrating this into a policy enforcement layer within a multi-turn assistant architecture, not an end-user crafting one-off chatbot interactions.

Use this prompt when your assistant operates under a policy stack where conflicts are likely—for example, a healthcare copilot that must balance clinical completeness, PII redaction, and a strict refusal policy, or a financial assistant that must reconcile brand voice guidelines with regulatory disclosure requirements. The prompt requires structured inputs: the full text of each conflicting policy, the user's current request, recent conversation context, and a defined priority hierarchy if one exists. It is not suitable for simple single-policy assistants, for resolving conflicts that require external legal or compliance review, or for cases where the conflict is between a policy and an unconstrained user demand rather than between two system-level policies. Do not use this prompt as a substitute for a proper policy authoring process—it resolves conflicts at runtime, but poorly written or ambiguous policies will produce unreliable resolutions.

Before wiring this into production, define your evaluation criteria. A successful resolution must cite the specific conflicting policies, explain the priority decision, and produce a single actionable instruction. Failure modes include false conflict detection (flagging complementary policies as contradictory), resolution that silently violates a higher-priority policy, or escalation fatigue where every minor tension triggers an unnecessary human review. Start by testing against a golden set of known policy conflicts with expected resolutions, and always log the resolution rationale for audit. If the assistant operates in a regulated domain, the escalation flag should route to a human reviewer rather than auto-resolving high-severity conflicts.

This template is the core of the Policy Conflict Resolution workflow. It expects a structured list of active policies and the user's current request, then produces a resolution decision. The prompt is designed to be called mid-turn when a policy enforcement layer detects that two or more policies would produce contradictory guidance for the same user input. It does not decide which policies are active—that is the job of the upstream policy engine. Its job is to reconcile conflicts and produce an auditable resolution.

textCopy
You are a policy conflict resolution engine. Your task is to detect when two or more active policies produce contradictory guidance for the same user request, then generate a resolved instruction.

## INPUT

Active Policies (JSON array of policy objects):
[ACTIVE_POLICIES]

User Request:
[USER_REQUEST]

Session Context Summary:
[SESSION_CONTEXT]

## POLICY OBJECT STRUCTURE
Each policy object contains:
- policy_id: unique identifier
- policy_name: human-readable name
- priority: integer (lower number = higher priority, 1 is highest)
- rule: the behavioral rule or constraint
- source: where this policy originated (system, compliance, brand, user_preference, tool_constraint)
- scope: what this policy applies to (output_content, tool_use, tone, data_handling, refusal, citation)

## TASK
1. Identify every pair or group of active policies that produce contradictory guidance for the user request.
2. For each conflict, determine which policy should take precedence based on priority, source, and scope specificity.
3. Generate a single resolved instruction that satisfies the highest-priority constraints while minimizing violation of lower-priority policies.
4. If the conflict cannot be resolved without violating a policy with priority 1 or 2, set escalation_required to true.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "conflict_detected": boolean,
  "conflicts": [
    {
      "conflict_id": string,
      "policies_in_conflict": [string],
      "contradiction_description": string,
      "resolution_rationale": string,
      "winning_policy_id": string,
      "overridden_policy_ids": [string]
    }
  ],
  "resolved_instruction": string,
  "escalation_required": boolean,
  "escalation_reason": string | null,
  "unresolved_policy_ids": [string]
}

## CONSTRAINTS
- Never ignore a priority-1 policy. If two priority-1 policies conflict, escalate.
- Prefer source hierarchy: system > compliance > brand > user_preference > tool_constraint when priorities are equal.
- The resolved_instruction must be a single, coherent behavioral directive that can be injected into the assistant's context.
- If escalation_required is true, resolved_instruction should describe the safe fallback behavior while escalation is pending.
- Do not fabricate policies. Only use policies provided in [ACTIVE_POLICIES].
- If no conflict exists, return conflict_detected: false with an empty conflicts array and set resolved_instruction to the original highest-priority applicable policy rule.

To adapt this template, replace the square-bracket placeholders with your application's live data. [ACTIVE_POLICIES] should be a JSON array built by your policy engine, not raw policy documents. [USER_REQUEST] is the latest user turn, cleaned of any prior assistant output. [SESSION_CONTEXT] should include the last N turns or a structured summary so the resolver understands what the user is trying to accomplish. The output schema is strict JSON—validate it before injecting the resolved_instruction into the assistant's context. If escalation_required is true, route to a human review queue and do not continue the automated workflow.

Before deploying, test this prompt against known conflict scenarios from your policy catalog. Common failure modes include: the resolver inventing a compromise that violates both policies instead of picking a winner; failing to escalate when two priority-1 policies genuinely conflict; or producing a resolved_instruction that is too vague to be actionable. Run eval suites that include single-policy cases (no conflict), clear-priority cases, equal-priority cases, and cases where the user request itself is ambiguous. If your assistant operates in a regulated domain, log every resolution decision with the full conflict analysis for audit review.

The Policy Conflict Resolution Prompt is not a standalone chatbot instruction; it is a middleware component that sits between your policy engine and the assistant's response generation. In a production harness, this prompt should be invoked before the assistant formulates a user-facing reply whenever the policy engine detects that two or more active policies produce contradictory guidance for the current turn. The typical call pattern is: (1) the policy engine evaluates the user input and session state against all active policies, (2) if a conflict score exceeds a configurable threshold, the conflict resolution prompt is called with the conflicting policies, user intent, and session context, (3) the resolved instruction is injected into the assistant's system message or tool context for the current turn only. This keeps resolution logic out of the main assistant prompt and makes conflict handling auditable and debuggable as a separate step.

Validation and retry logic is critical because a malformed resolution can cascade into policy violations downstream. The output schema should be strictly validated: confirm that resolved_instruction is a non-empty string, priority_rationale references at least one specific policy by ID, escalation_flag is a boolean, and reconciled_policies is a non-empty array of policy IDs that actually appear in the input. If validation fails, retry once with the validation errors injected as feedback into the prompt's [CONSTRAINTS] block. If the second attempt also fails, escalate to a human reviewer and log the full input/output pair for diagnosis. Do not silently fall back to a default policy—unresolved conflicts in regulated domains (healthcare, finance, legal) must halt the assistant's response until a human resolves the ambiguity. For lower-risk deployments, you may configure a fallback behavior such as defaulting to the most restrictive policy and flagging the turn for post-hoc review.

Model choice and latency budgeting matter here because this prompt runs on the critical path before every potentially conflicting turn. Use a fast, instruction-following model (e.g., GPT-4o-mini, Claude 3.5 Haiku) rather than a large reasoning model, since the task is structured classification and rewrite, not open-ended generation. Cache the prompt prefix containing the static policy definitions and output schema to reduce per-call latency and cost. If your policy set is large, pre-filter to only the policies that are actually active for the current session and user role before passing them into the prompt—do not dump the entire policy registry into [CONTEXT]. Log every resolution event with: session ID, turn number, conflicting policy IDs, resolved instruction, escalation flag, and the model's raw output. This audit trail is essential for compliance reviews and for tuning conflict thresholds over time. Wire the escalation flag into your observability stack so that frequent escalations trigger an alert, indicating that your policy set may need refactoring to reduce ambiguity.