Query Freshness Requirement Detection Prompt

This prompt is a classification router for your retrieval dispatch layer. Its job is to inspect a user query and decide which freshness tier the retrieval system should target: real-time, recent, or archival. Use it when your RAG system indexes content across multiple time-partitioned corpora—for example, a breaking news feed, a rolling six-month document store, and a historical archive—and you need to route queries before retrieval executes. The prompt detects explicit time expressions like 'last week', 'yesterday', or 'latest' as well as implicit freshness signals such as 'current CEO', 'breaking news', or 'today's price' that demand recent data without stating a date. It also identifies historical or timeless queries like 'causes of World War I' or 'definition of photosynthesis' that should avoid real-time indexes entirely.

Deploy this prompt when your retrieval architecture has at least two freshness tiers and the cost of querying the wrong tier is measurable—whether in latency, compute spend, or result irrelevance. It is especially useful when real-time indexes are expensive to query or have limited coverage, making it wasteful to route every query through them. The prompt works best as a pre-retrieval gate: classify first, then dispatch to the appropriate index. Do not use this prompt if your system has a single unified index, if all content is equally fresh, or if you already handle temporal routing through structured metadata filters applied at query time. In those cases, the prompt adds latency without improving retrieval quality.

This prompt is not a temporal expression parser. It does not normalize relative dates into absolute ranges—that work belongs to a downstream temporal query expansion step. It also does not handle queries that mix freshness requirements, such as 'compare last month's sales to the historical average.' For those compound queries, pair this prompt with a query decomposition step that splits the request into sub-queries with different freshness targets. Before deploying, calibrate the freshness thresholds with your operations team: define what 'real-time' means in minutes or seconds, what 'recent' covers in days or weeks, and what falls into 'archival.' Without agreed thresholds, the routing decision will be inconsistent across evaluations.

This template is designed to be dropped directly into your orchestration layer. It forces the model to classify a user query into a discrete freshness tier—realtime, recent, historical, or time_agnostic—and output a structured routing decision. The core value is preventing a query about 'today's outage' from searching an archive index that updates monthly, or a query about 'last decade's trends' from wasting resources on a real-time feed.

textCopy
System: You are a temporal query classifier for a retrieval system. Your only job is to analyze the user's query and determine the temporal freshness requirement. You must output a valid JSON object with no additional text.

Available freshness tiers and their target indexes:
- realtime: For queries requiring data from the last few minutes to hours. Routes to the `realtime_feed_index`.
- recent: For queries requiring data from the last few days to weeks. Routes to the `recent_docs_index`.
- historical: For queries requiring data older than a few weeks, including specific date ranges in the past. Routes to the `archive_index`.
- time_agnostic: For queries where time is not a factor (e.g., definitions, static facts). Routes to the `knowledge_base_index`.

[CONSTRAINTS]
- If the query contains relative time words like 'today', 'this week', 'latest', 'current', or 'live', it is at least `recent`.
- If the query contains a specific past date or year, it is `historical`.
- If the query asks for 'news' or 'updates' without a specific past date, it is `recent`.
- Do not guess. If temporal intent is unclear, default to `time_agnostic`.

[OUTPUT_SCHEMA]
{
  "freshness_tier": "realtime" | "recent" | "historical" | "time_agnostic",
  "target_index": "string",
  "confidence": 0.0-1.0,
  "rationale": "Brief explanation of the decision."
}

[EXAMPLES]
User Query: What's the stock price of GOOG?
Output: {"freshness_tier": "realtime", "target_index": "realtime_feed_index", "confidence": 0.98, "rationale": "Stock prices require up-to-the-minute data."}

User Query: Show me the Q3 2021 earnings report.
Output: {"freshness_tier": "historical", "target_index": "archive_index", "confidence": 0.99, "rationale": "Query specifies a past quarter and year."}

