Temporal Query Decomposition Prompt

This prompt is designed for RAG developers and search engineers who manage retrieval over time-series corpora—think financial filings, incident postmortems, news archives, or product changelogs. The core job-to-be-done is converting a user query that contains relative time expressions like 'last quarter,' 'recently,' or 'over the past few months' into a structured set of sub-questions, each with explicit ISO 8601 date boundaries. Without this normalization step, a vector or keyword index has no way to resolve 'last quarter' into a concrete date range, and a single broad query often masks the need to gather evidence from multiple distinct time windows. The ideal user is someone who already has a working retrieval pipeline but finds that temporal queries return incomplete, irrelevant, or temporally misaligned results.

Use this prompt when your retrieval index requires explicit date filters and when a user's temporal question implies multiple independent fact-finding steps. For example, a query like 'How did our Q2 churn rate compare to Q1, and what changed in our onboarding flow during that period?' demands at least two sub-questions targeting different date ranges and potentially different document subsets. The prompt normalizes the relative dates, decomposes the query, and outputs a structured plan that your application can execute as parallel or sequential retrieval calls. It is particularly valuable when your corpus has dense event sequences—such as incident timelines or earnings call transcripts—where a single retrieval pass over a wide date range would bury critical signals in noise.

Do not use this prompt for non-temporal queries, for real-time data streams where dates are irrelevant, or when your underlying search index already performs robust date math natively. If your index can parse 'last quarter' and map it to a filter without external help, adding a decomposition layer adds latency and complexity without benefit. Similarly, avoid this prompt for simple lookups like 'Show me the Q3 report'—a direct metadata filter is faster and more reliable. The next section provides the copy-ready prompt template you can adapt, followed by guidance on wiring it into your retrieval harness with validation, retries, and failure mode handling.

This prompt template is designed to be copied directly into your application's prompt management system. It takes a user query containing relative or absolute time references and breaks it into a set of independently answerable sub-questions, each scoped to a specific date range. The model is instructed to normalize all temporal expressions into explicit ISO 8601 date boundaries, which is critical for downstream retrieval systems that cannot interpret phrases like "last quarter" or "recently." Before using this template, replace every square-bracket placeholder with the values appropriate for your application, model, and risk tolerance.

textCopy
You are a temporal query decomposition assistant. Your job is to take a user's question that contains time-based references and break it into a set of sub-questions, each with an explicit date range. Normalize all relative time expressions (e.g., "last month," "recently," "this year") into concrete ISO 8601 date boundaries (YYYY-MM-DD).

[CONTEXT]

Today's date: [CURRENT_DATE]

[INPUT]

User query: [USER_QUERY]

[OUTPUT_SCHEMA]

Return a JSON object with the following structure:
{
  "original_query": "string",
  "decomposition_strategy": "parallel | sequential",
  "sub_questions": [
    {
      "id": "string",
      "question": "string",
      "start_date": "YYYY-MM-DD",
      "end_date": "YYYY-MM-DD",
      "rationale": "string explaining why this date range was chosen",
      "depends_on": ["sub_question_id"] | []
    }
  ]
}

[CONSTRAINTS]

- Every sub_question must have non-null start_date and end_date fields.
- If the user query contains no temporal references, return a single sub_question with start_date and end_date set to null and explain in the rationale that no temporal constraint was detected.
- If a relative time expression is ambiguous (e.g., "this quarter" when near a quarter boundary), choose the most likely interpretation and note the ambiguity in the rationale.
- Sub-questions must be independently answerable unless depends_on is populated.
- Do not answer the user's question. Only decompose it.
- If the query spans multiple non-contiguous time periods, generate one sub-question per period.

[EXAMPLES]

Example 1:
User query: "How did our revenue change between Q1 and Q2 of 2024?"
Output:
{
  "original_query": "How did our revenue change between Q1 and Q2 of 2024?",
  "decomposition_strategy": "parallel",
  "sub_questions": [
    {
      "id": "q1",
      "question": "What was our revenue in Q1 2024?",
      "start_date": "2024-01-01",
      "end_date": "2024-03-31",
      "rationale": "Q1 2024 spans January 1 to March 31, 2024.",
      "depends_on": []
    },
    {
      "id": "q2",
      "question": "What was our revenue in Q2 2024?",
      "start_date": "2024-04-01",
      "end_date": "2024-06-30",
      "rationale": "Q2 2024 spans April 1 to June 30, 2024.",
      "depends_on": []
    }
  ]
}

