Evidence Freshness Decay Scoring Prompt

This prompt is designed for RAG pipeline architects and search ranking engineers who need to incorporate temporal awareness into evidence scoring. Use it when your retrieval system returns documents spanning months or years and downstream answer quality depends on prioritizing recent information. The prompt applies a configurable decay function to an existing evidence relevance score based on the evidence age, a domain-specific half-life, and the query's time sensitivity. It is designed to be inserted as a re-ranking or scoring step after initial retrieval and before answer generation, and it assumes you already have a base relevance score for each evidence passage and reliable publication or crawl dates.

This approach is most effective in fast-moving domains where information becomes stale predictably. Examples include security vulnerability databases where a CVE from last month is far more actionable than one from 2019, financial earnings data where last quarter's report matters more than a report from three years ago, news summarization where yesterday's article is more relevant than last year's coverage, and incident response where recent postmortems carry more weight than historical ones. In each case, the decay function should be tuned to the domain's natural information half-life: hours for breaking news, days for incident response, quarters for financial reports, and years for scientific literature. The prompt includes a staleness threshold configuration so you can explicitly deprioritize or exclude evidence that has aged past usefulness.

Do not use this prompt when temporal relevance is irrelevant to answer quality. Evergreen domains such as mathematical proofs, historical analysis, philosophical arguments, or stable technical documentation should not apply freshness decay because older evidence may be equally or more authoritative. Applying decay in these domains introduces a recency bias that degrades answer quality. Similarly, avoid this prompt when your retrieval system already handles temporal ranking through index-time boosting or when publication dates are unreliable or missing. If more than 20% of your evidence lacks trustworthy dates, temporal decay will introduce noise rather than signal. For queries that explicitly ask for historical or archival information, set the time-sensitivity parameter to zero or bypass the decay step entirely.

Before deploying this prompt in production, validate that your decay parameters produce sensible rankings on a golden dataset of queries with known temporally-correct answers. Watch for two common failure modes: over-decay where moderately aged but still-relevant evidence is incorrectly buried, and under-decay where the half-life is set too long and stale evidence persists in top ranks. Run A/B comparisons against a baseline without decay to confirm the temporal signal improves answer quality rather than just shuffling rankings. For high-stakes domains such as medical guidelines or legal precedents, always include a human review step before final answer generation, because temporal decay can inadvertently suppress authoritative sources that happen to be older but remain the standard of care or controlling law.

This prompt template implements a temporal decay scoring function for evidence passages. It evaluates each piece of evidence against the query's time-sensitivity requirements, the evidence's publication or modification date, and a configurable domain half-life to produce a freshness score. The template is designed to be wired into a RAG re-ranking pipeline where stale evidence must be deprioritized before answer generation. Use this when your retrieval corpus spans multiple time periods and your queries have implicit or explicit recency requirements—such as in news summarization, financial intelligence, incident response, or regulatory monitoring systems.

textCopy
You are an evidence freshness evaluator for a retrieval-augmented generation system. Your task is to assign a freshness decay score to each evidence passage based on its age, the domain's information half-life, and the query's time-sensitivity.

[INPUT]
Query: [QUERY]
Query Time-Sensitivity: [TIME_SENSITIVITY] (Choose one: high, medium, low, none)
Current Date: [CURRENT_DATE]
Evidence Passages:
[EVIDENCE_PASSAGES]

[CONSTRAINTS]
1. For each passage, compute a freshness score between 0.0 (completely stale) and 1.0 (fully current).
2. Apply the domain half-life specified in [DOMAIN_HALF_LIFE] days. Evidence older than the half-life should receive a score no higher than 0.5 unless the query time-sensitivity is "none."
3. If query time-sensitivity is "high," apply an aggressive decay: evidence older than [STALENESS_THRESHOLD_HIGH] days must score below 0.3.
4. If query time-sensitivity is "low" or "none," decay should be gradual. Do not penalize older evidence for evergreen or historical queries.
5. Evidence with missing or unparseable dates must be flagged with a freshness score of null and a reason of "MISSING_DATE."
6. Do not modify the original evidence content or the existing relevance score. Append the freshness fields only.

[OUTPUT_SCHEMA]
Return a JSON object with the following structure:
{
  "query_freshness_assessment": {
    "time_sensitivity": "[high|medium|low|none]",
    "applied_half_life_days": number,
    "staleness_threshold_applied": number | null,
    "rationale": "Brief explanation of the decay function applied."
  },
  "passages": [
    {
      "passage_id": "string",
      "original_relevance_score": number,
      "publication_date": "string | null",
      "age_in_days": number | null,
      "freshness_score": number | null,
      "freshness_rationale": "string",
      "staleness_flag": "current | aging | stale | evergreen | missing_date"
    }
  ]
}