User Query: What is a large language model?
Output: {"freshness_tier": "time_agnostic", "target_index": "knowledge_base_index", "confidence": 0.99, "rationale": "Definitional query with no temporal constraint."}

User Query: Latest news on the acquisition.
Output: {"freshness_tier": "recent", "target_index": "recent_docs_index", "confidence": 0.95, "rationale": "'Latest news' implies recent temporal requirement."}

User Query: [USER_QUERY]
Output:

To adapt this, replace [USER_QUERY] with your application's user input string. The [CONSTRAINTS] block is your primary tuning lever; add domain-specific rules here, such as 'queries mentioning our competitor's product name are always recent.' The [OUTPUT_SCHEMA] must be kept strict to avoid parsing errors in your dispatch logic. The [EXAMPLES] are critical for teaching the model the boundary between recent and realtime, which is the most common failure point. Add at least two more examples that reflect edge cases from your own logs.

Before deploying, run a batch of 50-100 historical queries through this prompt and manually review the rationale field for any misclassifications, particularly queries that were incorrectly marked as time_agnostic. A common failure mode is the model defaulting to time_agnostic for queries with subtle temporal cues like 'current best practices.' If you observe this, add a counter-example to the [EXAMPLES] block and tighten the [CONSTRAINTS]. Wire the output of this prompt directly to your index selection function; if confidence is below 0.8, route to a human review queue or a more conservative, broader retrieval strategy as a fallback.

The Query Freshness Requirement Detection Prompt is designed to sit at the entry point of a retrieval dispatch layer, before any index is queried. Its job is to classify the temporal intent of a user query and return a structured decision that downstream routing logic can act on. The prompt itself does not perform retrieval; it produces a classification payload that your application code uses to select the appropriate freshness-tier index, apply date-range filters, or trigger a real-time data fetch. Treat this prompt as a deterministic classifier with a confidence score, not as a conversational agent. Its output should be validated before any retrieval call is made.

To integrate this prompt, wrap it in a function that accepts a user query string and an optional session context object. The prompt template expects placeholders like [USER_QUERY] and [CURRENT_TIMESTAMP] to be resolved at runtime. After receiving the model response, validate the output against a strict schema: the freshness_tier field must be one of realtime, recent, historical, or any; the confidence field must be a float between 0.0 and 1.0; and the temporal_signals array must contain only allowed signal types such as explicit_date, relative_time, event_reference, or recency_keyword. If validation fails, log the raw output and the failure reason, then fall back to a conservative routing strategy—typically routing to the recent tier with a wide date window. For high-stakes applications where misrouting could surface stale compliance or financial data, implement a human review queue for any classification with confidence below 0.7 or where freshness_tier is any.

Model choice matters here. This is a classification task with low latency requirements, so smaller, faster models like Claude Haiku, GPT-4o-mini, or a fine-tuned open-weight model are appropriate. Avoid using large reasoning models for this step unless you have evidence that classification accuracy degrades on edge cases. Implement retries with exponential backoff only for transient API errors, not for validation failures. A validation failure is a signal that the prompt or schema needs adjustment, not that the model should be retried. Log every classification decision along with the query, the resolved timestamp, the model version, and the routing outcome. This trace data is essential for tuning the confidence threshold and for debugging freshness-related retrieval failures in production.

The most common production failure mode is temporal signal misclassification: a query like 'What were our Q3 numbers?' gets classified as historical when the user actually means the most recent quarter. Mitigate this by resolving relative time expressions against [CURRENT_TIMESTAMP] before the prompt runs, and by maintaining a calendar of known events or fiscal periods that can be injected as additional context. Another failure mode is over-classification of realtime for queries that contain recency keywords but don't actually require live data. Use the confidence score to gate realtime routing—only route to realtime indexes when confidence exceeds 0.85. For everything else, route to recent with a configurable lookback window. Wire this prompt into your observability stack so you can track classification accuracy over time and adjust thresholds without redeploying the prompt itself.