Retry Budget for Hallucination Self-Correction Prompt

This prompt is a recovery and escalation control mechanism, not a primary answer generator. Its job is to act as a strict verifier within a retry loop after an initial model response has been flagged for containing unsupported claims. The ideal user is an AI product team that has already built a reliable hallucination detection mechanism—such as an LLM judge, a claim extraction pipeline, or a source-grounding validator—and now needs a predictable, cost-controlled way to attempt self-correction before falling back to human review. The required context includes the original user query, the flagged model response, the source evidence that should have grounded the answer, and the remaining retry budget as an integer.

You should use this prompt when the cost of a hallucination is high—for example, in clinical documentation, legal research, or financial audit summaries—and when you have a defined human review queue ready to receive escalations. The prompt enforces a hard limit on regeneration attempts by embedding the remaining budget directly into the instructions. When the budget reaches zero, the model is forced to output a structured escalation payload instead of another answer attempt, preventing infinite loops and unbounded latency. Do not use this prompt if you lack a reliable hallucination detector, as feeding false positives into the loop will degrade user experience without improving accuracy. It is also inappropriate for low-stakes creative or conversational tasks where a human review queue would be overkill.

Before integrating this prompt, ensure your harness tracks the retry budget per request, injects the current budget value into the [RETRY_BUDGET_REMAINING] placeholder, and can parse the structured escalation payload when the budget is exhausted. The next step is to pair this prompt with an eval suite that measures factual drift across retries—checking whether corrections introduce new unsupported claims—and to set a maximum budget based on your latency and cost tolerance. Avoid using this prompt as a substitute for improving your initial answer-generation prompt or your retrieval quality; it is a safety net, not a foundation.

The following prompt template is designed to be injected as a system message on a retry attempt after a hallucination has been detected by an upstream validator. Its job is to force the model to regenerate its response by strictly grounding every factual claim in the provided [CONTEXT] and to self-audit its own output. The prompt enforces a hard retry budget: if the model cannot produce a fully grounded response within the allowed attempts, it must output a structured escalation payload instead of another hallucinated answer. This prevents infinite correction loops and ensures that unresolved failures reach a human reviewer with complete diagnostic information.

textCopy
You are a fact-correction assistant operating under a strict retry budget.

## RETRY STATE
- Current attempt: [RETRY_ATTEMPT_NUMBER] of [MAX_RETRY_ATTEMPTS]
- Previous failure reason: [PREVIOUS_FAILURE_REASON]

## INPUT
User query: [USER_QUERY]
Previous response that was flagged for hallucination: [PREVIOUS_RESPONSE]

## GROUNDING CONTEXT
Use ONLY the following context to answer. If the context is insufficient, state that explicitly.
[CONTEXT]

## INSTRUCTIONS
1. Cross-check every factual claim in the previous response against the context above.
2. Identify and discard any claim that cannot be directly attributed to the context.
3. Generate a new response that contains ONLY claims supported by the context.
4. For each factual statement in your new response, append a citation tag referencing the specific source chunk in the context (e.g., [Source: chunk-3]).
5. If the context does not contain enough information to answer the user query, respond with: "INSUFFICIENT_CONTEXT: [explanation of what is missing]"
6. If you cannot produce a fully grounded response, do not guess. Instead, output the escalation format below.

## ESCALATION CONDITION
If this is the final allowed attempt (attempt [MAX_RETRY_ATTEMPTS]) and you still cannot produce a fully grounded response, you MUST output ONLY the following JSON and nothing else:
{
  "status": "ESCALATE_TO_HUMAN",
  "retry_attempts_exhausted": [MAX_RETRY_ATTEMPTS],
  "user_query": "[USER_QUERY]",
  "failure_summary": "[Concise description of why grounding failed across all attempts]",
  "last_ungrounded_claims": ["[Claim 1 that could not be verified]", "[Claim 2]"]
}

## OUTPUT FORMAT
- If grounded: Provide the answer with inline citations.
- If insufficient context: Output "INSUFFICIENT_CONTEXT" with an explanation.
- If escalating: Output ONLY the JSON object above.

To adapt this template, replace the square-bracket placeholders with values from your application's retry harness. [RETRY_ATTEMPT_NUMBER] and [MAX_RETRY_ATTEMPTS] should be injected by your orchestration layer, not the model. [PREVIOUS_FAILURE_REASON] should contain the specific output from your hallucination detector (e.g., "Claim 'Revenue grew 20%' not found in context"). [CONTEXT] must be the exact set of retrieved documents or source chunks that the model is permitted to use. The escalation JSON schema should match the contract expected by your human review queue or incident management system. For high-risk domains such as healthcare or finance, ensure that the escalation payload includes a full trace of all previous attempts and that the human reviewer is clearly instructed not to rely on any ungrounded claims from the retry history.

The retry budget prompt is not a standalone script; it is a decision node inside a retry loop. The application harness must track the number of correction attempts, the cumulative cost or latency incurred, and the quality delta between each regeneration. Before invoking the prompt, the harness should inject the current attempt count, the maximum budget, the original context, the previous output, and any validator feedback into the prompt's placeholders. The prompt returns a structured decision—retry, escalate, or accept—which the harness must enforce without allowing the model to override the budget limits.

A concrete implementation wraps the prompt in a retry controller with these responsibilities: (1) maintain an atomic counter for attempts and a stopwatch for wall-clock budget; (2) call a factuality validator (e.g., an NLI model or a citation-overlap check) after each generation to produce structured error feedback; (3) inject [ATTEMPT_NUMBER], [MAX_ATTEMPTS], [PREVIOUS_OUTPUT], [VALIDATION_ERRORS], and [CONTEXT] into the prompt; (4) parse the model's JSON decision (action, rationale, confidence) and enforce it. If the model returns action: escalate or the attempt counter exceeds the budget, the harness must package the full retry history into an escalation payload and route it to a human queue or a fallback model. Log every attempt's input, output, validator score, and decision for auditability.

Validation and safety checks are critical. Before accepting a self-corrected output, run a regression check: compare the new output's factual claims against the original context to detect factual drift introduced during correction. A common failure mode is the model inventing new details to satisfy the validator while drifting further from the source. If the validator score does not improve across two consecutive retries, the harness should force escalation regardless of remaining budget. For high-stakes domains, require human approval on any output that required more than one correction attempt, even if the validator passes. Wire the escalation payload to include the original query, all retry outputs, validator scores, and the model's own rationale for each attempt so the human reviewer has full context.