Source Date and Freshness Ranking Prompt

This prompt is for RAG system builders who need to rank retrieved passages by both relevance and recency before answer synthesis. It is designed for knowledge bases where document dates matter: product documentation with versioned releases, financial filings with reporting periods, legal databases with precedents that evolve, news archives, or technical documentation that changes across releases. The prompt produces a freshness-weighted ranking that explicitly distinguishes between queries where recency is critical ('latest security patch') and queries where it is irrelevant ('definition of a derivative'). Use this prompt when your retrieval step returns passages with associated dates and you need to surface the most temporally appropriate evidence before generating an answer.

Before wiring this into your pipeline, verify that your retrieval step reliably returns date metadata for each passage. The prompt expects a publication_date or last_modified field in ISO 8601 format. If your knowledge base lacks this, you will need a preprocessing step to extract or infer dates before invoking the ranking prompt. Additionally, calibrate your staleness thresholds: a security advisory might be stale after 30 days, while a tax regulation might remain current for years. The prompt template includes a [STALENESS_THRESHOLD] variable that lets you define domain-specific freshness windows. For high-stakes domains like legal or clinical RAG, always pair this prompt with a human review step when the ranking deprioritizes a source that a user might reasonably expect to see.

Do not use this prompt when your knowledge base lacks reliable date metadata, when all sources are equally current, or when the user query contains no temporal signal whatsoever. In those cases, a standard relevance-only ranking prompt will produce better results without introducing spurious recency bias. If you are unsure whether temporal signals exist in your queries, run an eval set that includes both time-sensitive and time-agnostic questions and measure whether the freshness weighting improves or degrades answer accuracy. Start with a low recency weight and increase it only when your eval data justifies the trade-off.

This prompt template is designed to be wired into your RAG pipeline after retrieval but before answer synthesis. It takes a user query, a set of retrieved passages with source dates, and a set of configurable constraints to produce a ranked list that balances topical relevance against temporal freshness. The template uses square-bracket placeholders for all dynamic inputs, making it safe to copy directly into your prompt management system or codebase without accidental token injection.

codeCopy
You are a temporal evidence ranker for a retrieval-augmented generation system. Your job is to re-rank a set of retrieved passages by balancing their topical relevance to the user's query against their source date freshness.

[INPUT]
User Query: [QUERY]
Current Date: [CURRENT_DATE]
Retrieved Passages:
[PASSAGES]

[CONSTRAINTS]
- Time Sensitivity Classification: [TIME_SENSITIVITY]
- Staleness Threshold (days): [STALENESS_THRESHOLD]
- Recency Weight: [RECENCY_WEIGHT]
- Relevance Weight: [RELEVANCE_WEIGHT]
- Minimum Sources to Return: [MIN_SOURCES]
- Maximum Sources to Return: [MAX_SOURCES]

[OUTPUT_SCHEMA]
Return a JSON object with the following structure:
{
  "query_time_sensitivity": "high|medium|low|none",
  "staleness_threshold_applied_days": number,
  "ranked_passages": [
    {
      "passage_id": "string",
      "rank": number,
      "relevance_score": 0.0-1.0,
      "freshness_score": 0.0-1.0,
      "combined_score": 0.0-1.0,
      "source_date": "YYYY-MM-DD",
      "days_since_publication": number,
      "freshness_justification": "string explaining why this date matters or doesn't matter for this query",
      "relevance_justification": "string explaining topical match to query"
    }
  ],
  "excluded_passages": [
    {
      "passage_id": "string",
      "exclusion_reason": "stale|irrelevant|redundant|below_threshold",
      "detail": "string"
    }
  ],
  "ranking_methodology": "string summarizing how recency and relevance were balanced"
}

[EXAMPLES]
Example 1 - Time-Sensitive Query:
Query: "What are the latest COVID-19 booster recommendations?"
Current Date: 2025-06-15
Time Sensitivity: high
Expected behavior: Passages older than 90 days should be heavily penalized. A highly relevant passage from 2024 should rank below a moderately relevant passage from May 2025.

Example 2 - Timeless Query:
Query: "Explain the second law of thermodynamics."
Current Date: 2025-06-15
Time Sensitivity: none
Expected behavior: Source date should have negligible impact on ranking. A highly relevant passage from 2019 should outrank a tangentially relevant passage from 2025.

