Temporal Query Routing Prompt for Time-Sensitive Indexes

This prompt is for RAG developers and orchestration engineers who manage time-partitioned corpora. Use it when your retrieval system must decide whether a user query needs recent data, historical archives, or a specific time window. The prompt detects temporal requirements in natural language, normalizes relative time expressions like 'last week' or 'recently' into concrete boundaries, and routes the query to the appropriate time-scoped index or freshness tier. Without this classification layer, a query for 'the latest security advisory' might silently hit a stale quarterly snapshot, or a request for 'Q2 2023 financials' could waste compute scanning real-time indexes that don't hold historical records.

Deploy this prompt when your retrieval architecture already has multiple time-scoped indexes—such as a hot index for the last 7 days, a warm index for the current quarter, and a cold archive for older data—and you need a reliable dispatch mechanism. The prompt works best when combined with a metadata filter generation step that translates its normalized date boundaries into structured start_date and end_date constraints for your vector or keyword search backends. Do not use this prompt when your corpus has no time dimension, when all indexes contain the same temporal coverage, or when the user has already provided explicit date filters in a structured query interface. In those cases, temporal routing adds latency and classification risk without improving retrieval quality.

Before integrating this prompt into production, validate its performance against a golden dataset of queries with known temporal intent. Pay special attention to relative time expressions ('this month,' 'year-to-date,' 'recently'), implicit freshness signals ('current CEO,' 'latest release'), and queries that appear temporal but are not ('the history of the Roman Empire'). Common failure modes include misclassifying atemporal historical-analysis queries as requiring recent data, failing to resolve timezone-relative expressions, and over-routing to real-time indexes for queries that a warm index could satisfy. Start with a small set of labeled examples, measure classification accuracy and index-hit quality, and tune the prompt's routing thresholds before expanding coverage.

The following prompt template is designed to be dropped into a query routing layer before retrieval execution. It analyzes a user's natural language query for temporal signals—relative time expressions, explicit date ranges, recency requirements, and freshness expectations—and outputs a structured routing decision. The decision includes a normalized time range, a target index tier, and a confidence score that your application can use to trigger fallback or human review.

textCopy
You are a temporal query router for a RAG system with time-partitioned indexes. Your job is to analyze a user query, detect any temporal requirements, normalize them into explicit date boundaries, and select the appropriate index tier.

## INPUT
User Query: [USER_QUERY]
Current Date (ISO 8601): [CURRENT_DATE]

## AVAILABLE INDEX TIERS
- realtime: Last 24 hours. Use for queries requiring immediate, breaking, or live information.
- recent: Last 30 days. Use for queries about recent events, updates, or current-state questions.
- quarterly: Last 90 days. Use for queries referencing 'this quarter' or recent trends.
- yearly: Last 365 days. Use for queries about 'this year' or annual patterns.
- historical: All time, no recency constraint. Use for factual, evergreen, or reference queries.
- custom_range: A specific date range not matching the tiers above. Provide explicit start and end dates.

## OUTPUT SCHEMA
Return a single JSON object with these fields:
{
  "temporal_intent_detected": boolean,
  "temporal_signals_found": ["list of strings identifying the temporal expressions found in the query"],
  "normalized_start_date": "ISO 8601 date or null",
  "normalized_end_date": "ISO 8601 date or null",
  "selected_index_tier": "realtime | recent | quarterly | yearly | historical | custom_range",
  "confidence": 0.0-1.0,
  "reasoning": "Brief explanation of the routing decision.",
  "requires_disambiguation": boolean
}

## RELATIVE TIME NORMALIZATION RULES
- "now", "right now", "currently", "live" → realtime tier, end_date = CURRENT_DATE, start_date = CURRENT_DATE minus 1 day
- "today" → realtime tier, start_date = CURRENT_DATE, end_date = CURRENT_DATE
- "yesterday" → recent tier, start_date = CURRENT_DATE minus 1 day, end_date = CURRENT_DATE minus 1 day
- "this week" → recent tier, start_date = Monday of current week, end_date = CURRENT_DATE
- "last week" → recent tier, start_date = Monday of previous week, end_date = Sunday of previous week
- "this month" → recent tier, start_date = 1st of current month, end_date = CURRENT_DATE
- "last month" → recent tier, start_date = 1st of previous month, end_date = last day of previous month
- "this quarter" → quarterly tier, start_date = 1st day of current quarter, end_date = CURRENT_DATE
- "last quarter" → quarterly tier, start_date = 1st day of previous quarter, end_date = last day of previous quarter
- "this year" → yearly tier, start_date = January 1 of current year, end_date = CURRENT_DATE
- "last year" → yearly tier, start_date = January 1 of previous year, end_date = December 31 of previous year
- "recent", "lately", "in the past few days" → recent tier, start_date = CURRENT_DATE minus 7 days, end_date = CURRENT_DATE
- "latest", "most recent", "newest" → recent tier, start_date = CURRENT_DATE minus 30 days, end_date = CURRENT_DATE
- Explicit date ranges (e.g., "between March 2023 and June 2023") → custom_range tier with extracted dates
- No temporal signal → historical tier, start_date = null, end_date = null

