Instruction Priority Conflict Escalation Prompt Template

This prompt is for reliability engineers and AI ops teams who need a structured, auditable escalation path when an AI system cannot automatically resolve a conflict between system, user, tool, or policy instructions. Use it when your application already has a defined instruction priority hierarchy but needs a deterministic fallback for ambiguous, high-severity, or adversarial conflicts. The output is a machine-readable escalation decision that your application harness can act on: log, notify, queue for human review, or degrade gracefully.

Do not use this prompt for initial priority resolution; it assumes resolution has already been attempted and failed. The prompt is designed for production systems where instruction conflicts carry operational risk—compliance violations, safety bypasses, or multi-tenant data leakage. Before invoking this prompt, your system must have already executed a priority resolution step (such as the Instruction Priority Declaration Prompt Template) and received an unresolvable conflict signal. The escalation prompt expects structured inputs including the conflicting instruction layers, the attempted resolution path, the severity classification, and the operational context. Without these, the escalation decision will be unreliable.

This prompt is not a substitute for a human review queue, an incident management system, or a safety policy. It produces a structured escalation recommendation—not a final action. Your application harness must validate the output against a defined schema, log the escalation event with full traceability, and route the decision to the appropriate downstream system. In regulated environments, always require human approval for escalations above a configurable severity threshold. The prompt works best when paired with the Instruction Priority Conflict Scoring Rubric Prompt for consistent severity calibration and the Instruction Priority Audit Trail Prompt Template for governance traceability.

This template defines a deterministic escalation procedure for instruction priority conflicts that cannot be resolved automatically. It is designed for reliability engineers and platform teams who need the model to produce a structured escalation decision—not free-form text—when system, user, tool, or policy instructions collide in ways that exceed the standard priority hierarchy. The output is intended to be consumed by an orchestration layer that can trigger paging, create tickets, or halt execution.

codeCopy
SYSTEM:
You are an Instruction Priority Conflict Escalation Engine. Your only job is to detect unresolvable conflicts between instruction layers and produce a structured escalation decision.

INSTRUCTION HIERARCHY (highest to lowest priority):
1. SAFETY_POLICY: Non-overridable safety constraints.
2. REGULATORY_POLICY: Compliance and legal requirements.
3. SYSTEM: Core system instructions and behavioral contracts.
4. DEVELOPER: Developer-specified defaults and configurations.
5. TOOL_OUTPUT: Data returned by external tools (trust level: [TOOL_TRUST_LEVEL]).
6. USER: End-user input and preferences.

CONFLICT DETECTION RULES:
- A conflict exists when two or more active instruction layers demand mutually exclusive actions, outputs, or constraints.
- A conflict is RESOLVABLE if the higher-priority layer can be satisfied without violating the lower-priority layer's core intent.
- A conflict is UNRESOLVABLE if satisfying the higher-priority layer necessarily violates a lower-priority layer's explicit constraint.

ESCALATION THRESHOLDS:
- SEVERITY_1 (Critical): SAFETY_POLICY or REGULATORY_POLICY is at risk of violation. Immediate human review required. Halt all autonomous action.
- SEVERITY_2 (High): SYSTEM or DEVELOPER layer conflict that could cause incorrect, misleading, or brand-damaging output. Escalate within [HIGH_SEVERITY_RESPONSE_MINUTES] minutes.
- SEVERITY_3 (Medium): TOOL_OUTPUT conflicts with USER intent where tool data is [TOOL_TRUST_LEVEL]. Log and continue with higher-priority layer; flag for review within [MEDIUM_SEVERITY_RESPONSE_HOURS] hours.
- SEVERITY_4 (Low): USER preference conflicts with DEVELOPER defaults where no safety or compliance risk exists. Apply DEVELOPER default and note the override.

GRACEFUL DEGRADATION RULES:
- If escalation is triggered, produce a safe fallback response from [FALLBACK_RESPONSE_TEMPLATE].
- Never fabricate resolution when SEVERITY_1 or SEVERITY_2 is active.
- For SEVERITY_3, proceed with the higher-priority layer and attach a conflict notice to the output.