Example 2:
User query: "What were the top support issues last week and how do they compare to the week before?"
Output:
{
  "original_query": "What were the top support issues last week and how do they compare to the week before?",
  "decomposition_strategy": "parallel",
  "sub_questions": [
    {
      "id": "last_week",
      "question": "What were the top support issues last week?",
      "start_date": "2025-01-13",
      "end_date": "2025-01-19",
      "rationale": "Assuming today is 2025-01-20, last week is Monday January 13 through Sunday January 19.",
      "depends_on": []
    },
    {
      "id": "week_before",
      "question": "What were the top support issues the week before last?",
      "start_date": "2025-01-06",
      "end_date": "2025-01-12",
      "rationale": "The week before last week is Monday January 6 through Sunday January 12.",
      "depends_on": []
    }
  ]
}

[RISK_LEVEL]

[RISK_LEVEL]

To adapt this template, start by populating [CURRENT_DATE] with the actual date at query time, formatted as YYYY-MM-DD. This is the single most important variable because all relative date normalization depends on it. Replace [USER_QUERY] with the incoming user question from your application. The [CONTEXT] placeholder can be used to inject additional information such as the user's timezone, fiscal calendar definitions, or company-specific period boundaries. If your application operates in a regulated domain where date misinterpretation could cause financial or compliance errors, set [RISK_LEVEL] to "high" and add an instruction requiring the model to flag ambiguous temporal expressions for human review rather than guessing.

After copying the template, test it against a small set of queries that include edge cases: queries with no time references, queries spanning multiple years, queries with ambiguous boundaries like "this month" when the current date is the first or last day of the month, and queries that mix absolute and relative dates. Validate that every returned sub-question has a start_date and end_date that are either both null or both populated with valid ISO 8601 strings. If you are wiring this into a production RAG pipeline, add a post-processing validator that rejects any decomposition where a sub-question's end_date is before its start_date, where date ranges overlap in a sequential decomposition, or where a depends_on field references a non-existent sub-question ID. These structural checks catch model errors before they propagate into your retrieval layer and produce silently wrong answers.

The Temporal Query Decomposition Prompt is designed to be called as a pre-retrieval step in a RAG pipeline. When a user query contains relative time expressions like 'last quarter', 'recent', or 'since the announcement', the prompt normalizes those into explicit date ranges and splits the query into sub-questions targeting distinct time periods. The harness should intercept the user query, detect whether temporal decomposition is needed (via a lightweight classifier or keyword check), and then call the LLM with this prompt before any retrieval occurs. The output is a structured list of sub-questions, each with a start_date and end_date field that downstream retrieval systems can use as metadata filters.

The implementation must include a date-range validator that runs immediately after the LLM response. This validator checks that every generated sub-question has non-null start_date and end_date fields, that start_date is before end_date, that date ranges do not overlap unless the decomposition explicitly calls for comparative periods, and that all dates fall within the corpus boundary defined in [CORPUS_DATE_RANGE]. If validation fails, the harness should retry the prompt once with the validation error appended to [CONSTRAINTS]. After two failures, escalate to a human reviewer or fall back to a default single-query rewrite. Log every decomposition attempt, including the original query, generated sub-questions, validator results, and retry count, for observability.

For model choice, use a model with strong instruction-following and JSON output capabilities, such as GPT-4o, Claude 3.5 Sonnet, or a fine-tuned variant if your temporal expressions are domain-specific. Set temperature=0 to maximize deterministic date normalization. If your RAG system uses multiple retrieval backends (e.g., vector search for semantic matches and a date-filtered keyword index for time-bound documents), map each sub-question to the appropriate backend based on its target_index field. Wire the sub-questions into a parallel retrieval step, then feed the collected evidence into a downstream synthesis prompt. Avoid feeding raw sub-questions directly to the user; they are intermediate artifacts for retrieval orchestration.