Contradictory Instruction Resolution Prompt

This prompt is designed for AI assistant and copilot builders who need to handle a specific, high-stakes production failure mode: a user changes their mind mid-session, issuing a new instruction that directly contradicts a prior one. The job-to-be-done is not just to follow the latest command, but to explicitly detect the conflict, model the user's updated intent, construct a transparent rationale, and seek confirmation before silently overwriting the prior state. The ideal user is an engineering lead or developer integrating this into a task-oriented agent, customer support bot, or any multi-turn system where silently discarding prior context erodes user trust or violates business logic.

You should use this prompt when the cost of getting the resolution wrong is high. This includes scenarios where the prior instruction triggered a multi-step plan, a tool execution, or a database write. The prompt requires a structured input containing the full session history, the specific contradictory turns, and any non-negotiable system constraints. It is not suitable for simple, stateless Q&A or single-turn instruction following. Do not use this prompt if your application can safely adopt a 'last instruction wins' policy without consequence, or if the latency introduced by a confirmation step is unacceptable for your real-time use case.

Before integrating this prompt, ensure your application harness can surface the conflict to the user and pause execution for confirmation. The prompt's output is a structured intent model and a confirmation request, not a final action. The next step is to wire this output into a human-in-the-loop review or a strict confirmation gateway in your agent's execution loop. Avoid the common failure mode of deploying this prompt and then auto-accepting its output, which defeats its purpose and creates a silent, complex state corruption.

This prompt template is designed to be copied directly into your prompt management system, IDE, or orchestration layer. It accepts the current session state, the new user message, and your system constraints, then produces a structured resolution that includes an updated intent model, a rationale for the change, and a confirmation request to present to the user. The template uses square-bracket placeholders that you must replace with your application's actual values before sending the request to the model.

textCopy
You are an assistant that detects and resolves contradictory instructions from users during an ongoing session. Your job is to identify when a new user message conflicts with prior instructions, determine which instruction should take precedence, and produce a structured resolution that the application can use to update state and confirm with the user.

## INPUTS

### Session Context
[SESSION_CONTEXT]

### New User Message
[USER_MESSAGE]

### System Constraints
[SYSTEM_CONSTRAINTS]

### Precedence Rules
[PRECEDENCE_RULES]

## INSTRUCTIONS

1. Compare the new user message against all prior instructions, goals, constraints, and commitments in the session context.
2. If no conflict exists, respond with `"conflict_detected": false` and an empty resolution.
3. If a conflict exists, identify:
   - The specific prior instruction or commitment being contradicted.
   - The new instruction that conflicts with it.
   - The type of conflict: direct_override, priority_shift, constraint_violation, or scope_change.
4. Apply the precedence rules to determine which instruction wins.
5. If the precedence rules do not clearly resolve the conflict, flag for human clarification.
6. Produce a resolution that includes:
   - The updated intent model reflecting the winning instruction.
   - A clear rationale explaining why this instruction takes precedence.
   - Any state elements that must be rolled back or invalidated.
   - A confirmation message to present to the user before applying the change.

## OUTPUT SCHEMA

Return a valid JSON object with this exact structure:

{
  "conflict_detected": boolean,
  "conflict_type": "direct_override" | "priority_shift" | "constraint_violation" | "scope_change" | null,
  "conflicting_elements": [
    {
      "prior_instruction": "string",
      "new_instruction": "string",
      "source_turn": number | null
    }
  ],
  "resolution": {
    "winning_instruction": "string",
    "precedence_rationale": "string",
    "rolled_back_state": ["string"],
    "unchanged_state": ["string"],
    "updated_intent_model": {
      "primary_goal": "string",
      "active_constraints": ["string"],
      "pending_actions": ["string"]
    }
  },
  "confirmation_required": boolean,
  "confirmation_message": "string",
  "escalation_required": boolean,
  "escalation_reason": "string | null"
}

## CONSTRAINTS

- Do not apply the resolution silently. Always set `confirmation_required: true` when a conflict is detected.
- Do not fabricate prior instructions that do not appear in the session context.
- If the session context is empty or insufficient to detect conflict, set `conflict_detected: false`.
- If the conflict involves a safety or compliance constraint from [SYSTEM_CONSTRAINTS], the constraint always wins unless [PRECEDENCE_RULES] explicitly state otherwise.
- For `escalation_required: true`, provide a specific reason that a human reviewer can act on.
- Keep the confirmation message concise, specific, and neutral in tone. Do not apologize excessively.

## EXAMPLES

[EXAMPLES]

## RISK LEVEL

[RISK_LEVEL]

To adapt this template, replace each square-bracket placeholder with your application's live data. [SESSION_CONTEXT] should contain a structured representation of prior turns, active goals, constraints, and pending actions—not raw chat history. [PRECEDENCE_RULES] must encode your application's policy for resolving conflicts, such as 'most recent explicit user instruction wins unless it violates a system constraint' or 'safety constraints always override user preferences.' [EXAMPLES] should include at least two few-shot demonstrations: one showing a clear conflict resolution and one showing a non-conflict where the model correctly returns conflict_detected: false. [RISK_LEVEL] should be set to high if the assistant controls irreversible actions, medium if it controls reversible state changes, or low for read-only assistants. Before deploying, validate that the model reliably populates conflicting_elements with specific, traceable references to prior turns rather than vague summaries.

The Contradictory Instruction Resolution Prompt is not a standalone artifact; it is a stateful component that must be integrated into a session management layer. The application is responsible for maintaining a structured session state object that tracks the user's active instructions, their precedence, and the turn in which each was established. Before calling the model, the harness must extract the current instruction set and the new contradictory input, format them into the prompt's [PRIOR_INSTRUCTIONS] and [NEW_INPUT] placeholders, and inject any relevant [SYSTEM_CONSTRAINTS]. After the model responds, the harness must parse the structured output—typically an intent_model, conflict_rationale, and confirmation_request—and update the session state only after the conflict is resolved, not preemptively.

Validation is the critical safety net here. The harness must validate that the model's output contains all required fields and that the resolution_type is one of the allowed enum values (e.g., override, merge, clarify, escalate). A retry loop with a maximum of two attempts should be implemented for malformed JSON or missing fields, using a repair prompt that includes the raw output and the validation error. More importantly, implement a semantic check: compare the updated_intent against the PRIOR_INSTRUCTIONS to detect silent reversals where the model drops a prior instruction without explicit rationale. If a prior instruction is absent from the updated set and the conflict_rationale does not address it, flag the response for human review or force a clarify escalation. This prevents the most dangerous failure mode: the assistant quietly forgetting a user's earlier constraint.

Logging must capture the full conflict resolution event for auditability and debugging. Record the session ID, the turn numbers of the conflicting instructions, the raw prompt, the model's raw output, the validation result, and the final state update applied. For high-stakes domains, write an immutable audit record before applying the state change. Wire the harness to emit a context_conflict_resolved event that downstream systems can consume. When the resolution_type is escalate, the harness should not update the session state automatically; instead, it should enqueue a human review task and pause the conversation flow until the review is complete. Avoid the temptation to auto-resolve conflicts with low confidence scores—a confidence field below 0.7 should trigger a confirmation request to the user rather than a silent state mutation.