## RECENCY THRESHOLD CHECKS
- If the query asks for "latest" or "current" information but the topic is fast-changing (news, stock prices, sports scores, weather), prefer realtime tier.
- If the query asks for "latest" but the topic is slow-changing (scientific facts, historical analysis, documentation), prefer recent or historical tier.
- If multiple temporal signals conflict, set requires_disambiguation to true and confidence below 0.6.

## CONSTRAINTS
- Always use the provided CURRENT_DATE as the reference point for relative time normalization.
- If a temporal signal is ambiguous (e.g., "last Friday" when today is Monday), set requires_disambiguation to true and provide both possible interpretations in reasoning.
- Do not invent dates. If the query contains no temporal signal, temporal_intent_detected must be false and selected_index_tier must be "historical".
- Confidence below 0.7 should trigger a fallback or human review in the calling application.

To adapt this template, replace [USER_QUERY] with the raw user input and [CURRENT_DATE] with the current date in ISO 8601 format at the time of the request. The output schema is designed for direct parsing by your routing middleware. If your index tiers differ from the five listed, update the AVAILABLE INDEX TIERS section and the corresponding RELATIVE TIME NORMALIZATION RULES to match your infrastructure. The recency threshold checks in the prompt encode domain-specific heuristics—adjust the fast-changing and slow-changing topic examples to reflect your corpus.

Before deploying, validate the prompt against a golden set of temporal queries that includes edge cases: queries with no temporal signal, queries with conflicting signals, queries with ambiguous relative dates, and queries with explicit date ranges that span multiple tiers. Log the confidence and requires_disambiguation fields in production to monitor routing quality. If confidence drops below 0.7 or requires_disambiguation is true, route to a disambiguation workflow or escalate for human review rather than silently defaulting to a tier that may produce irrelevant results.

The Temporal Query Routing Prompt is a classification and normalization step that must execute before any retrieval call. It takes a raw user query and returns a structured routing decision: a target time-scoped index, a normalized date range, and a confidence score. This output should be treated as a control signal, not a final answer. Wire it as a synchronous pre-retrieval hook in your RAG orchestrator. The prompt's latency budget should be tight—target under 500ms—since it sits on the critical path for every time-sensitive query. Use a fast model (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned small classifier) rather than a large reasoning model. If the confidence score falls below your threshold (start with 0.85), route to a conservative fallback: either a broad time-range index or a multi-index query with post-retrieval re-ranking by date.

Validation and retry logic is essential. The prompt returns a JSON object with fields routing_decision, normalized_date_range, confidence, and reasoning. Validate this output structurally before acting on it. Check that normalized_date_range.start and normalized_date_range.end are valid ISO 8601 dates, that start <= end, and that confidence is a float between 0 and 1. If validation fails, retry once with the same prompt and a stronger constraint instruction appended. If the retry also fails, log the failure, set routing_decision to fallback, and route to your broadest time-index. Never pass an unvalidated date range to your retrieval backend—malformed dates can cause empty result sets or full-index scans. For relative time expressions like 'last quarter' or 'past week', verify that the normalized range resolves to concrete dates relative to the current system timestamp, not the model's training cutoff.

Observability and logging should capture the full routing decision for every query. Log the raw user query, the normalized date range, the selected index, the confidence score, and the reasoning field. This data is invaluable for tuning your recency thresholds and detecting temporal misclassification patterns. Set up a dashboard that tracks: (1) the distribution of routing decisions across your time-index tiers, (2) the rate of low-confidence routings that trigger fallback, and (3) the correlation between confidence scores and downstream answer quality metrics. If you observe that queries containing 'recently', 'latest', or 'current' are frequently misrouted to archival indexes, add those terms as few-shot examples in the prompt template. For high-stakes domains like financial filings or medical literature, add a human review gate when the confidence score is below 0.7 and the query involves regulatory or clinical content. The routing decision should be surfaced in your trace tool (e.g., LangSmith, Arize, or custom logging) alongside the retrieval call and final answer for end-to-end debugging.

Model choice and caching can significantly reduce cost and latency. Since temporal classification is a narrow, pattern-matching task, a small model with a well-constructed prompt often outperforms a large model with a generic prompt. If you process high query volumes, consider fine-tuning a classifier on 500–1000 labeled examples of temporal vs. non-temporal queries with normalized date ranges. Cache routing decisions for identical or near-identical queries using a normalized query hash as the key, with a TTL equal to your shortest time-index granularity (e.g., 1 hour for hourly indexes). Do not cache queries containing relative time expressions like 'today' or 'this week'—these must be re-evaluated on each request. For multi-turn conversations, pass the session's accumulated temporal context (e.g., 'the user previously asked about Q3 2024') as part of [CONTEXT] to prevent the model from resetting its temporal frame on each turn.