Example 3 - Mixed Sensitivity:
Query: "What are the best practices for Python async programming?"
Current Date: 2025-06-15
Time Sensitivity: medium
Expected behavior: Prefer passages from the last 2 years, but foundational explanations from older sources should still rank if they remain accurate and highly relevant.

[TOOLS]
No external tools are available. You must work only with the provided passages and their metadata.

[RISK_LEVEL]
Medium. Incorrect freshness ranking can surface outdated information for time-sensitive queries. For high-stakes domains such as medical or legal, human review of the final ranked set is required before answer synthesis.

Now, rank the passages according to the constraints above and return the JSON output.

To adapt this template for your pipeline, start by defining how your system classifies time sensitivity. You can either pass a pre-classified [TIME_SENSITIVITY] value from an upstream classifier prompt, or remove that field and let this prompt infer sensitivity from the query itself. The [STALENESS_THRESHOLD] should be set based on your domain: 30 days for news, 90 days for technical documentation, 365 days for academic literature, or null for timeless knowledge bases. The [RECENCY_WEIGHT] and [RELEVANCE_WEIGHT] values should sum to 1.0 and can be tuned per query type. For production use, always validate the JSON output against the schema before passing ranked passages to your synthesis prompt. Log exclusion reasons and freshness justifications to enable debugging when users report stale answers. If your system handles high-stakes domains, route passages flagged with high time sensitivity and low freshness scores to a human review queue before they reach the answer generation stage.

This prompt is designed to sit between retrieval and answer synthesis in a RAG pipeline. It expects a list of retrieved passages with associated date metadata and a user query. The output is a ranked list with freshness scores, staleness flags, and explicit reasoning about why temporal relevance matters for this specific query. The harness must handle cases where date metadata is missing, ambiguous, or conflicting, and must enforce the output schema before passing results downstream.

Input Assembly: Before calling the model, assemble the [RETRIEVED_PASSAGES] array with each passage containing id, text, publication_date (ISO 8601), and optional last_updated and content_type fields. The [USER_QUERY] should be passed verbatim. Add a [TEMPORAL_CLASSIFICATION] field if you have a pre-classifier that tags queries as time_sensitive, time_aware, or timeless—this helps the prompt calibrate its freshness weighting. If dates are missing, inject a date_confidence field set to null and let the prompt's explicit handling rules decide how to treat undated sources rather than guessing.

Output Validation: The prompt returns a JSON object with a ranked_passages array. Each entry must contain passage_id, freshness_score (0.0–1.0), relevance_score (0.0–1.0), combined_score, rank, staleness_flag (boolean), and rationale. Implement a post-processing validator that checks: all input passage IDs appear exactly once in the output, scores are within bounds, ranks are sequential and unique, and the staleness_flag is consistent with any configured threshold (e.g., passages older than [STALENESS_THRESHOLD_DAYS] should be flagged unless the query is classified as timeless). Reject and retry malformed outputs up to [MAX_RETRIES] times, escalating to a fallback ranking (chronological or retrieval-score-only) after exhaustion.

Model Choice and Latency: This is a ranking and reasoning task that benefits from strong instruction-following models. Use Claude 3.5 Sonnet, GPT-4o, or equivalent for production. For high-throughput pipelines, consider a smaller model (Claude 3 Haiku, GPT-4o-mini) with stricter output validation and a higher retry budget. Cache the prompt prefix (system instructions and output schema) to reduce latency and cost. If your retrieval set exceeds ~20 passages, pre-filter to the top-N by retrieval score before invoking this prompt to stay within context window limits.

Observability and Eval: Log every invocation with: input passage count, query temporal classification, output ranking distribution, staleness flag count, validation pass/fail, retry count, and latency. Run periodic eval suites comparing model-assigned freshness scores against ground-truth temporal relevance judgments. Watch for drift patterns: over-prioritizing recency on timeless queries, ignoring recent updates to older documents, or inconsistent staleness flagging across similar date gaps. If your application is in a regulated domain (legal, financial, clinical), route staleness-flagged passages to a human review queue before they reach answer synthesis, and log the reviewer's decision for future calibration.

Integration Point: Wire the validated output directly into your answer synthesis prompt by passing the ranked_passages array as [RANKED_EVIDENCE]. Include the staleness_flag and rationale fields so the synthesis prompt can adjust its certainty language (e.g., 'According to a 2019 source...' vs. 'Recent guidance from 2024 indicates...'). Do not silently drop staleness-flagged passages—let the synthesis prompt decide whether to include them with appropriate caveats or exclude them based on your product's freshness policy.