[EXAMPLES]
Example Input:
Query: "Latest GPU driver release notes for vulnerability CVE-2024-0091"
Time-Sensitivity: high
Current Date: 2024-11-15
Domain Half-Life: 30 days
Staleness Threshold (High): 90 days
Evidence: [{"passage_id": "p1", "content": "NVIDIA driver 550.90 patch notes from October 2024...", "publication_date": "2024-10-20", "relevance_score": 0.94}]

Example Output:
{
  "query_freshness_assessment": {
    "time_sensitivity": "high",
    "applied_half_life_days": 30,
    "staleness_threshold_applied": 90,
    "rationale": "Security vulnerability queries require current patch information. Applied aggressive decay with a 90-day staleness cutoff."
  },
  "passages": [
    {
      "passage_id": "p1",
      "original_relevance_score": 0.94,
      "publication_date": "2024-10-20",
      "age_in_days": 26,
      "freshness_score": 0.87,
      "freshness_rationale": "Published 26 days ago, within the 30-day half-life. Slight decay applied but evidence remains highly current for this security query.",
      "staleness_flag": "current"
    }
  ]
}

[TOOLS]
No external tools are required. Perform all date calculations using the provided current date.

[RISK_LEVEL]
Medium. Incorrect staleness flags can cause the downstream RAG system to use outdated security or financial information. Always validate that evergreen domains (e.g., historical analysis, scientific fundamentals) are not subjected to aggressive decay. If time-sensitivity is ambiguous, default to "medium" and document the assumption.

To adapt this template for your application, replace the bracketed variables with data from your retrieval pipeline. The [EVIDENCE_PASSAGES] placeholder should receive a JSON array of passage objects, each containing at minimum a passage_id, content, publication_date, and relevance_score. The [DOMAIN_HALF_LIFE] and [STALENESS_THRESHOLD_HIGH] values should be calibrated per domain—financial news may use a 7-day half-life, while academic literature may use 365 days or more. For evergreen domains, set [TIME_SENSITIVITY] to "none" and the decay function will preserve all scores near 1.0 regardless of age.

Before deploying this prompt into a production re-ranking pipeline, validate the output against a golden dataset of passages with known publication dates and expected staleness flags. Pay particular attention to edge cases: evidence published today should always score 1.0, evidence with missing dates must not silently receive a default score, and queries marked as time-insensitive must not have their evidence unfairly penalized. After scoring, the downstream selection step should multiply the original relevance score by the freshness score (or apply a weighted combination) to produce the final ranking. If the freshness score is null due to a missing date, escalate the passage for human review or exclude it with a logged warning rather than silently admitting it to the ranked list.

This prompt is designed to operate as a scoring microservice within a larger retrieval pipeline, not as a standalone chat interaction. It receives a batch of evidence passages, each with a publication or crawl date, and returns decay-adjusted scores. The implementation harness must handle date parsing, decay function configuration, and score normalization before the results are consumed by a downstream re-ranker or evidence selector. Because freshness decay is domain-specific, the harness should expose configurable half-life parameters and staleness thresholds rather than hardcoding them into the prompt.

Wire the prompt into your application as a post-retrieval scoring step. After your initial retrieval returns candidate passages with metadata, extract the [PUBLICATION_DATE] for each passage and the [QUERY_TIMESTAMP] from the user request. Pass these into the prompt along with the [DOMAIN_HALF_LIFE] and [STALENESS_THRESHOLD] configured for your domain. The model returns a structured JSON array with original scores, decay multipliers, and adjusted scores. Validate the output schema strictly: every passage must receive a decay multiplier between 0.0 and 1.0, and the adjusted score must equal the original score multiplied by the decay multiplier. Reject any response that fails schema validation or contains scores outside the expected range, and retry with a stricter output constraint instruction. Log every scoring decision, including the passage ID, publication date, decay multiplier, and adjusted score, so that pipeline operators can audit freshness decisions later.

For high-stakes domains such as financial intelligence or medical literature, route passages that fall below the staleness threshold to a human review queue instead of silently discarding them. The model's staleness classification is a strong signal but not infallible—an evergreen research paper might be incorrectly flagged as stale if the publication date metadata is missing or malformed. Implement a pre-prompt date validation step that rejects passages with unparseable or missing dates before they reach the model, returning an explicit error to the pipeline operator rather than allowing the model to guess. When deploying to production, run periodic eval checks comparing the model's decay decisions against domain-expert judgments on a golden dataset of passages with known freshness characteristics, and recalibrate the half-life parameter if systematic drift is detected.