Factual Grounding Retry with Evidence Constraints Prompt

This prompt is a recovery step for high-stakes QA and RAG systems. Use it when a previous model response contained unsupported claims, hallucinated details, or assertions that could not be traced to the provided evidence. The prompt forces the model to regenerate the answer under a strict contract: every factual assertion must cite a specific source passage, and any territory without direct evidence support must trigger explicit abstention. This is not a first-pass generation prompt. It is a retry harness designed for compliance-sensitive domains such as legal research, clinical summarization, financial audit, and regulated customer support where an unsupported claim is a product defect.

The ideal user is an AI engineer or platform developer who has already observed a grounding failure in production or during evaluation. The required context includes the original user query, the set of retrieved evidence passages, and the previously generated response that failed validation. You should wire this prompt into a post-generation validation loop: a citation coverage check or a claim-to-source alignment evaluator flags the output, and this prompt is invoked as the first recovery step before escalating to human review. Do not use this prompt for creative writing, open-ended brainstorming, or tasks where factual precision is not the primary requirement—it will over-constrain the model and produce unnecessarily cautious outputs.

Before invoking this retry, confirm that the evidence passages provided are complete and relevant. If the retrieval step itself returned poor results, fix retrieval before applying grounding constraints—forcing a model to cite irrelevant passages produces brittle, misleading outputs. Set a retry budget: if this prompt fails to produce a fully grounded answer after two attempts, escalate to human review rather than looping indefinitely. In regulated workflows, log every retry attempt, the validator scores that triggered it, and the final grounded output for audit trails. The next section provides the copy-ready prompt template you can adapt to your evidence schema and output format requirements.

This template is designed to be the core instruction set for a retry harness that regenerates an answer after a grounding failure. It enforces a strict contract: every assertion must be directly traceable to the provided evidence, and the model must explicitly abstain from making claims that lack support. Use this when a previous model response contained hallucinations, missing citations, or unsupported inferences, and you need a corrected, fully grounded replacement.

textCopy
You are a strict factual grounding assistant. Your task is to regenerate an answer to the user's question under absolute evidence constraints.

## INPUT
- USER_QUESTION: [USER_QUESTION]
- PREVIOUS_FAILED_ANSWER: [PREVIOUS_FAILED_ANSWER]
- FAILURE_REASON: [FAILURE_REASON]
- EVIDENCE_SOURCES: [EVIDENCE_SOURCES]

## CONSTRAINTS
1. Every declarative statement you make MUST be directly and unambiguously supported by a passage in EVIDENCE_SOURCES.
2. For each claim, you MUST provide an inline citation in the format [Source: <source_id>].
3. If the EVIDENCE_SOURCES do not contain sufficient information to answer any part of the USER_QUESTION, you MUST explicitly state that you cannot answer that part and explain why the evidence is insufficient.
4. Do not infer, extrapolate, or use external knowledge. Your answer must be a strict synthesis of the provided text.
5. If the EVIDENCE_SOURCES contain conflicting information, you must present both sides, cite them, and state that a conflict exists. Do not choose a winner.

## OUTPUT FORMAT
Return a JSON object with the following schema:
{
  "answer": "The fully grounded answer with inline citations.",
  "abstentions": [
    {
      "question_part": "The specific part of the question you could not answer.",
      "reason": "Why the evidence was insufficient."
    }
  ],
  "conflicts": [
    {
      "claim_a": "First conflicting claim with citation.",
      "claim_b": "Second conflicting claim with citation.",
      "summary": "Brief description of the conflict."
    }
  ]
}

## RISK LEVEL
[RISK_LEVEL]

## ADDITIONAL CONTEXT
[ADDITIONAL_CONTEXT]

To adapt this template, replace the square-bracket placeholders with data from your application's retry context. [USER_QUESTION] is the original prompt. [PREVIOUS_FAILED_ANSWER] and [FAILURE_REASON] provide the model with the specific error it must correct, such as 'hallucinated source' or 'claim without citation.' [EVIDENCE_SOURCES] should be a pre-formatted string of your retrieved documents with clear source IDs. The [RISK_LEVEL] field is critical for high-stakes domains like healthcare or finance; set it to a value like 'HIGH' to reinforce the abstention policy. [ADDITIONAL_CONTEXT] can be used to inject domain-specific terminology or output length limits. After the model responds, your harness must parse the JSON and validate that every citation in the answer field maps to a valid ID in [EVIDENCE_SOURCES] before surfacing the result to the user or proceeding to the next step in the pipeline.

This prompt is not a standalone fix; it is a recovery step inside a larger harness. The harness should catch a primary generation failure—typically a validation error indicating unsupported claims or missing citations—and then invoke this retry prompt with the original question, the retrieved evidence, and the failed answer. The harness must supply the [EVIDENCE] placeholder with the exact retrieved passages, not summaries, because the prompt's constraint compliance depends on verbatim source access. The [FAILED_ANSWER] placeholder should contain the full previous model output so the retry prompt can contrast unsupported claims against the evidence.

Before calling the model, the harness should validate that [EVIDENCE] is non-empty and that [FAILED_ANSWER] contains at least one claim flagged as unsupported. If evidence is empty, skip the retry and escalate to a retrieval expansion workflow or human review. After receiving the retry output, run a constraint compliance evaluator: a separate LLM call or rule-based check that verifies every sentence in the regenerated answer is either (a) directly traceable to a provided evidence passage, or (b) an explicit abstention statement. Use a structured output schema for the evaluator—fields like claim, source_passage_id, match_type (direct|abstention|unsupported). Any unsupported match should either trigger one more retry with the specific violation fed back into [FAILED_ANSWER], or escalate to human review if the retry budget is exhausted.

Set a retry budget of 2-3 attempts for this prompt. Beyond that, the model is unlikely to converge on a fully grounded answer, and further retries waste latency and compute. Log every attempt with the retry index, the evaluator output, and the final disposition (grounded, partial_with_abstention, escalated). For high-stakes domains like healthcare or legal, always route escalated outputs to a human review queue with the evidence, the failed answers, and the evaluator trace attached. Model choice matters: use a model with strong instruction-following and long-context fidelity, such as claude-sonnet-4-20250514 or gpt-4o, because smaller models often drift from the strict traceability constraint after the first few sentences. Avoid using this prompt with models that have known hallucination tendencies under constraint pressure.