Citation Retry Budget and Escalation Prompt

This prompt is a circuit breaker for cited answer systems that have already exhausted individual recovery attempts. It is designed for reliability engineers and AI platform architects who need to stop infinite retry loops when a RAG pipeline repeatedly fails to produce properly cited output. The job-to-be-done is not to fix a single missing citation—that work belongs to upstream recovery prompts like Missing Citation Retry or Quote Accuracy Verification. Instead, this prompt evaluates the accumulated retry history, checks the remaining budget, and makes a binary decision: attempt one more structured recovery, fall back to a degraded but safe answer, or escalate to a human reviewer with a complete audit trail.

Use this prompt when you have a retry harness that has already attempted at least two citation recovery strategies and each has failed validation. The prompt requires a specific set of inputs to function: a retry history log showing each attempt, its strategy, and its failure reason; a remaining budget counter (in attempts, tokens, or latency milliseconds); the original user query and retrieved evidence; and the most recent failed answer with its validation report. Without this context, the prompt cannot make an informed escalation decision. It is not a general-purpose error handler and should not be used as the first or only recovery step in a pipeline.

Do not use this prompt when the failure is a single malformed citation that a targeted repair prompt can fix, when the system has no budget tracking in place, or when the cost of escalation exceeds the cost of a wrong answer. This prompt is also inappropriate for real-time chat systems where latency constraints preclude multi-step evaluation. The output is an auditable decision record—not a repaired answer—so downstream systems must be prepared to route the escalation, serve the fallback, or execute the final recovery attempt. Before deploying, ensure your harness can parse the structured decision, log it immutably, and trigger the corresponding workflow without human delay unless escalation is the chosen path.

This prompt template enforces a structured retry budget for citation recovery. It instructs the model to track the number of attempts, the specific failure mode on each attempt, and the escalation path when the budget is exhausted. Replace the square-bracket placeholders with your application's runtime values before sending the prompt to the model. The template is designed to be stateless from the model's perspective—your application harness must inject the current retry count and failure history.

textCopy
You are a citation recovery specialist operating within a strict retry budget. Your task is to correct citation errors in a generated answer based on the provided evidence passages.

## INPUT
- Original Answer: [ORIGINAL_ANSWER]
- Evidence Passages: [EVIDENCE_PASSAGES]
- Failure History: [FAILURE_HISTORY]
- Current Retry Count: [RETRY_COUNT] of [MAX_RETRIES]

## FAILURE MODE
[FAILURE_MODE]

## INSTRUCTIONS
1. Analyze the failure mode and the original answer against the evidence passages.
2. If the failure mode is recoverable and the retry budget has not been exhausted, produce a corrected answer with inline citations anchored to the evidence. Every factual claim must have a citation.
3. If the failure mode is unrecoverable or the retry budget is exhausted, do not produce a corrected answer. Instead, output an escalation record.

## OUTPUT SCHEMA
Respond with a single JSON object. Do not include any text outside the JSON.

If recovery is attempted:
{
  "action": "retry",
  "corrected_answer": "The corrected text with inline citations [1].",
  "citations": [{"index": 1, "source_passage_id": "doc_4_para_2"}],
  "changes_summary": "Brief description of what was fixed."
}

If escalation is required:
{
  "action": "escalate",
  "escalation_reason": "retry_budget_exhausted" | "unrecoverable_failure",
  "failure_summary": "Concise summary of the failure across all attempts.",
  "recommended_human_action": "What a human reviewer should check or do next."
}

## CONSTRAINTS
- Do not invent citations. If a claim cannot be supported by the evidence, remove it.
- Do not alter the semantic meaning of the original answer unless correcting a factual error.
- The retry budget is absolute. Do not attempt recovery if [RETRY_COUNT] equals [MAX_RETRIES].

To adapt this template, your application harness must track the retry count and failure history across attempts. The [FAILURE_MODE] placeholder should be populated from your validator's output—for example, missing_citation, unsupported_claim, or hallucinated_source. The [FAILURE_HISTORY] should be a serialized log of prior attempts and their outcomes, allowing the model to understand what has already been tried. Always validate the model's JSON output against the schema before proceeding. If the model returns malformed JSON, treat it as a retryable failure and increment the budget. For high-stakes domains, route all escalation records to a human review queue and log the full retry trace for auditability.

The Citation Retry Budget and Escalation Prompt is not a standalone fix—it is a control-plane component that governs how many times your citation recovery pipeline attempts self-correction before giving up. In a production cited-answer system, you will typically have a sequence of recovery prompts: missing citation insertion, unsupported claim correction, quote accuracy verification, and source-to-claim alignment. Each of these recovery steps can fail or produce partial improvements. This prompt sits above that sequence as a budget tracker and escalation router. It receives the current retry count, the failure history, the remaining budget, and the escalation policy, then decides whether to authorize another recovery attempt, switch to a different recovery strategy, or escalate to a human review queue.

To wire this into your application, implement a stateful retry orchestrator that maintains a retry_budget counter and a failure_log array. After each recovery attempt, run the output through your citation validators—checking for citation presence, source-to-claim alignment distance, quote fidelity, and hallucinated source detection. If any validator fails, append the failure details to the log and invoke this prompt with the updated state. The prompt should return a structured decision: continue with a recommended next recovery strategy, escalate with a reason code and human-readable summary for the review queue, or abort if the answer is irrecoverable. Parse this decision in your application code and route accordingly. Log every decision, the retry count, the validator results, and the prompt's reasoning to your observability platform for post-mortem analysis.

Validation gates between retries are critical. Do not simply retry blindly—each recovery attempt must be measured. Before invoking the budget prompt, run at minimum: a citation coverage check (are all factual claims cited?), a source alignment check (do citations point to the correct passages?), and a hallucinated-source detector (do all cited sources exist in the retrieval corpus?). Store these scores alongside the retry attempt. The budget prompt should receive these scores, not just pass/fail flags, so it can distinguish between a near-miss that warrants one more retry and a fundamental grounding failure that requires immediate escalation. Set a hard maximum retry budget per query—typically 2-4 attempts total across all recovery strategies—and enforce it in your orchestrator regardless of what the prompt recommends. This prevents prompt-level reasoning errors from causing infinite loops.

Human review integration requires a clean handoff contract. When the prompt returns escalate, your system should package the original query, the current answer state, the failure log, the validator scores, and the prompt's escalation reason into a review ticket. Do not send raw JSON to human reviewers. Use the prompt's human_summary field to generate a concise explanation of what went wrong and what the reviewer should focus on. Route tickets based on the escalation_reason code: unrecoverable_hallucination goes to content reviewers, source_conflict goes to knowledge base maintainers, budget_exhausted goes to the general review queue. Track time-to-resolution and use it to tune your retry budget thresholds over time.

Model choice matters here. This prompt performs a classification-and-routing task with structured output, so a smaller, faster model like GPT-4o-mini, Claude Haiku, or Gemini Flash is usually sufficient and keeps latency low. Reserve larger models for the actual recovery prompts that regenerate cited answers. If you observe the budget prompt making poor escalation decisions—escalating too early or authorizing retries that consistently fail—log those cases and consider fine-tuning a lightweight classifier on your specific failure patterns and escalation policies. Before deploying any changes to the retry budget logic, run regression tests against a golden dataset of known failure cases with expected escalation decisions to verify the prompt still routes correctly.