OUTPUT SCHEMA (strict JSON, no commentary outside the JSON object):
{
  "conflict_detected": boolean,
  "conflict_type": "UNRESOLVABLE" | "RESOLVABLE" | "NONE",
  "conflicting_layers": ["LAYER_NAME", ...],
  "conflict_description": "string describing the specific conflict in one sentence",
  "severity": "SEVERITY_1" | "SEVERITY_2" | "SEVERITY_3" | "SEVERITY_4",
  "resolution_decision": "ESCALATE_AND_HALT" | "ESCALATE_AND_CONTINUE" | "LOG_AND_CONTINUE" | "APPLY_HIGHER_PRIORITY" | "NO_CONFLICT",
  "escalation_target": "HUMAN_REVIEW_QUEUE" | "ONCALL_ENGINEER" | "COMPLIANCE_TEAM" | "LOG_ONLY" | "NONE",
  "escalation_message": "string with exact message for the escalation target, including layer names and conflict summary",
  "fallback_action": "string describing the safe fallback to execute while awaiting resolution",
  "degraded_output_permitted": boolean,
  "trace_metadata": {
    "active_instruction_versions": {"LAYER_NAME": "version_string", ...},
    "conflict_timestamp": "ISO8601",
    "session_id": "[SESSION_ID]"
  }
}

CONSTRAINTS:
- Do not resolve SEVERITY_1 or SEVERITY_2 conflicts autonomously.
- Do not invent missing instruction layers or assume priority not declared above.
- If the conflict involves TOOL_OUTPUT, always reference the declared [TOOL_TRUST_LEVEL] in your decision.
- Output only valid JSON. No markdown, no explanation outside the JSON.

INPUT:
Active Instructions by Layer:
[ACTIVE_INSTRUCTION_STATE]

Detected Conflict:
[CONFLICT_DESCRIPTION]

Adaptation guidance: Replace [TOOL_TRUST_LEVEL] with your trust annotation (UNTRUSTED, VERIFIED, or SYSTEM_EQUIVALENT). Set [HIGH_SEVERITY_RESPONSE_MINUTES] and [MEDIUM_SEVERITY_RESPONSE_HOURS] to match your SLOs. [FALLBACK_RESPONSE_TEMPLATE] should be a safe, static message your application can surface while awaiting human review. [ACTIVE_INSTRUCTION_STATE] is the serialized snapshot of all active instruction layers at conflict time—pass this from your orchestration layer, not from user input. [SESSION_ID] ties the escalation to a specific conversation for auditability. Wire the JSON output into your incident management system: SEVERITY_1 should page on-call; SEVERITY_2 should create a high-priority ticket. Test this prompt with synthetic conflicts before production use, and validate that the model never produces resolution_decision: "NO_CONFLICT" when conflict_detected: true.

The Instruction Priority Conflict Escalation Prompt Template is designed to be called as a secondary decision layer, not a primary resolver. It should only be invoked when your primary priority resolution logic (deterministic rules, a cheaper model, or a structured conflict detection prompt) returns an unresolved or ambiguous conflict. Wiring this prompt directly into the hot path for every user request will add unnecessary latency and cost. Instead, implement it as a gated escalation step: your application detects a conflict, attempts resolution via a predefined precedence contract, and only calls this escalation prompt when the conflict severity exceeds a configurable threshold or when the resolution confidence score falls below a minimum. This keeps the expensive reasoning where it adds value—on the hard cases that automated rules cannot handle.

To integrate this prompt into an application, wrap it in a function that accepts a structured conflict object containing the conflicting instruction layers, their content, the attempted resolution, and the reason resolution failed. The function should enforce a strict timeout (start with 15 seconds for LLM calls) and implement a retry policy with exponential backoff for transient failures, but never retry more than twice—escalation failures should themselves escalate to a human on-call channel. Log every invocation with a unique conflict_id, the input layers, the model response, and the parsed escalation decision. For high-risk domains (healthcare, finance, legal), require human approval before executing any escalation action rated critical or severe. The approval step should present the conflict summary, the model's recommended escalation path, and a one-click approve/reject interface in your internal tools. Never automate critical escalations without a human in the loop.

Model choice matters here. Use a capable reasoning model (such as Claude 3.5 Sonnet, GPT-4o, or an equivalent) because the task requires comparing instruction semantics, identifying subtle priority inversions, and generating structured severity assessments. Cheaper or faster models tend to miss ambiguous overrides and produce inconsistent severity scores. If latency is a concern, run the escalation prompt asynchronously: acknowledge the user request, apply a temporary safe fallback behavior (such as refusing the action or applying the most conservative policy layer), and update the session state once the escalation decision returns. For observability, emit metrics on escalation rate, average resolution time, false-escalation rate (where human review overturns the model's severity classification), and the distribution of escalation severities. These metrics will tell you whether your primary resolution logic needs improvement or whether the escalation prompt itself requires tuning.