Sub-Question Dependency Graph Construction Prompt

This prompt is for RAG architects and agent developers who need to answer complex questions that cannot be resolved with a single round-trip to a vector database. The core job is to decompose a multi-part user question into its constituent sub-questions and output a machine-readable directed acyclic graph (DAG) that defines the execution order. You should use this prompt when a question contains nested logic, requires information from one retrieval to formulate the next query, or combines multiple entities and relationships that must be resolved sequentially. The ideal user is an engineer building a multi-hop retrieval pipeline who needs a structured plan—not just a list of queries—to orchestrate downstream tool calls and evidence collection.

This prompt is not a general-purpose query rewriter. Do not use it for simple factoid lookups, single-hop retrieval, or synonym expansion. It is also not a substitute for an agent's planning module if your system already uses a fine-tuned planner. The prompt assumes you have a mechanism to execute the generated sub-queries and merge their results; it only produces the dependency structure. You must provide the original complex question as [USER_QUESTION], and optionally any known [DOMAIN_CONSTRAINTS] or [KNOWN_ENTITIES] that can ground the decomposition. The output is a strict JSON schema representing nodes (sub-questions) and edges (dependencies), which your application code will parse to manage parallel execution batches and sequential waits.

Before integrating this prompt into a production pipeline, validate the generated graph for cycles, orphan nodes, and redundant paths using the companion 'Dependency Graph Validation Prompt for Query Plans.' In high-stakes domains like legal research or clinical literature review, a malformed graph can silently skip critical evidence. Always log the generated graph alongside the final answer for auditability. If your latency budget is tight, consider pairing this prompt with the 'Multi-Hop Query Execution Order Optimization Prompt' to minimize total retrieval rounds after the graph is built.

This prompt template is the core instruction set you will send to the model. It is designed to accept a complex user question and output a structured dependency graph of sub-questions. The graph explicitly defines which sub-questions must be answered before others, enabling your agent or RAG orchestrator to execute a valid multi-hop retrieval plan. The template uses square-bracket placeholders for all dynamic inputs, making it ready for programmatic injection in your application code.

textCopy
You are a precise query planner. Your task is to decompose a complex user question into a set of sub-questions and output a directed acyclic graph (DAG) of their dependencies.

**Input Question:**
[USER_QUESTION]

**Instructions:**
1. Decompose the question into the smallest set of independent sub-questions required to answer it fully.
2. For each sub-question, identify its dependencies: which other sub-questions must be answered first.
3. Output a JSON object conforming to the schema below. The graph must be acyclic.

**Output Schema:**
{
  "sub_questions": [
    {
      "id": "string (unique identifier, e.g., 'Q1')",
      "question": "string (the full text of the sub-question)",
      "depends_on": ["string (list of sub-question IDs that must be answered before this one)"],
      "expected_answer_type": "string (e.g., 'entity', 'date', 'boolean', 'list_of_facts')"
    }
  ],
  "root_questions": ["string (list of sub-question IDs with no dependencies)"]
}

**Constraints:**
- [CONSTRAINTS]

**Examples:**
[EXAMPLES]

To adapt this template, replace the placeholders with your application's specific needs. [USER_QUESTION] is the only strictly required input. Use [CONSTRAINTS] to inject rules like 'Do not create more than 5 sub-questions' or 'Prefer parallelizable questions.' Use [EXAMPLES] to provide few-shot demonstrations of the desired decomposition style for your domain. Before wiring this into a production pipeline, ensure your application layer validates the output against the schema and checks for cycles, as covered in the Implementation Harness section.

This prompt is not a standalone utility; it is a planning step inside a larger retrieval pipeline. The typical integration point is after intent classification and before any retrieval execution. When a user question is flagged as complex or multi-hop, the application calls this prompt to produce a dependency graph. The graph is then consumed by an execution engine that respects the directed acyclic structure: parallel-safe sub-questions are dispatched concurrently, while dependent sub-questions wait for their upstream results. The output of this prompt should be treated as a machine-readable plan, not a final answer to the user. Store the raw graph JSON alongside the session trace for debugging and audit.

Validation is the most critical harness component. Before the graph is executed, run a structural validator that checks for cycles (a topological sort must succeed), orphan nodes (every node except root nodes must have at least one incoming edge), and redundant paths (if A→B and A→C→B both exist, flag the shorter path as potentially sufficient). Additionally, validate that every sub-question is independently answerable: if a sub-question contains unresolved pronouns or references that depend on another sub-question's output, that dependency must be explicitly represented as an edge. A common failure mode is the model producing a flat list of sub-questions with no edges, which defeats the purpose of dependency-aware execution. The harness should reject graphs with zero edges when the question contains clear multi-hop structure, and fall back to a simpler sequential plan or escalate for human review.

Model choice matters here. This task requires strong reasoning about logical dependencies and benefits from models with explicit chain-of-thought capabilities. In testing, smaller or faster models often produce graphs with missing edges or hallucinated dependencies. Consider routing this prompt to a larger reasoning model while using smaller models for simpler query decomposition tasks. Implement a retry strategy with a maximum of two attempts: if the first output fails structural validation, feed the validation errors back into a retry prompt that asks the model to repair the graph. If the second attempt also fails, log the failure, fall back to a sequential execution plan, and surface the incident to the operations dashboard. Do not silently execute a broken graph.

Observability requires logging the input question, the generated graph, validation results, and the final executed plan. Tag each trace with the graph's node count, edge count, and whether validation passed on the first attempt. This data is essential for tuning the prompt over time and identifying question categories where dependency detection is unreliable. For high-stakes domains such as legal, financial, or clinical question answering, add a human-in-the-loop approval gate before executing any graph with more than a configurable threshold of nodes, or when the model's confidence score falls below a defined cutoff. The graph should be presented to a reviewer with the original question and a clear visualization of the proposed dependencies.