Context Conflict Repair Loop Prompt Template

This prompt is for production AI engineers who need an automated, bounded repair loop when a primary assistant or agent output fails context conflict validation. The core job-to-be-done is not just detecting a conflict, but attempting a structured repair with a clear termination condition. Use this when your system has already classified a conflict (e.g., a user correction contradicting prior instructions, or retrieved evidence clashing with session state) and a validator has rejected the initial response. The ideal user is integrating this into an orchestration layer where a failed validation triggers this repair prompt, not a human manually pasting it into a chat interface.

The prompt requires several concrete inputs to function safely: the original user input that triggered the conflict, the conflicting context elements (e.g., prior turns, retrieved documents, system policies), the validator's specific rejection reason, and a strict [MAX_REPAIR_ATTEMPTS] integer. It is designed to produce a single repair attempt per invocation. Your application harness must manage the loop counter, feed the previous failed attempt and rejection reason back into the [PRIOR_FAILED_OUTPUT] and [VALIDATOR_FEEDBACK] placeholders, and halt the loop if the counter exceeds the limit. Do not use this prompt for open-ended conversational refinement; it is a targeted repair tool for a known, classified conflict.

Avoid this prompt when the conflict is ambiguous or unclassified. If you haven't run a dedicated conflict detection step first, you risk the model inventing a conflict to repair or over-correcting a valid output. Similarly, do not use this for safety policy violations where the correct action is a hard refusal and escalation, not a repair attempt. The repair loop should be reserved for resolvable semantic or factual conflicts. The next step after implementing this prompt is to pair it with a loop harness that enforces a strict retry budget, logs every repair attempt for auditability, and escalates to a human review queue if the loop exhausts its retries without passing validation.

This template implements a controlled repair loop for context conflicts. It takes a detected conflict, the current session state, and any relevant evidence or policy, then produces a repair attempt. The prompt is designed to be called iteratively by an application harness that enforces retry limits, validates output quality, and escalates when repairs fail or degrade. Use this template when you need the model to propose a specific fix—not just classify the conflict—and when you must guard against infinite repair loops in production.

textCopy
You are a context conflict repair agent. Your job is to resolve a detected conflict in the current conversation session by producing a single repair attempt. You must follow the repair strategy, respect all constraints, and output a structured result that can be validated by the calling system.

## CONFLICT TO REPAIR
[CONFLICT_DETAILS]

## CURRENT SESSION STATE
[SESSION_STATE]

## RELEVANT EVIDENCE OR POLICY
[EVIDENCE_OR_POLICY]

## REPAIR STRATEGY
[REPAIR_STRATEGY]

## CONSTRAINTS
- Do not modify context elements that are not part of the conflict.
- Preserve all unchanged session state exactly as provided.
- If the conflict involves a user correction, accept the user's latest explicit instruction as authoritative unless it violates a hard system policy.
- If the conflict involves retrieved evidence vs. session context, prefer the most recent verified evidence unless the user has explicitly overridden it.
- Do not hallucinate facts, sources, or user statements not present in the inputs.
- If you cannot resolve the conflict with the information provided, set `resolution_status` to `"unresolved"` and explain what is missing.

## OUTPUT SCHEMA
Return a single JSON object with exactly these fields:
{
  "resolution_status": "resolved" | "unresolved" | "partial",
  "repair_description": "string explaining what was changed and why",
  "updated_session_state": { /* full session state object with conflict resolved */ },
  "affected_context_keys": ["list of state keys that were modified"],
  "unchanged_context_keys": ["list of state keys confirmed unchanged"],
  "confidence": 0.0-1.0,
  "requires_user_confirmation": true | false,
  "escalation_reason": "string or null if not escalating",
  "repair_attempt_number": [ATTEMPT_NUMBER]
}

## REPAIR ATTEMPT CONTEXT
This is repair attempt [ATTEMPT_NUMBER] of [MAX_ATTEMPTS]. Previous failed attempts and their rejection reasons are listed below. Do not repeat a repair that was already rejected.

[PREVIOUS_ATTEMPTS]

