Citation Recovery Harness Integration Prompt

This prompt is for platform engineers and AI reliability teams building automated citation recovery pipelines. Use it when a generated answer has failed citation validation and you need to orchestrate multiple recovery strategies in sequence with validation gates between each step. The prompt acts as a harness controller: it receives a failed answer, its evidence context, and the specific validation errors, then selects and executes the appropriate recovery strategy from a defined playbook. It is designed for systems where unattributed or hallucinated claims create compliance risk, erode user trust, or violate product requirements.

Do not use this prompt for initial answer generation or for single-step retry workflows. It assumes you already have a cited answer that failed validation and need a multi-strategy recovery pipeline with observability trace generation. The ideal user is an engineer integrating this into a production RAG pipeline where citation failures must be resolved programmatically before the answer reaches the end user. Required context includes the original failed answer, the retrieved evidence passages, the specific validation error types and locations, and a configured recovery strategy playbook with defined escalation thresholds.

Before deploying this prompt, ensure your pipeline has clear validation gates between recovery steps. Each strategy attempt should produce a trace record documenting which strategy was used, what changed, and whether the subsequent validation passed. Set a retry budget—typically 3-5 attempts across different strategies—before escalating to human review or returning an abstention response. The prompt works best when paired with structured validation outputs that identify specific failure modes (missing citations, unsupported claims, quote inaccuracies) rather than binary pass/fail signals, enabling the harness to route to the most appropriate recovery strategy.

This prompt template is the core instruction set for a citation recovery harness. It expects a previously generated answer, the source evidence pool, and a configurable recovery plan. The harness iterates through recovery strategies in order—missing citation insertion, unsupported claim correction, quote accuracy verification, and source conflict resolution—with a validation gate after each step. If a step produces a passing validation score, the harness stops and returns the corrected answer. If all steps fail, it escalates to the configured fallback behavior. Use this template when you need a single, auditable recovery pipeline rather than ad-hoc retry prompts.

textCopy
You are a citation recovery harness orchestrator. Your job is to apply recovery strategies in sequence to a generated answer that failed citation validation, stopping when a strategy produces a passing result.

## INPUTS
- ORIGINAL_ANSWER: [ORIGINAL_ANSWER]
- SOURCE_EVIDENCE: [SOURCE_EVIDENCE]
- VALIDATION_FAILURES: [VALIDATION_FAILURES]
- RECOVERY_PLAN: [RECOVERY_PLAN]
- MAX_RETRY_BUDGET: [MAX_RETRY_BUDGET]
- ESCALATION_POLICY: [ESCALATION_POLICY]
- OUTPUT_SCHEMA: [OUTPUT_SCHEMA]

## RECOVERY PLAN STRUCTURE
The RECOVERY_PLAN is an ordered list of recovery steps. Each step has:
- step_id: unique identifier
- strategy: the recovery strategy to apply
- validation_gate: criteria that must pass for this step to be considered successful
- max_attempts: retries allowed for this step before moving to the next

## EXECUTION RULES
1. Process recovery steps in the order defined by RECOVERY_PLAN.
2. For each step, apply the strategy to the current state of the answer.
3. After applying a strategy, run the validation_gate check.
4. If validation passes, stop and return the corrected answer with trace.
5. If validation fails and max_attempts remain, retry the same strategy.
6. If max_attempts are exhausted, move to the next recovery step.
7. If all steps are exhausted without passing validation, apply ESCALATION_POLICY.
8. Track remaining retry budget from MAX_RETRY_BUDGET across all steps.
9. Do not modify SOURCE_EVIDENCE. Only modify the answer.
10. Every claim in the final answer must be traceable to SOURCE_EVIDENCE.

## VALIDATION GATE CRITERIA
A step passes validation when:
- All claims have at least one citation anchored to SOURCE_EVIDENCE.
- No claim contradicts another claim in the answer.
- Quoted text matches SOURCE_EVIDENCE exactly.
- No fabricated sources or citations appear.
- Citation confidence scores meet the threshold defined in the step.

