Temporal Relevance Scoring Prompt Template

This prompt is designed for RAG pipeline engineers and search architects who need to score retrieved passages by combining their semantic relevance to a query with their temporal freshness. Use it when a standard vector similarity score is insufficient because the information value of a passage decays over time. This is critical in domains like financial intelligence, news summarization, and competitive analysis where outdated evidence produces factually wrong answers. The prompt instructs an LLM to act as a calibrated scoring function, outputting a single score between 0 and 1 for each passage along with a structured justification.

You should reach for this prompt when your retrieval system returns passages with associated publication dates and your application's answer quality depends on recency. For example, a financial analyst querying 'What is the current consensus on interest rate cuts?' needs evidence from the last few weeks, not a relevant but outdated article from six months ago. The prompt works best when you have already performed an initial retrieval pass and need a secondary scoring layer that penalizes staleness. It expects each passage to include a text field and a publication_date field in ISO 8601 format. The output is a structured JSON object containing a temporal_relevance_score between 0.0 and 1.0, a justification string explaining the score, and a breakdown of the semantic relevance and temporal freshness components.

Do not use this prompt for real-time streaming data validation or for ranking passages that lack publication dates. It is not a substitute for a time-series database query or a streaming freshness monitor. If your passages have no timestamps, use a standard relevance scoring prompt instead. This prompt also assumes you have already defined a domain-specific decay function or half-life parameter; if you haven't, you'll need to calibrate that separately using a held-out dataset of known-answer queries. For high-stakes domains like healthcare or legal, always include a human review step after scoring to verify that the temporal weighting hasn't excluded critical evidence that ages differently than the model assumes.

This template is designed to be dropped directly into your RAG pipeline's scoring or reranking stage. It instructs the model to evaluate each passage against both semantic relevance and temporal freshness, producing a single calibrated score between 0 and 1. The prompt enforces structured output, requires explicit reasoning for each score, and includes a time-decay justification so that scoring decisions are auditable. Replace every square-bracket placeholder with your actual data before sending the request.

textCopy
You are a temporal relevance scoring engine. Your task is to evaluate a set of retrieved passages against a user query, producing a calibrated relevance score (0.0 to 1.0) that combines semantic relevance with temporal freshness.

## INPUT
Query: [QUERY]
Query Date: [QUERY_DATE]
Domain: [DOMAIN]
Temporal Sensitivity: [TEMPORAL_SENSITIVITY]
  Options: real-time | recent | historical | time-agnostic

Passages to score:
[PASSAGES]
  Format: One passage per line, starting with "PASSAGE_ID: <id> | DATE: <publication_date> | TEXT: <text>"

## SCORING RULES
1. Semantic Relevance (0.0-1.0): How well does the passage content answer or inform the query?
2. Temporal Freshness (0.0-1.0): How current is the passage relative to the query date and temporal sensitivity?
   - real-time: Decay sharply after [REAL_TIME_WINDOW_HOURS] hours. Score 0.0 if older.
   - recent: Apply exponential decay with half-life of [RECENT_HALF_LIFE_DAYS] days.
   - historical: Minimal decay. Prefer primary sources from the correct period.
   - time-agnostic: Ignore publication date. Score 1.0 for freshness.
3. Combined Score = (semantic_relevance * [SEMANTIC_WEIGHT]) + (temporal_freshness * [FRESHNESS_WEIGHT])
   Default weights: semantic=0.6, freshness=0.4 unless overridden.
4. If a passage contains no usable date, set temporal_freshness to 0.0 and flag it.
5. If the combined score is below [MIN_SCORE_THRESHOLD], mark the passage as EXCLUDED.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "query_id": "[QUERY_ID]",
  "scored_passages": [
    {
      "passage_id": "string",
      "semantic_relevance": 0.0,
      "temporal_freshness": 0.0,
      "combined_score": 0.0,
      "excluded": false,
      "reasoning": "Brief explanation of both scores.",
      "decay_function_applied": "none | real-time-cutoff | exponential | historical-preference",
      "date_used": "ISO8601 or null",
      "flags": ["no_date"]
    }
  ],
  "scoring_summary": {
    "total_passages": 0,
    "excluded_count": 0,
    "top_passage_id": "string",
    "score_distribution": {
      "high": 0,
      "medium": 0,
      "low": 0
    }
  }
}

## CONSTRAINTS
- Do not invent dates. If a passage has no date, set temporal_freshness to 0.0 and add the "no_date" flag.
- Do not exceed 1.0 or go below 0.0 for any score.
- Return ONLY the JSON object. No markdown fences, no commentary.
- Score every passage in the input list. Do not skip any.

