Time-Sensitive Query Classification Prompt

This prompt is designed for the critical routing layer that sits between the user's raw query and your retrieval infrastructure. Its job is to classify an incoming query into one of four temporal sensitivity categories: real-time, recent, historical, or time-agnostic. This classification is not an end in itself; it is a control signal that determines which index to query, which date filter to apply, or whether to bypass the static knowledge base entirely and hit a live API. The ideal user is a RAG pipeline architect or query routing engineer who manages multiple data sources with different freshness profiles—for example, a system that must answer both 'What is the current price of NVDA?' and 'Explain the efficient market hypothesis' from the same interface.

You should use this prompt when your application serves a mix of fast-moving and slow-moving domains. In a financial intelligence platform, a query about earnings requires evidence from the most recent filing period, while a query about a company's founding date is historical. Without this classification step, a naive retrieval pipeline might return a relevant but stale earnings report, producing a factually correct answer for the wrong time period. The prompt produces a structured output containing a classification label, a temporal_window recommendation (e.g., 'last 24 hours', 'Q3 2024'), and a confidence_score that you can use to trigger a human review or a fallback retrieval strategy if the model is uncertain.

Do not use this prompt when the user has already provided an explicit date filter or when your application operates in a domain with uniform freshness requirements. If a user asks 'Show me news from last Tuesday,' the temporal constraint is already parsed, and routing should rely on that explicit filter rather than a model's inference. Similarly, if your entire knowledge base is a static, versioned documentation set with no time-sensitive content, this classification step adds latency without improving retrieval quality. The prompt belongs strictly at the entry point of your retrieval pipeline, before any search or evidence fetching occurs. After classification, route the query to the appropriate downstream system: a real-time API for real-time, a recent-document index with a date filter for recent, a historical archive for historical, or a general-purpose knowledge base for time-agnostic.

This prompt template is the core classification step for any RAG pipeline or query router that needs to decide how much temporal weight to give retrieved evidence. It takes a user query and an optional set of domain constraints, then produces a structured classification label—real-time, recent, historical, or time-agnostic—along with a recommended date-range window and a confidence score. Copy the template directly into your system prompt or classification step, replace the square-bracket placeholders with your application's values, and wire the output into your retrieval filter or reranking logic.

textCopy
You are a query temporal sensitivity classifier for a retrieval-augmented generation system. Your job is to analyze a user query and determine how time-sensitive it is, then recommend an appropriate retrieval window.

## INPUT
User Query: [USER_QUERY]
Current Date: [CURRENT_DATE]
Domain Context: [DOMAIN_CONTEXT]

## CLASSIFICATION TAXONOMY
- **real-time**: The query requires information from the last few minutes to hours. Examples: breaking news, live sports scores, current stock prices, active incident status.
- **recent**: The query requires information from the last few days to weeks. Examples: this week's earnings reports, recent regulatory filings, product launch coverage from this month.
- **historical**: The query requires information from a specific past period or across a long historical range. Examples: Q2 2023 financial results, 2019 industry benchmarks, historical election data.
- **time-agnostic**: The query's answer does not depend on when the information was published. Examples: explanations of scientific concepts, how-to guides, definitions, historical facts that don't change.

## OUTPUT SCHEMA
Return a valid JSON object with exactly these fields:
{
  "classification": "real-time | recent | historical | time-agnostic",
  "confidence": 0.0-1.0,
  "recommended_date_range": {
    "start": "ISO 8601 date or null",
    "end": "ISO 8601 date or null"
  },
  "reasoning": "Brief explanation of the classification and window choice."
}

## CONSTRAINTS
- If the query mentions a specific date, date range, or relative time expression (e.g., 'last week', 'yesterday', 'Q3 2024'), factor that into the classification and recommended window.
- If the query is ambiguous about time sensitivity, default to 'recent' with a wider window and lower confidence.
- For 'time-agnostic' queries, set both start and end to null.
- For 'real-time' queries, set the end date to the current date and the start date to 24 hours before the current date unless the query specifies otherwise.
- Confidence should reflect how certain you are about the classification, not about the answerability of the query.
- Do not answer the query. Only classify it.

## EXAMPLES
Query: "What's the current price of AAPL?"
Current Date: 2025-03-15
Domain: financial market data
Output: {"classification": "real-time", "confidence": 0.95, "recommended_date_range": {"start": "2025-03-14", "end": "2025-03-15"}, "reasoning": "Stock prices require current trading data. Real-time classification with a 24-hour window to capture the latest available quote."}

