Freshness-Aware Query Rewriting Prompt

This prompt transforms a user's original question into one or more retrieval-optimized queries that include explicit temporal constraints. It is designed for retrieval-augmented generation (RAG) systems, search pipelines, and AI applications where answer quality depends on accessing the most current information. Use this prompt when your retrieval index contains documents spanning a wide date range and your users ask questions that imply a recency requirement, such as 'What is the latest research on...' or 'Show me recent earnings reports.' This prompt belongs in the query rewriting stage of your pipeline, after the user submits a question but before you call your vector database, search API, or hybrid retrieval system. It reduces the risk of retrieving outdated evidence that would produce factually wrong answers in fast-moving domains like finance, news, legal filings, and scientific research.

The ideal deployment scenario is a production RAG pipeline where your retrieval index mixes documents from multiple years and your users expect time-aware answers. Wire this prompt as a preprocessing step that runs before every retrieval call when the upstream query classifier flags the question as time-sensitive. If you already have a Time-Sensitive Query Classification Prompt in your pipeline, route only queries classified as real-time or recent through this rewriting step. For queries classified as historical or time-agnostic, skip the rewrite to avoid adding unnecessary date filters that could exclude relevant older documents. The prompt expects a user query string and an optional current date; it returns one or more rewritten queries with explicit date ranges, recency keywords, or temporal operators suitable for your retrieval system's filter syntax.

Do not use this prompt when your retrieval index is already partitioned by date and your search API accepts native date-range filters. In that case, pass the temporal constraints directly as API parameters rather than embedding them in the query text. Also avoid this prompt when your knowledge base is inherently static—such as a corpus of historical legal opinions or a fixed scientific reference set—because adding recency constraints would artificially narrow retrieval without improving answer quality. For low-latency applications where the added rewrite step introduces unacceptable delay, consider caching rewritten queries for common temporal patterns or using a lightweight rule-based date extraction approach instead. Before deploying, validate the rewritten queries against your retrieval system's actual filter syntax and run an A/B test comparing retrieval precision with and without temporal expansion using the eval framework described in the Implementation Harness section.

This prompt template rewrites a user query to include temporal constraints, date-range filters, and recency preferences. It is designed to sit between the user input and your retrieval system, transforming ambiguous or time-agnostic questions into queries that explicitly encode freshness requirements. The template uses square-bracket placeholders so you can swap in your own query, current date, domain-specific freshness rules, and output format without touching the instruction logic.

textCopy
You are a query rewriting assistant for a retrieval system. Your job is to rewrite the user's original query so that it includes explicit temporal constraints, date-range filters, and recency preferences. Do not answer the query. Only produce the rewritten query or queries.

Original Query: [USER_QUERY]
Current Date: [CURRENT_DATE]
Domain Freshness Rules:
[DOCUMENT_FRESHNESS_RULES]

Instructions:
1. Classify the query's temporal sensitivity as one of: real-time, recent, historical, or time-agnostic.
2. If the query is time-sensitive, rewrite it to include:
   - An explicit date range or recency window (e.g., "after 2024-06-01", "last 30 days", "Q3 2024").
   - Temporal keywords that retrieval systems can map to metadata filters.
3. If the query is time-agnostic, return the original query unchanged and explain why no temporal expansion is needed.
4. If the query references an event, earnings report, filing, or news item, infer the relevant time period from the domain rules and the current date.
5. Produce up to [MAX_VARIANTS] rewritten query variants with different temporal scopes when the appropriate window is ambiguous.
6. For each rewritten query, include a brief justification of the temporal constraint chosen.

Output Format:
{
  "temporal_sensitivity": "real-time | recent | historical | time-agnostic",
  "rewritten_queries": [
    {
      "query": "rewritten query string with temporal constraints",
      "temporal_window": "explicit date range or recency description",
      "justification": "why this temporal scope was selected"
    }
  ],
  "original_query_unchanged": false
}

Constraints:
- Never invent dates that are not implied by the query or domain rules.
- Use ISO 8601 date formats (YYYY-MM-DD).
- If the current date is provided, use it as the reference point for relative windows.
- Do not add temporal constraints that would exclude obviously relevant results.

To adapt this template, replace [USER_QUERY] with the incoming user question, [CURRENT_DATE] with today's date in ISO 8601 format, and [DOCUMENT_FRESHNESS_RULES] with your domain-specific rules (for example, "financial earnings data is stale after 90 days; breaking news is stale after 24 hours"). Set [MAX_VARIANTS] to a number between 1 and 5 depending on how many retrieval passes your pipeline can afford. The output is structured JSON, so wire a schema validator after the model response to catch malformed fields before the rewritten queries reach your retriever. If the model classifies the query as time-agnostic and returns original_query_unchanged: true, skip temporal expansion and pass the original query directly to retrieval.