After pasting this template, replace the placeholders with your runtime values. The [PASSAGES] placeholder should be populated with your retrieval results, one per line in the specified format. The temporal sensitivity classification and decay parameters should come from an upstream query classifier or be set as constants for your domain. Wire the output JSON into your reranking logic, filtering out passages marked as EXCLUDED before they reach answer generation. For high-stakes domains like financial intelligence or clinical decision support, route excluded passages and low-confidence scores to a human review queue before final answer synthesis.

The Temporal Relevance Scoring Prompt is not a standalone utility—it is a scoring module that sits between retrieval and answer generation in a RAG pipeline. After your retriever returns candidate passages, each passage is sent through this prompt to produce a calibrated 0–1 score that combines semantic relevance with temporal freshness. The output is a structured JSON object per passage, which your application must validate, aggregate, and use to rerank or filter passages before they reach the answer-generation step. The harness described here assumes you are running this prompt at scale, potentially scoring dozens of passages per query, and need reliable, auditable scores rather than one-off manual evaluations.

Integration pattern. Wrap the prompt in a scoring function that accepts a query string, a passage object (with text, publication_date, and optional source_authority), and a temporal_sensitivity classification from an upstream query classifier. The function should construct the prompt by injecting these values into the [QUERY], [PASSAGE_TEXT], [PUBLICATION_DATE], [QUERY_TIMESTAMP], and [TEMPORAL_SENSITIVITY] placeholders. For production, batch passage scoring into concurrent API calls with a configurable concurrency limit (start with 5–10 parallel requests) and a timeout of 5 seconds per call. On timeout or HTTP 5xx, retry once with exponential backoff (1s initial delay). On a second failure, log the passage ID and assign a default score of 0.0 with a scoring_error flag so downstream reranking can degrade gracefully rather than blocking the entire pipeline.

Output validation. The prompt returns a JSON object with fields: relevance_score (float, 0–1), freshness_score (float, 0–1), combined_score (float, 0–1), time_decay_factor (float, 0–1), rationale (string), and stale_flag (boolean). Before trusting these scores, validate every response: check that all numeric fields are present, within [0,1], and that combined_score is not greater than max(relevance_score, freshness_score) plus a small epsilon (0.05) to catch calculation errors. If validation fails, discard the score and log the raw response for debugging. For high-stakes domains like financial intelligence or clinical evidence, route any passage where stale_flag is true and combined_score exceeds 0.5 to a human review queue—this catches cases where the model may have scored stale content too highly due to strong semantic match.

Calibration and evals. Before deploying, run this prompt against a golden dataset of 100–500 query-passage pairs with human-annotated relevance and freshness scores. Measure Mean Absolute Error (MAE) between model combined_score and human scores; target MAE < 0.15. Also measure calibration: bucket predictions into deciles and check that the proportion of truly relevant passages in each bucket matches the predicted score. If the model is overconfident (high scores for irrelevant passages), adjust the prompt's scoring rubric or add few-shot examples of borderline cases. Run this calibration check weekly if your document corpus or query distribution changes. Log every scored passage with its query, passage ID, scores, and the model version to enable drift detection over time.

Model choice and latency. This prompt works well with fast instruction-following models (GPT-4o-mini, Claude 3.5 Haiku, or equivalent open-weight models like Llama 3.1 8B). Avoid using largest models for per-passage scoring unless latency and cost are not constraints—scoring 20 passages with a large model can add 10–20 seconds to your pipeline. If scoring latency exceeds your p95 target, consider batching multiple passages into a single prompt with an array output schema, but validate that batch scoring does not degrade score calibration compared to single-passage scoring. For air-gapped or local deployments, quantized 7B–13B models can perform this task reliably if you include 3–5 few-shot examples in the prompt to anchor the scoring scale.

What to avoid. Do not use this prompt as the sole gatekeeper for answer generation without a downstream grounding verification step—a high combined score does not guarantee the passage actually supports the final answer. Do not skip output validation; malformed JSON or out-of-range scores will silently corrupt your reranking logic. Do not hardcode the time-decay function in application code and expect the prompt to match it; instead, describe the decay behavior in the prompt's [TEMPORAL_SENSITIVITY] context and let the model apply it, then validate the resulting time_decay_factor against your expected decay curve during eval. Finally, do not treat this prompt as static—recalibrate when your retrieval system, document corpus freshness profile, or user query patterns change meaningfully.