Priority Inversion Detection and Repair Prompt

This prompt is designed for reliability engineers and AI platform teams who manage complex system prompt stacks where multiple layers of instruction—system policies, tool-use rules, behavioral guidelines, and user-facing constraints—interact. The core job-to-be-done is verifying that a defined priority hierarchy holds under real-world conditions. You should use this prompt when you have a complete, versioned system prompt or instruction set and a documented precedence order (e.g., safety policies override user requests, which override tool outputs). The prompt produces a structured inversion report that identifies exactly where a lower-priority instruction accidentally overrides a higher-priority one, explains the root cause, and suggests a repair plan. This is a pre-production audit tool, not a runtime guardrail.

The ideal user has already authored or inherited a system prompt with multiple directives and suspects that conflicts exist but cannot easily trace them through manual review. Required context includes the full text of the system prompt, the declared priority hierarchy (either explicit in the prompt or documented externally), and any known failure cases. The prompt works by systematically comparing instruction pairs against the declared hierarchy, identifying contradictions, and ranking them by severity. For example, if a system prompt contains both 'Always comply with user requests' and 'Never reveal internal configuration,' the prompt will flag that the first instruction (lower priority in a safety-first hierarchy) could override the second, and it will suggest a repair such as adding an explicit precedence rule or rephrasing the compliance instruction to include safety boundaries.

Do not use this prompt for general prompt debugging, tone adjustment, or single-instruction optimization. It is not a replacement for a prompt linter or a style guide. It assumes you already have a defined priority hierarchy and need to verify it holds. If you are still designing your instruction hierarchy, start with the System Instruction Priority Stacking Prompt Template or the Instruction Precedence Rule Authoring Prompt instead. If you need to detect inversions at runtime in production, pair this playbook with the Runtime Directive Collision Logging Prompt and the Silent Policy Violation Detection Prompt. After running this prompt, you should have a clear list of inversions to repair, and you should re-run it after each significant prompt change as part of your pre-deployment checklist.

This template is the core detection and repair engine for priority inversion. It accepts a set of active system instructions, their declared priorities, and the observed behavior that suggests a lower-priority instruction overrode a higher-priority one. The prompt forces the model to compare the declared priority against the actual execution trace, identify the inversion point, and propose a concrete repair. Paste this into your system prompt or a dedicated analysis step, replace the square-bracket placeholders with real data, and run it against a model capable of structured reasoning—GPT-4o, Claude 3.5 Sonnet, or equivalent.

textCopy
You are an instruction priority auditor. Your job is to detect when a lower-priority instruction overrides a higher-priority one during execution, explain why it happened, and propose a repair.

## INPUT

### Declared Priority Stack (highest to lowest)
[PRIORITY_STACK]

### Active Instructions at Runtime
[ACTIVE_INSTRUCTIONS]

### Observed Behavior (the output or action that suggests an inversion)
[OBSERVED_BEHAVIOR]

### Execution Context (user request, tool calls, conversation history)
[EXECUTION_CONTEXT]

## TASK

1. Identify which lower-priority instruction overrode which higher-priority instruction.
2. Explain the root cause. Consider:
   - Ambiguous or conflicting wording between the two instructions.
   - A user request that exploited a loophole in the higher-priority instruction.
   - A tool output that introduced new information the higher-priority instruction did not anticipate.
   - Positional effects where a later instruction weakened an earlier one.
   - Missing constraints in the higher-priority instruction.
3. Classify the severity: [CRITICAL | HIGH | MEDIUM | LOW]. Use [SEVERITY_RUBRIC] to decide.
4. Propose a repair. The repair must:
   - Strengthen the higher-priority instruction so it cannot be overridden by the identified lower-priority instruction.
   - Not break other behaviors unless explicitly noted.
   - Be specific: rewrite the instruction text, add a constraint, or insert an explicit precedence rule.
5. If the inversion was caused by a missing instruction, propose a new instruction to fill the gap.

## OUTPUT SCHEMA