Adaptation guidance: Replace each square-bracket placeholder with values injected by your application harness. [CONFLICT_DETAILS] should contain the structured conflict classification from your detection step. [SESSION_STATE] must be the complete, machine-readable state object. [EVIDENCE_OR_POLICY] includes retrieved documents, system policies, or user preference records relevant to the conflict. [REPAIR_STRATEGY] can be a fixed instruction like "accept user correction and roll back dependent state" or a dynamically selected strategy based on conflict type. [ATTEMPT_NUMBER] and [MAX_ATTEMPTS] are integers injected by the harness to give the model awareness of retry budget. [PREVIOUS_ATTEMPTS] should contain a summary of prior repair attempts and the validator's rejection reasons, preventing the model from looping on the same broken fix.

What to do next: Wire this prompt into a harness that validates the output schema, checks that updated_session_state is structurally valid, compares affected_context_keys against the expected scope, and rejects repairs that modify too much or too little. If resolution_status is "unresolved" or confidence falls below your threshold, either retry with a different strategy or escalate to human review. Never allow the repair loop to exceed [MAX_ATTEMPTS] without forced escalation—unbounded repair loops are a production incident waiting to happen.

The Context Conflict Repair Loop Prompt Template is not a single fire-and-forget call. It is a retry controller that sits inside a repair loop in your application code. The application calls the model with the repair prompt, validates the output, checks termination conditions, and decides whether to retry, fall back, or escalate. The prompt itself produces a repair attempt and a loop-control signal, but the harness enforces the hard limits that prevent infinite repair cycles and degraded output quality.

Loop architecture. The harness should implement a bounded retry loop with these components: (1) a maximum repair attempt counter (start at 2–3 for most production systems; never exceed 5 without human-in-the-loop gating); (2) a repair quality validator that checks whether the repaired output is actually better than the previous attempt—if quality degrades, terminate the loop and escalate; (3) a loop termination detector that parses the model's loop_decision field (RETRY, FALLBACK, ESCALATE, or TERMINATE) and enforces it; (4) a state tracker that accumulates repair history so the model sees what was tried before; and (5) a timeout guard that kills the loop if total repair latency exceeds a threshold (e.g., 10 seconds for real-time copilots, 30 seconds for async workflows).

Validation and quality gates. After each repair attempt, run structured checks before deciding to retry. Validate that the output conforms to the expected schema (if the repair broke JSON structure, do not retry—escalate). Check that the conflict classification is consistent with the repair action (a SEVERE conflict with a trivial text edit is a mismatch). Compare the repaired output against the original using a lightweight eval: did the repair actually resolve the conflicting elements identified in the conflict report? If the model claims resolution but the conflicting claims still appear in the output, increment a repair-failure counter and consider fallback. Log every repair attempt with the attempt number, conflict report, repair action, validation result, and loop decision. These logs are essential for tuning retry limits and detecting systemic repair failures.

Model choice and tool integration. The repair loop prompt works best with models that have strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro). Avoid running repair loops on smaller or faster models that may produce syntactically valid but semantically empty repairs. If your primary generation model is a smaller model, route repair attempts to a larger model as a repair escalation path. For RAG-augmented systems, the harness should re-retrieve evidence if the conflict report indicates stale or missing context before calling the repair prompt again—do not ask the model to repair with bad evidence. If the conflict involves tool outputs, the harness should consider re-running the tool with corrected parameters rather than asking the model to paper over tool errors.

Escalation and human review. When the loop terminates with ESCALATE or exhausts its retry budget, the harness must have a clear handoff path. For internal copilots, this might mean surfacing the conflict summary and repair history to the user with a clear prompt: 'I detected a conflict between your earlier instruction and the retrieved document. Here's what I found. How would you like me to proceed?' For automated agent pipelines, escalation might mean writing a structured incident record to a review queue, pausing the workflow, and notifying an on-call engineer. Never silently fall back to a degraded output without signaling that a conflict was detected and could not be automatically resolved. The repair loop's job is to try automated fixes within safe bounds; the harness's job is to know when to stop trying and ask for help.