Temporal Relevance Scoring Prompt for Hybrid Search

This prompt is for search relevance engineers and RAG developers who need to convert natural language time expressions into tunable scoring parameters for hybrid search. The job-to-be-done is not just extracting a date range, but deciding how aggressively recency should influence the final ranking when a user asks for 'recent earnings calls' or 'latest security patches.' The prompt produces a time-decay curve definition and a recency boost range, not a fixed filter clause, making it appropriate when you want temporal proximity to act as a ranking signal rather than a hard constraint.

Use this prompt when your retrieval pipeline already supports hybrid scoring (e.g., combining vector similarity, BM25, and metadata boosts) and you need a principled way to derive the recency weight from the query itself. The required inputs are the user's raw query, a reference timestamp (usually now()), and a schema for the output parameters: decay function type, half-life or decay rate, boost ceiling, and a confidence score. Do not use this prompt when the query demands a strict date filter (e.g., 'documents published after March 2024')—that is a filter generation task, not a scoring task. Similarly, avoid it when your search index lacks document timestamps or when the corpus is entirely static and recency is meaningless.

The prompt is designed for a single-turn scoring decision. If you are building a conversational system where temporal context accumulates across turns, you should pair this prompt with a Temporal Anchor Point Injection Prompt to resolve relative references like 'last week' before scoring. The output must be validated before use: confirm that the decay parameters are within sane bounds (e.g., half-life not negative, boost not exceeding your index's maximum), and log the query, output, and final ranking for offline evaluation. For high-stakes applications like financial or legal search, route outputs with confidence scores below a threshold to human review rather than silently applying a bad recency curve.

After implementing this prompt, build a regression test set of queries with known temporal intent—'urgent,' 'historical,' 'latest,' 'recent,' 'archived'—and measure whether the resulting rankings improve NDCG or recall over a baseline without temporal scoring. The most common failure mode is over-weighting recency for queries where the user's surface language implies freshness but their actual need is timeless (e.g., 'recent studies on gravity'). Your eval should catch this by including queries where relevance should override temporal signals.

This prompt template converts a user query and a set of candidate document timestamps into a temporal relevance scoring configuration. It produces a time-decay function, recency boost ranges, and a ranked explanation of when recency should dominate versus when relevance should override temporal signals. Use it inside a hybrid search pipeline where you need to blend semantic relevance with time-based ranking before returning final results to the user.

textCopy
You are a temporal relevance scorer for a hybrid search system. Your job is to analyze a user query and produce a time-decay configuration that controls how document age influences ranking.

## INPUT
Query: [QUERY]
Reference Date (ISO 8601): [REFERENCE_DATE]
Candidate Document Timestamps (ISO 8601 list): [DOCUMENT_TIMESTAMPS]

## OUTPUT SCHEMA
Return valid JSON matching this schema exactly:
{
  "temporal_intent": "high_recency" | "moderate_recency" | "balanced" | "historical" | "temporal_irrelevant",
  "decay_function": "exponential" | "linear" | "gaussian" | "step" | "none",
  "decay_parameters": {
    "half_life_days": number | null,
    "decay_rate": number | null,
    "center_date": "ISO 8601" | null,
    "std_dev_days": number | null,
    "step_thresholds": [{"before_days": number, "boost": number}] | null
  },
  "recency_boost_range": {
    "start_date": "ISO 8601" | null,
    "end_date": "ISO 8601" | null,
    "boost_factor": number
  },
  "override_conditions": [
    {
      "condition": "string describing when relevance overrides recency",
      "threshold": "string describing the override trigger"
    }
  ],
  "confidence": number,
  "rationale": "string explaining the scoring decision"
}

## CONSTRAINTS
- If the query contains no temporal language, set temporal_intent to "temporal_irrelevant" and decay_function to "none".
- If the query uses terms like "latest", "recent", "this week", "current", set temporal_intent to "high_recency".
- If the query references a specific time period like "2023", "last year", "Q2", set temporal_intent to "moderate_recency" or "historical" depending on distance from reference date.
- If the query asks for "best", "definitive", "overview", or "fundamentals" without time constraints, temporal relevance should not dominate.
- For "high_recency" intent, prefer exponential decay with a short half-life (1-30 days).
- For "historical" intent, prefer gaussian decay centered on the referenced period.
- Override conditions must describe when semantic relevance should outweigh temporal proximity.
- All dates must be ISO 8601 format.
- Confidence must be between 0.0 and 1.0.

## EXAMPLES
Query: "What are the latest developments in AI regulation?"
Reference Date: 2025-01-15
Output: temporal_intent "high_recency", exponential decay, half_life_days 14, boost_factor 2.0

Query: "Explain the transformer architecture"
Reference Date: 2025-01-15
Output: temporal_intent "temporal_irrelevant", decay_function "none", boost_factor 1.0

Query: "What happened in AI during 2023?"
Reference Date: 2025-01-15
Output: temporal_intent "historical", gaussian decay, center_date "2023-07-01", std_dev_days 180

## RISK_LEVEL: [RISK_LEVEL]
- If RISK_LEVEL is "high", include explicit override conditions and require confidence above 0.8 before applying decay.
- If RISK_LEVEL is "low", default to balanced intent when temporal signals are ambiguous.

To adapt this prompt, replace the square-bracket placeholders with your application's runtime values. The [QUERY] should be the user's raw search string. [REFERENCE_DATE] should be the current date or the session's temporal anchor in ISO 8601 format. [DOCUMENT_TIMESTAMPS] should be a JSON array of timestamps from your candidate document set, which the model uses to calibrate decay parameters against your actual data distribution. Set [RISK_LEVEL] based on your domain: use "high" for legal, financial, or medical search where incorrect temporal weighting could cause harm, and "low" for general-purpose search where occasional misweighting is acceptable. After receiving the output, validate the JSON schema before applying the decay parameters to your ranking function. If confidence is below 0.7, fall back to a default balanced decay or log the result for human review.

This prompt is not a standalone component; it is a scoring signal generator that sits between query understanding and final ranking. The typical integration point is after the initial retrieval set is gathered from both vector and keyword indexes but before the final fusion and re-ranking step. The prompt receives the user's original query and any extracted temporal expressions, then returns a time_decay_curve and a recency_boost_range that your application code applies as multiplicative weights to the retrieval candidates' timestamps. Do not pass raw document content to this prompt—it only needs the query language and, optionally, the reference date context.

Wiring the prompt into your application requires a thin orchestration layer. First, extract any explicit temporal constraints from the user query using a dedicated normalization prompt (such as the Relative Date Normalization Prompt Template) to produce ISO 8601 boundaries. Pass those boundaries and the original query text into this scoring prompt. Parse the JSON output and validate the time_decay_curve parameters: half_life_days must be a positive float, decay_function must be one of exponential, linear, or gaussian, and min_weight must be between 0.0 and 1.0. The recency_boost_range must contain valid ISO 8601 start and end dates with boost_multiplier >= 1.0. If validation fails, log the malformed output, retry once with a stricter schema constraint appended to the prompt, and fall back to a default decay curve (e.g., exponential with a 90-day half-life and 0.3 min_weight) if the retry also fails.

Model choice and latency considerations matter here because this prompt runs in the retrieval-critical path. Use a fast, cheap model for this task—GPT-4o-mini, Claude Haiku, or a fine-tuned small open-weight model are appropriate. The output schema is small and deterministic enough that a larger model provides no measurable quality gain. Cache prompt responses when the same query text and reference date appear within a session window. For high-throughput systems, consider pre-computing decay curves for common temporal expressions ('last week', 'this month', 'recent') and bypassing the LLM call entirely when a cache hit occurs. Log every call with the query hash, output parameters, validation status, and latency for later eval analysis.

The recency boost should not override relevance blindly. After applying the time-decay weights and recency boost to candidate scores, implement a relevance floor check: if a highly relevant document (vector similarity > 0.85 or keyword BM25 score in the top percentile) falls below the score threshold solely due to temporal decay, promote it back above the cutoff and log the override. This prevents the system from hiding a definitive answer just because it is slightly older than the recency window. Conversely, if the recency_boost_range multiplier pushes a very recent but low-relevance document into the top results, apply a relevance gate that requires a minimum base relevance score before the boost takes effect. These guardrails should live in your application code, not in the prompt.

Testing and eval integration should happen before deployment. Build a golden dataset of 50–100 query-reference date pairs with expected decay parameters and boost ranges. Run the prompt against this dataset and measure exact-match accuracy on decay_function, mean absolute error on half_life_days, and boundary overlap (IoU) on recency_boost_range. Flag any output where the boost range extends more than 30 days beyond the expected window or where min_weight drops below 0.1 without clear justification. In production, monitor the distribution of applied boost multipliers and decay weights; a sudden spike in extreme values (near-zero weights or 5x+ boosts) often indicates prompt drift or a model version change. Wire these metrics into your existing prompt observability dashboard alongside retrieval precision and recall.