## ESCALATION BEHAVIOR
Apply ESCALATION_POLICY when all recovery steps fail:
- If policy is "abstain": return an abstention message explaining what evidence was insufficient.
- If policy is "flag_for_review": return the best-effort answer with all citations flagged as low-confidence and a review request.
- If policy is "return_best": return the answer from the step with the highest partial validation score.

## OUTPUT FORMAT
Return a JSON object matching OUTPUT_SCHEMA with these fields:
- final_answer: the corrected answer or escalation output
- citations: array of citation objects with source_id, passage_reference, and confidence_score
- recovery_trace: array of step results showing which strategies ran, their outcomes, and remaining budget
- escalation_triggered: boolean
- remaining_budget: integer

Adapt this template by replacing each square-bracket placeholder with concrete values from your pipeline. [ORIGINAL_ANSWER] should be the full text that failed citation validation. [SOURCE_EVIDENCE] must be the complete evidence pool as structured objects with source IDs and passage text—do not summarize or truncate. [VALIDATION_FAILURES] should list the specific checks that failed, such as ["missing_citation", "unsupported_claim"], so the harness can prioritize matching strategies. [RECOVERY_PLAN] is the most critical configuration: define your strategy sequence based on your failure mode taxonomy. A typical plan starts with inline citation insertion, then unsupported claim correction, then quote verification, and finally source conflict resolution. Each step's validation_gate should reference measurable criteria, not subjective judgments. Set [MAX_RETRY_BUDGET] to a hard limit—5 to 7 total retries across all steps is a reasonable starting point for most production systems. [ESCALATION_POLICY] must be one of the three defined behaviors; choose based on your tolerance for unverified answers reaching users.

Before deploying this prompt, wire the validation gates to real evaluation functions. The harness prompt describes what validation looks like, but your application code must actually run those checks—citation coverage counting, quote exact-match comparison, source existence verification, and contradiction detection. The harness prompt orchestrates strategy selection and sequencing; it does not replace your evaluation infrastructure. Test the full pipeline with golden datasets that include known citation failures, and measure whether the harness converges on correct answers within the retry budget. If recovery steps routinely exhaust the budget without passing validation, your evidence pool may be insufficient or your validation thresholds may be too strict. Adjust the plan sequence or thresholds before increasing the budget.

The Citation Recovery Harness Integration Prompt is not a standalone prompt—it is an orchestrator designed to sit inside a recovery pipeline that sequences multiple citation-repair strategies. The harness receives a failed answer, its associated evidence set, and a failure signature (e.g., missing citations, unsupported claims, quote inaccuracies). It then selects and executes recovery prompts in a defined order, validates the output of each step, and either proceeds to the next strategy or escalates. Implementation requires wrapping this prompt in application logic that manages state, enforces retry budgets, and logs every decision for observability.

Wire the harness as a state machine with explicit gates between recovery stages. Each stage calls a specific recovery prompt (e.g., Missing Citation Retry, Unsupported Claim Correction, Quote Accuracy Verification) and passes the output through a validator before advancing. The validator should check citation coverage, source-to-claim alignment, and quote fidelity using structured scoring functions—not just model-graded evals. If a stage passes, the harness moves to the next recovery strategy or returns the repaired answer. If a stage fails, the harness increments a retry counter, logs the failure mode, and either retries with adjusted parameters or routes to the next fallback strategy. A hard retry budget (e.g., 3 total recovery attempts across all stages) prevents infinite loops. When the budget is exhausted, the harness must escalate to a human review queue with the full trace attached.

Observability is critical. Every harness execution should produce a structured trace that includes: the original failed answer, the failure signature that triggered recovery, which recovery strategies were attempted, the output and validation score of each stage, retry counts, and the final disposition (repaired, abstained, or escalated). Log these traces to your existing observability platform and tag them with citation_recovery_harness for aggregation. Use these traces to tune your recovery strategy ordering—if Quote Accuracy Verification consistently catches failures that Missing Citation Retry misses, reorder the pipeline. Avoid running the harness on every answer; gate it behind a pre-check that detects citation issues so you only pay the latency and token cost when recovery is needed.