Query: "Summarize Tesla's Q4 2024 earnings report."
Current Date: 2025-03-15
Domain: financial filings
Output: {"classification": "historical", "confidence": 0.92, "recommended_date_range": {"start": "2024-10-01", "end": "2025-01-31"}, "reasoning": "Query specifies a past quarter. Window covers Q4 2024 plus a buffer for earnings release timing in January 2025."}

Query: "What is a dividend yield?"
Current Date: 2025-03-15
Domain: financial education
Output: {"classification": "time-agnostic", "confidence": 0.97, "recommended_date_range": {"start": null, "end": null}, "reasoning": "Definitional query with no temporal dependency. Any well-authored source will suffice regardless of publication date."}

Query: "What happened in the markets this week?"
Current Date: 2025-03-15
Domain: financial news
Output: {"classification": "recent", "confidence": 0.88, "recommended_date_range": {"start": "2025-03-09", "end": "2025-03-15"}, "reasoning": "'This week' is a relative time expression. Window covers the current calendar week. Confidence is slightly reduced because 'markets' is broad."}

After copying this template, replace [USER_QUERY] with the incoming user message, [CURRENT_DATE] with the system timestamp in YYYY-MM-DD format, and [DOMAIN_CONTEXT] with a short description of your application's domain—such as 'financial market data,' 'breaking news,' or 'technical documentation.' The domain context helps the model calibrate its freshness expectations. If your application has additional temporal sensitivity categories, extend the taxonomy and update the output schema accordingly, but keep the JSON structure strict so downstream routing logic can parse it reliably. Always validate the JSON output before using the classification to configure retrieval filters; a malformed classification should trigger a retry or fallback to a conservative recent-evidence window.

This prompt is designed to sit at the entry point of a RAG pipeline, acting as a classifier before retrieval or generation occurs. It should be called immediately after user input is received and sanitized. The classification output—a temporal sensitivity label, a recommended time window, and a confidence score—becomes a control signal for downstream components. A real-time classification might bypass the static vector database entirely and route to a live API or streaming data source. A recent classification would apply a date filter to the retrieval query. A historical classification might relax recency filters and prioritize authoritative archival sources. A time-agnostic classification allows the standard retrieval pipeline to run without temporal constraints. The implementation must treat this prompt as a synchronous gate: the user's query should not proceed to retrieval until a valid, parseable classification is returned.

To integrate this into an application, wrap the prompt call in a function that enforces a strict output contract. Define a schema in your application code (e.g., a Pydantic model or JSON Schema) that expects classification as an enum of ['real-time', 'recent', 'historical', 'time-agnostic'], temporal_window as a structured object with start_date and end_date in ISO 8601 format or null, and confidence as a float between 0.0 and 1.0. After receiving the model response, validate it against this schema. If validation fails, implement a retry strategy with a maximum of two additional attempts, feeding the validation error message back into the prompt's [CONSTRAINTS] field as a correction hint. Log every classification attempt—including the raw query, the model's raw output, validation errors, and the final accepted classification—for observability. For high-stakes domains like financial intelligence or breaking news, route classifications with a confidence score below 0.85 to a human review queue before the query proceeds. The model choice matters: use a fast, cost-effective model (like GPT-4o-mini, Claude Haiku, or a fine-tuned small open-weight model) for this classification task, reserving larger models for the downstream generation step that benefits from deeper reasoning.

The next step after a successful classification is to use the temporal_window to parameterize your retrieval system. If the window is null (for time-agnostic queries), skip temporal filtering. Otherwise, inject the start_date and end_date as metadata filters in your vector database query (e.g., Pinecone, Weaviate, or pgvector with a publication_date field). For real-time classifications, bypass the static index and call a designated live data tool or API. To evaluate this harness, build a test suite of 50-100 labeled queries covering each classification label, including edge cases like ambiguous temporal references ('latest report'), implicit recency expectations ('current CEO'), and queries with conflicting temporal signals. Measure routing accuracy (did the query go to the correct retrieval path?) and end-to-end answer freshness. Monitor production drift by tracking the distribution of classification labels over time; a sudden drop in real-time classifications during a breaking news event signals a potential prompt or model failure. Avoid the mistake of treating this classification as advisory—if the label is ignored by downstream code, the entire temporal grounding investment is wasted.