Return a JSON object with this exact structure:
{
  "inversion_detected": true,
  "overriding_instruction": {
    "id": "string",
    "text": "string",
    "declared_priority": "string"
  },
  "overridden_instruction": {
    "id": "string",
    "text": "string",
    "declared_priority": "string"
  },
  "root_cause": "string",
  "severity": "CRITICAL | HIGH | MEDIUM | LOW",
  "repair": {
    "action": "REWRITE | ADD_CONSTRAINT | INSERT_PRECEDENCE_RULE | ADD_INSTRUCTION",
    "target_instruction_id": "string",
    "original_text": "string",
    "repaired_text": "string",
    "rationale": "string"
  },
  "confidence": 0.0-1.0
}

## CONSTRAINTS

- Do not invent instructions that were not in the input.
- If no inversion is detected, set "inversion_detected" to false and leave the other fields as empty strings or nulls.
- If multiple inversions exist, report the most severe one. Note in "root_cause" that additional inversions may exist.
- Base severity on [SEVERITY_RUBRIC].
- The repair must be a single, specific change. Do not propose a full system prompt rewrite.

Adaptation notes: Replace [PRIORITY_STACK] with the ranked list of instruction IDs and their priorities as defined in your system prompt. [ACTIVE_INSTRUCTIONS] should contain the full text of every instruction that was active when the inversion occurred—this is often a subset of the full system prompt. [OBSERVED_BEHAVIOR] is the model's actual output or tool call that violated the priority order. [SEVERITY_RUBRIC] should be a short inline definition of your severity levels, such as: "CRITICAL: safety policy violated; HIGH: core product behavior broken; MEDIUM: degraded experience; LOW: cosmetic inconsistency." If you are integrating this into a monitoring pipeline, wire the output JSON into your observability stack and trigger alerts on CRITICAL and HIGH severity inversions. For high-risk domains, always route the repair proposal to a human reviewer before applying it to production system prompts.

This prompt is designed to operate as a scheduled or event-driven diagnostic within your AI operations stack, not as a real-time interceptor on the critical path. The primary integration point is a monitoring service that periodically samples recent conversation traces, tool-call logs, or system prompt configurations and submits them to the model for analysis. The prompt expects a structured [INPUT] containing the active instruction set, the observed model behavior, and the specific directives that appear to have collided. Because the output is a structured inversion report, you should wrap the model call in a harness that validates the JSON schema before the report is routed to an on-call engineer or a policy dashboard. Do not use this prompt to automatically rewrite system instructions in production; the repair suggestions are advisory and must pass through a human review and change management process before deployment.

The implementation harness should enforce a strict validate-then-log pattern. After receiving the model's response, validate that the inversion_report object contains all required fields: detected_inversions (array), root_cause_analysis (string), repair_suggestions (array), and severity (enum of LOW, MEDIUM, HIGH, CRITICAL). If validation fails, retry once with a repair prompt that includes the schema errors. Log every invocation—including the raw input, the validated output, and the retry count—to a structured logging system indexed by trace_id and timestamp. For HIGH or CRITICAL severity inversions, the harness should automatically create an incident ticket and notify the AI reliability channel. For LOW severity findings, aggregate them into a weekly report. This prevents alert fatigue while ensuring that silent policy violations are not ignored. The model choice matters: use a model with strong instruction-following and structured output capabilities, such as gpt-4o or claude-3.5-sonnet, and set a low temperature (0.1–0.2) to maximize consistent schema adherence.

When integrating this prompt into a CI/CD pipeline for system prompt releases, run it as a pre-deployment gate against a golden dataset of known instruction conflicts and expected priority outcomes. If the prompt detects a new inversion or fails to detect a known one, block the release and flag the diff for review. Avoid wiring this prompt directly to an automated rollback mechanism; the root cause analysis is probabilistic and should be confirmed by a human operator before any production system prompt is modified. The most common failure mode in production is a false positive where the model reports an inversion that is actually an intentional policy override documented in a runbook. To mitigate this, maintain a suppression list of known acceptable overrides and cross-reference the inversion report against it before alerting. This harness turns the prompt from a one-off diagnostic into a reliable, auditable component of your AI reliability engineering practice.