Uncertainty Decomposition Prompt for Complex Queries

This prompt is for planning and reasoning system builders who need to break a complex, multi-part query into discrete sub-questions and assign a confidence estimate to each. Use it when a single monolithic answer would hide critical uncertainty, when you need to identify which parts of a query require clarification before proceeding, or when you are building an agent that must decide between autonomous completion and human escalation. This prompt belongs in the pre-execution phase of a reasoning pipeline, before tool calls or final answer generation. It assumes the input query is non-trivial and may contain nested dependencies, ambiguous references, or factual premises that require verification.

The ideal user is an AI engineer or product developer integrating a reasoning step into an agent harness, a RAG system, or a structured output pipeline. Required context includes the full user query, any available grounding documents, and a defined confidence schema. Do not use this prompt for simple factual lookups, single-intent queries with no ambiguity, or latency-sensitive real-time chat where decomposition overhead is unacceptable. It is also inappropriate when the downstream system cannot act on per-sub-question confidence signals, making the structured output wasted computation.

Before wiring this prompt into production, define what the consuming system will do with each confidence level. A sub-question with low confidence might trigger a clarification request, a human handoff, or a fallback model. Without that contract, the decomposition is just an academic exercise. Start with a small set of manually decomposed queries to calibrate your confidence thresholds, then automate. Avoid using this prompt as a substitute for proper retrieval when the query requires external facts the model cannot reliably self-assess.

This template is designed to be copied directly into your prompt management system or codebase. It instructs the model to break a complex, multi-part query into discrete sub-questions, assign a confidence score to each, and flag any sub-question that requires further clarification before a reliable answer can be produced. The output is a structured decomposition that helps downstream routing logic decide whether to proceed, ask the user for clarification, or escalate to a human reviewer.

textCopy
You are an expert query analyst. Your task is to decompose a complex user query into its constituent sub-questions. For each sub-question, assess whether you have sufficient information to answer it confidently and assign a confidence score.

## INPUT
[COMPLEX_QUERY]

## CONTEXT
[CONTEXT]

## CONSTRAINTS
- Decompose the query into the smallest set of independent, non-overlapping sub-questions that fully cover the original intent.
- For each sub-question, assign a confidence score between 0.0 and 1.0, where 1.0 means you are fully confident you can answer correctly with the available information.
- If a sub-question is ambiguous, missing critical parameters, or requires external knowledge not present in the context, mark it as `needs_clarification: true` and specify what is missing.
- Do not answer the sub-questions. Only produce the decomposition and confidence assessment.
- If the entire query is unanswerable or nonsensical, return a single entry with `confidence: 0.0` and a clear explanation.

## OUTPUT_SCHEMA
Return a valid JSON object with the following structure:
{
  "original_query": "string",
  "decomposition": [
    {
      "sub_question": "string",
      "confidence": number,
      "needs_clarification": boolean,
      "missing_information": "string | null",
      "rationale": "string"
    }
  ],
  "overall_assessment": {
    "average_confidence": number,
    "clarification_required": boolean,
    "recommended_action": "proceed | clarify | escalate"
  }
}

## EXAMPLES
[EXAMPLES]

## RISK_LEVEL
[RISK_LEVEL]

To adapt this template, replace the bracketed placeholders with your specific inputs. [COMPLEX_QUERY] is the user's original multi-part question. [CONTEXT] should contain any retrieved documents, conversation history, or system data the model can use to assess answerability. [EXAMPLES] should include 2-3 few-shot demonstrations of correct decompositions for your domain, showing both high-confidence and clarification-needed cases. [RISK_LEVEL] accepts values like low, medium, or high and should be used to adjust the confidence threshold for the recommended_action field in your post-processing logic. After copying, validate that the output JSON matches the schema before routing—schema violations should trigger a retry with the same prompt or a repair prompt from the Output Repair and Validation Prompts pillar. For high-risk domains, always route clarification_required: true outputs to a human reviewer rather than automatically asking the user.

The Uncertainty Decomposition Prompt is not a standalone chat interaction—it is a structured reasoning step inside a larger planning or QA pipeline. Wire it as a synchronous call within an orchestrator that first receives a complex user query, then invokes this prompt to produce a decomposition with per-sub-question confidence estimates. The orchestrator should parse the structured output (JSON with sub-questions, confidence scores, and evidence gaps) and branch: sub-questions above a configurable confidence threshold proceed to downstream retrieval or tool calls, while those below the threshold trigger clarification requests or human review. Store the full decomposition payload in your trace system so operators can audit which parts of a complex query were answered autonomously and which were escalated.

Validation must happen at two levels. First, validate the output schema: confirm the response contains a parseable JSON array where each element has a sub_question string, a confidence float between 0.0 and 1.0, and an evidence_gap string explaining what is missing or uncertain. Reject and retry if the schema is malformed or confidence values fall outside bounds. Second, validate decomposition coverage: check that the sub-questions collectively address all core entities and intents in the original query. A lightweight coverage check can prompt a second model call to compare the original query against the decomposition and flag missing aspects. If coverage is incomplete, append the missing sub-questions with low confidence and route them to clarification. For high-stakes domains, log every decomposition alongside the coverage check result for human audit before downstream actions execute.

Model choice matters. Use a model with strong reasoning and structured-output capabilities for the decomposition step. If latency permits, consider running the decomposition through two models and comparing confidence divergence as an additional uncertainty signal. Set a retry budget: if schema validation fails, retry up to two times with the validation error included in the retry prompt context. If coverage validation fails, do not retry blindly—escalate to a human reviewer with the original query, the partial decomposition, and the coverage gap report. Wire the entire harness into your observability stack: log decomposition latency, confidence distributions, retry counts, and escalation rates. Monitor for drift in average confidence scores over time, which can signal model behavior changes or shifts in query complexity that require threshold recalibration.