Sub-Question Answer Merging Prompt for Multi-Hop Synthesis

This prompt is the final stage in a multi-hop RAG pipeline. After your system has decomposed a complex question, executed a sequence of dependent retrieval queries, and collected answers for each sub-question, this prompt merges those intermediate answers into a single coherent final response. Use it when you need a synthesized answer that traces every claim back to its specific retrieval hop, exposes contradictions between sub-answers, and flags any integration gaps where the assembled evidence still does not fully answer the original question. The ideal user is a RAG pipeline operator or agent developer who already has a working query decomposition and retrieval execution layer and now needs reliable answer fusion with provenance tracking.

Do not use this prompt for single-hop retrieval answers, for generating the sub-questions themselves, or when the intermediate answers are already self-contained and require no cross-referencing. It is not a replacement for a query decomposition prompt, a retrieval execution engine, or a fact-verification step. If your pipeline produces only one retrieval result, or if the sub-answers are independent facts that can be listed without synthesis, this prompt adds unnecessary latency and token cost. The prompt assumes that each intermediate answer carries a hop identifier, source citations, and the retrieved evidence text. Without these inputs, the merging prompt cannot produce traceable provenance or detect contradictions reliably.

Before wiring this prompt into production, validate that your upstream decomposition and retrieval steps consistently produce structured intermediate answers with the fields this prompt expects: hop index, sub-question text, answer text, source citations, and confidence scores. Missing or malformed fields will cause the merge to fail silently or produce unsupported claims. For high-stakes domains such as healthcare, legal, or financial analysis, always route the merged output through a human review step and run an additional fact-verification pass that checks each claim against its cited source. The next section provides the copy-ready prompt template with all required placeholders.

This prompt is designed for the final stage of a multi-hop RAG pipeline. After your system has decomposed a complex question, executed a sequence of dependent retrieval queries, and collected answers for each sub-question, this prompt merges those intermediate findings into a single, coherent final answer. The template enforces hop-by-hop provenance, requires explicit contradiction flagging, and produces a structured output suitable for downstream display or further automated processing. Use this when your retrieval chain has produced a set of sub-question-answer pairs and you need to synthesize them without losing traceability back to the evidence.

codeCopy
You are a synthesis engine for a multi-hop retrieval system. Your task is to merge answers from multiple sub-questions into a single, coherent final answer. You must preserve traceability to each hop and flag any contradictions.

## ORIGINAL USER QUESTION
[ORIGINAL_QUESTION]

## SUB-QUESTION ANSWERS (in retrieval order)
[SUB_QUESTION_ANSWER_PAIRS]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "final_answer": "A coherent synthesis that answers the original question by integrating all sub-question findings. Use clear language and logical flow.",
  "hop_provenance": [
    {
      "hop_number": 1,
      "sub_question": "The sub-question for this hop",
      "finding_used": "The specific finding from this hop that was incorporated into the final answer",
      "source_citation": "Citation or reference from the original sub-question answer"
    }
  ],
  "contradictions": [
    {
      "hop_a": 1,
      "hop_b": 2,
      "description": "Description of the contradiction between the findings",
      "resolution_attempted": "How the contradiction was resolved, or 'unresolved' if it could not be reconciled"
    }
  ],
  "missing_information": ["List any information gaps that prevented a complete answer"],
  "confidence": "high|medium|low",
  "confidence_rationale": "Brief explanation of the confidence level based on evidence consistency and completeness"
}

## CONSTRAINTS
- Do not introduce facts not present in the sub-question answers.
- If sub-question answers conflict, flag the contradiction rather than silently choosing one.
- If critical information is missing, state it explicitly rather than fabricating.
- Preserve all source citations from sub-question answers.
- If the sub-question answers are insufficient to answer the original question, set confidence to "low" and explain why.
- Order hop_provenance entries by retrieval sequence.
- If fewer than [MIN_HOPS] hops are provided, note this as missing information.

To adapt this template, replace [ORIGINAL_QUESTION] with the user's initial complex question. Populate [SUB_QUESTION_ANSWER_PAIRS] with the structured output from each retrieval hop—typically a list of objects containing the sub-question text, the retrieved answer, and source citations. Set [MIN_HOPS] to the expected minimum number of hops for your pipeline, which helps the model detect incomplete retrieval chains. The output schema is designed for programmatic consumption: your application layer should parse the JSON, render final_answer to the user, and use hop_provenance to build clickable citations. The contradictions array should trigger a review workflow if unresolved conflicts are detected. Before deploying, run this prompt against a golden dataset of known multi-hop questions with expected answer spans and verify that provenance chains are complete and contradictions are correctly identified.

The sub-question answer merging prompt operates as the final synthesis stage in a multi-hop RAG pipeline. It receives a collection of sub-question/answer pairs produced by earlier retrieval and answering rounds, along with the original user question, and produces a single coherent answer with hop-by-hop provenance. In a production harness, this prompt is not called in isolation. It is invoked after all dependency-respecting sub-queries have been executed and their individual answers collected. The harness must assemble the input payload carefully: each sub-answer must be paired with its originating sub-question and source citations, because the merge prompt needs to trace which evidence came from which retrieval hop. If the upstream query planner produced a dependency graph, the harness should pass that graph as additional context so the merge prompt can validate that all required hops completed before synthesis begins.

A robust implementation wraps the merge prompt in a validation and retry loop. After the model returns a merged answer, the harness should run structural and semantic checks before surfacing the result to the user. Structural validation confirms that the output contains all required fields: the synthesized answer, a provenance array mapping each claim to its source sub-question and retrieval hop, and a contradictions array if the merge prompt detected conflicting sub-answers. Semantic validation checks for missing integration steps: if the original question required connecting entity A to entity C via bridge entity B, the harness should verify that the merged answer explicitly mentions the bridge step rather than jumping directly from A to C. For high-stakes domains such as clinical review or legal analysis, the harness should route merged outputs to a human review queue when the contradictions array is non-empty or when the merge prompt's confidence score falls below a configured threshold. Model choice matters here: models with strong instruction-following and long-context handling, such as Claude 3.5 Sonnet or GPT-4o, perform better at maintaining provenance fidelity across multiple sub-answers than smaller models that may drop citation links or flatten the reasoning chain.

Logging and observability are critical for debugging merge failures. The harness should log the full input payload (sub-questions, sub-answers, dependency graph, and original question), the raw model output, validation results, and any retry attempts. This trace data enables post-mortem analysis when users report answers that contradict source evidence or skip intermediate reasoning steps. Common failure modes to instrument for include: the merge prompt hallucinating a connection that none of the sub-answers support, omitting a sub-answer entirely from the synthesis, or producing a final answer that contradicts one of the input sub-answers without flagging it in the contradictions array. When these failures occur, the harness can trigger a repair path: re-invoke the merge prompt with explicit instructions to reconcile the specific contradiction, or escalate to a more capable model. Avoid the temptation to skip the merge step and concatenate sub-answers directly; users need a single coherent answer, not a list of partial results, and the merge prompt's provenance tracking is what makes the multi-hop pipeline auditable.