Retry Budget for Citation Recovery Prompt

This prompt is a targeted recovery mechanism for RAG systems where a downstream citation validator has programmatically detected a failure in the initial output. The failure modes it addresses are specific: missing citations for factual claims, citations that do not support the associated statement, or a complete absence of source grounding. It is not a general-purpose question-answering prompt. Its sole job is to act as a self-correction instruction within a controlled retry loop, instructing the model to repair its previous response using the validator's specific error message as context. The primary users are product teams and AI engineers who have already built a RAG pipeline and a citation validator, and who now need to manage the cost and latency of automatic recovery without allowing the system to guess indefinitely.

You should integrate this prompt into your application's retry logic, not use it as a standalone chat instruction. The ideal implementation involves a harness that catches a validation failure, injects the failure reason and the remaining retry budget into this prompt's [PREVIOUS_FAILURE_REASON] and [RETRY_BUDGET_REMAINING] placeholders, and resubmits the original query and context. The prompt enforces a strict budget; it instructs the model to make a limited number of repair attempts, each with a stricter mandate to ground every claim. This is crucial for preventing infinite loops where a model repeatedly generates unsupported text. For example, if your validator flags 'Claim in sentence 3 has no supporting citation,' that exact string becomes the [PREVIOUS_FAILURE_REASON], giving the model a concrete target for correction rather than a vague instruction to 'be more accurate.'

Do not use this prompt when the initial failure is due to a lack of relevant context in your retrieval step. If the knowledge base simply doesn't contain the answer, no amount of regeneration will produce a properly cited response. In that case, the correct behavior is an early exit to a 'no answer found' or human escalation path, not a retry loop. Similarly, avoid this prompt for non-citation failures like malformed JSON or incorrect tone, which require different repair strategies. The next step after understanding this use case is to review the implementation harness section, which details how to wire this prompt into a retry loop with a hard budget, a validator, and a safe fallback that prioritizes source-grounded statements over fluent but unsupported prose.

This prompt template acts as the system or developer message in a retry loop for RAG-generated answers with citation failures. It receives the previous failed output and the specific validator error (e.g., missing citations, unsupported claims, hallucinated sources) as context. The prompt instructs the model to attempt citation repair within a strict attempt budget, and to produce a structured escalation payload if the budget is exhausted, rather than continuing to generate unverifiable text. Use this when your application's citation validator has rejected an answer and you need a controlled recovery path that prevents infinite regeneration loops.

textCopy
You are a citation-repair assistant operating under a strict retry budget. Your task is to correct citation errors in a previously generated answer without introducing new unsupported claims.

## INPUTS
- Original user query: [USER_QUERY]
- Retrieved source documents (with source IDs): [RETRIEVED_DOCUMENTS]
- Previous failed answer: [PREVIOUS_ANSWER]
- Validator error details: [VALIDATOR_ERROR]
- Current retry attempt number: [ATTEMPT_NUMBER]
- Maximum allowed retry attempts: [MAX_ATTEMPTS]

## CONSTRAINTS
1. Every factual claim in your answer MUST be supported by at least one citation to a source ID from [RETRIEVED_DOCUMENTS].
2. Do not fabricate, paraphrase, or infer details not explicitly present in the retrieved documents.
3. If a claim cannot be supported by any retrieved document, you MUST either remove the claim or explicitly state that the retrieved sources do not contain that information.
4. Citations must use the format `[Source: <source_id>]` immediately after the supported claim.
5. Do not repeat the validator error pattern described in [VALIDATOR_ERROR].

## RETRY BUDGET LOGIC
- If [ATTEMPT_NUMBER] is less than [MAX_ATTEMPTS]: Produce a corrected answer with proper citations. Start your response with the phrase "CORRECTED ANSWER (Attempt [ATTEMPT_NUMBER]/[MAX_ATTEMPTS]):".
- If [ATTEMPT_NUMBER] equals [MAX_ATTEMPTS]: Do NOT produce another answer. Instead, produce a structured escalation payload. Start your response with "RETRY BUDGET EXHAUSTED. ESCALATION PAYLOAD:" followed by a JSON object containing:
  - "escalation_reason": A concise summary of why citation repair failed after [MAX_ATTEMPTS] attempts.
  - "original_query": The [USER_QUERY].
  - "last_failed_answer": The [PREVIOUS_ANSWER].
  - "persistent_validator_error": The [VALIDATOR_ERROR] from the final attempt.
  - "recommended_fallback_action": A suggestion, such as "Route to human reviewer", "Use source-grounded fallback response", or "Return answer with explicit unsupported-claim disclaimers".

## OUTPUT SCHEMA
Your entire response must be either a corrected answer with citations or the escalation JSON. No other text.

To adapt this template, replace the square-bracket placeholders with values from your application's retry harness. The [VALIDATOR_ERROR] should contain the specific, actionable feedback from your citation-checking validator (e.g., 'Claim about Q3 revenue lacks a source citation', 'Source ID 4 does not contain the quoted figure'). The [RETRIEVED_DOCUMENTS] must include source IDs that the model can reference. Wire this prompt into a loop that increments [ATTEMPT_NUMBER] and checks the response prefix. If the response starts with 'CORRECTED ANSWER', validate it again. If it starts with 'RETRY BUDGET EXHAUSTED', parse the JSON and route to your escalation handler. Never allow the loop to exceed [MAX_ATTEMPTS]; the prompt's budget logic is a safety net, but your application code must also enforce the hard limit to guard against prompt injection or model non-compliance.

The retry budget for citation recovery is not a single prompt but a stateful loop managed by the application harness. The harness is responsible for tracking the number of repair attempts, evaluating each regenerated response against citation completeness and hallucination checks, and deciding whether to retry, fall back to a source-grounded summary, or escalate to human review. The model only sees the current repair instruction and context; it does not count its own attempts or enforce the budget. This separation is critical because models cannot reliably self-limit retries, and budget enforcement must be deterministic and auditable.

Implement the harness as a loop with a configurable max_citation_repair_attempts parameter (start with 3). On each iteration: (1) send the original query, retrieved context, and the previous failed response with specific citation errors to the repair prompt; (2) validate the regenerated response using a structured eval that checks for citation_present (boolean per claim), citation_supported (boolean per citation), and hallucination_flag (boolean if any claim lacks source grounding); (3) if all checks pass, return the response; (4) if checks fail and attempts remain, increment the counter and retry with the specific failure details appended to the repair instruction; (5) if the budget is exhausted, execute the escalation path. Log every attempt with the attempt number, error types, and eval results for debugging and audit trails.

The escalation path must not silently degrade. When the retry budget is exhausted, the harness should either: (a) fall back to a source-grounded response that explicitly marks unsupported claims with [CITATION NOT FOUND] and removes hallucinated content, or (b) queue the request for human review with a structured payload containing the original query, retrieved context, all repair attempts, and the specific citation failures that persisted. Never return a response that appears fully cited when the budget was exhausted—this creates a false sense of reliability. For high-stakes domains, require human approval before surfacing any response that exhausted the citation repair budget.