Decision Support Intent Query Rewrite Prompt Template

This prompt is designed for RAG system architects and search engineers building retrieval pipelines that serve executive dashboards, product strategy tools, or any application where users ask questions about trade-offs, options, and recommendations. The core job is to detect when a user query implies a decision-support need and rewrite it to retrieve comparative analyses, decision frameworks, and outcome evidence rather than simple definitions or isolated facts. Use this prompt when your knowledge base contains business cases, strategy documents, product comparisons, and risk assessments.

The ideal deployment context is a retrieval system where a naive user query like 'should we build or buy?' would fail because vector similarity alone retrieves documents matching the words 'build' or 'buy' without understanding the comparative intent. This prompt intervenes before retrieval, transforming the query into something like 'build versus buy decision framework criteria total cost of ownership trade-offs' and extracting decision dimensions such as ['cost', 'time_to_market', 'core_competency', 'maintenance']. The harness should validate that the rewritten query explicitly requests comparative language and that extracted dimensions are non-redundant and actionable. Do not use this prompt for factoid lookup, step-by-step procedural retrieval, or troubleshooting workflows. It assumes the user is evaluating choices and needs evidence that surfaces criteria, trade-offs, and rationale.

Before wiring this into production, confirm that your knowledge base actually contains decision-relevant content. If the corpus is primarily API reference docs, runbooks, or factual encyclopedias, this prompt will rewrite queries to request evidence that does not exist, producing empty or misleading retrieval results. Pair this prompt with an intent classifier that gates whether the rewrite fires, and log cases where the rewritten query returns zero results so you can refine the rewrite template or flag gaps in the knowledge base. The next section provides the copy-ready prompt template you can adapt and test against your own retrieval stack.

This template is designed to be pasted directly into your system or developer message. It instructs the model to analyze a user's query for decision-support intent—where the user is evaluating options, weighing trade-offs, or seeking a recommendation rationale—and to rewrite that query to optimize retrieval from a corpus of comparative analyses, decision frameworks, and outcome evidence. The prompt is self-contained and uses square-bracket placeholders for all application-specific values. Before sending, replace each placeholder with the concrete values for your use case, such as your domain context, risk tolerance, and any specific output format requirements.

textCopy
You are a query rewriting agent for a decision-support retrieval system. Your job is to analyze a user's query and determine if it expresses a decision-support intent: evaluating options, weighing trade-offs, seeking a recommendation with rationale, or understanding the criteria for a choice.

If the query does NOT express decision-support intent, output a JSON object with "intent_detected": false and "rewritten_query": null.

If the query DOES express decision-support intent, rewrite it to maximize retrieval of comparative analyses, decision frameworks, and outcome evidence. The rewritten query should surface documents that discuss trade-offs, criteria weighting, and evidence-based recommendations.

Follow these rules:
- Preserve all key entities, options, and constraints from the original query.
- Expand the query with decision-oriented language: "comparison," "trade-offs," "criteria," "evaluation," "pros and cons," "outcome evidence."
- Do not invent options or criteria the user did not mention.
- If the query implies a specific domain, incorporate that domain's terminology for decision analysis.

Domain context: [DOMAIN_CONTEXT]
Risk level for this application: [RISK_LEVEL]

Output a JSON object with the following schema:
{
  "intent_detected": boolean,
  "rewritten_query": string | null,
  "decision_dimensions": string[],
  "rationale": string
}

Where:
- "intent_detected": true if the query is a decision-support query, false otherwise.
- "rewritten_query": the rewritten query string, or null if intent is not detected.
- "decision_dimensions": an array of the key dimensions or criteria the user appears to be weighing (e.g., ["cost", "scalability", "time to market"]). Empty array if none detected.
- "rationale": a brief explanation of why the query was or was not classified as decision-support.

User query: [USER_QUERY]

To adapt this template, start by defining your [DOMAIN_CONTEXT]. This could be a short description like "enterprise software architecture" or "healthcare procurement." The model uses this to select appropriate terminology. Next, set [RISK_LEVEL] to "low," "medium," or "high." For high-risk domains such as healthcare or finance, you should add an additional constraint requiring the model to flag when the rewritten query might retrieve documents that could be misinterpreted as direct advice. The [USER_QUERY] placeholder should be replaced at runtime with the actual user input. The output schema is designed to be parsed by your application code; validate that the JSON is well-formed and that the decision_dimensions array does not contain duplicates. For production, log the rationale field alongside the rewritten query to support debugging and eval. If your retrieval system expects a plain string rather than structured JSON, modify the output schema accordingly, but always retain the intent detection flag to support routing logic.

This prompt is designed to sit in the pre-retrieval stage of a RAG pipeline, immediately after the user's query is received and before any vector or keyword search is executed. The harness should call the LLM with the prompt template, parse the structured output, and use the rewritten_query field as the primary input to your retrieval system. The decision_dimensions array should be logged and can be used downstream to guide re-ranking, prompt assembly for the generation step, or to trigger a specialized decision-mapping tool. Do not treat this as a simple string-in/string-out operation; the structured output is critical for the rest of the pipeline.

The implementation must include a strict JSON schema validator that checks the model's output before it reaches retrieval. The validator should confirm that rewritten_query is a non-empty string, decision_dimensions is an array of strings, and intent_confidence is a float between 0.0 and 1.0. If validation fails, implement a single retry by feeding the raw output and the validation error message back to the model with a repair instruction. If the retry also fails, log the failure, fall back to the original user query for retrieval, and set a flag for human review. For model choice, a capable mid-tier model like gpt-4o or claude-3.5-sonnet is sufficient; avoid using a slow, expensive reasoning model for this latency-sensitive pre-retrieval step.

Log the original query, the rewritten query, the extracted dimensions, and the confidence score to your observability platform. This data is essential for evaluating the prompt's performance. Create an offline evaluation script that runs a golden dataset of decision-support questions through the harness and checks two things: first, that the rewritten_query retrieves documents containing trade-off language, criteria discussion, and comparative analysis from your knowledge base; second, that the decision_dimensions extracted by the model match a human-labeled set of dimensions for each test case. If the confidence score is below a threshold you determine from this eval (e.g., 0.7), route the query to a clarification flow instead of proceeding with a potentially misdirected retrieval. This prompt is a classification and rewriting step, not a generation step, so do not send its output directly to the end user.