Evidence Ranking with Temporal Decay Prompt Template

This prompt is designed for RAG pipelines where the recency of information is a first-class ranking signal, not an afterthought. Use it when your application serves time-sensitive domains—news summarization, financial intelligence, market analysis, competitive monitoring, or operational dashboards—where evidence older than a few days or hours can be misleading or factually wrong. The prompt assumes you already have a retrieval set with reliable publication timestamps and a clear reference date (typically 'now' in production). It does not perform retrieval itself; it expects pre-retrieved passages, their metadata, and a query as inputs. The core job-to-be-done is transforming a flat list of relevant-but-possibly-stale passages into a decay-adjusted ranking that a downstream answer generator or citation selector can trust.

The prompt applies a configurable decay function—you control the half-life, decay curve shape, and minimum weight floor—so older passages don't disappear entirely but are appropriately discounted. This is critical for queries like 'What is the current market sentiment on X?' where a highly relevant analysis from six months ago may still provide useful context but should not outrank a slightly less detailed report from yesterday. Do not use this prompt when your domain is largely time-invariant (e.g., code documentation, scientific fundamentals, historical research) or when your retrieval set lacks reliable timestamps. In those cases, a standard relevance-only ranking prompt from the Evidence Ranking and Prioritization group will be simpler and less prone to misconfiguration. Also avoid this prompt if your upstream retrieval already applies aggressive time-based filtering—double-decaying will distort rankings.

Before deploying, verify three prerequisites: (1) every passage in your retrieval set carries a parseable published_date or timestamp field in a consistent format; (2) you have defined a decay configuration (half-life duration, decay function type like exponential or gaussian, and a minimum weight threshold) that matches your domain's information velocity; and (3) your evaluation pipeline includes time-sensitive test queries where stale-but-relevant passages exist alongside fresh-but-less-relevant ones, so you can measure whether the decay-adjusted ranking improves downstream answer quality. If you cannot satisfy these prerequisites, start with a simpler ranking prompt and add temporal decay once your metadata pipeline and eval set are ready.

This template is designed to be pasted directly into your system prompt or user message template. It instructs the model to rank a list of evidence passages against a user query, applying a temporal decay function to prioritize recent information. The prompt uses square-bracket placeholders for all dynamic inputs, making it safe for programmatic substitution in your application code. Before using this in production, you must define your decay function and output schema in the [CONSTRAINTS] and [OUTPUT_SCHEMA] blocks.

textCopy
You are an evidence ranking system. Your task is to rank the provided evidence passages by their relevance to the user's query, applying a temporal decay function to prioritize more recent information.

## USER QUERY
[QUERY]

## CURRENT REFERENCE DATE
[REFERENCE_DATE]

## EVIDENCE PASSAGES
[EVIDENCE_LIST]

## RANKING CONSTRAINTS
[CONSTRAINTS]

## OUTPUT FORMAT
[OUTPUT_SCHEMA]

## FEW-SHOT EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. For each passage, calculate a base relevance score (0.0 to 1.0) indicating how well it answers the user query.
2. Apply the temporal decay function specified in the constraints to the base relevance score, using the passage's publication date and the reference date.
3. Rank all passages by their final decay-adjusted score in descending order.
4. If a passage's publication date is missing, treat it as the oldest possible date or apply a default penalty as specified in the constraints.
5. Output the ranked list strictly according to the provided output schema.
6. If the evidence set is empty, return an empty ranking.

To adapt this template, replace each placeholder with the appropriate values for your application. The [QUERY] is the user's time-sensitive question. [REFERENCE_DATE] should be the current date or the 'as of' date for the ranking, in ISO 8601 format. [EVIDENCE_LIST] must be a pre-retrieved set of passages, each with a unique ID, text content, and a publication date. The [CONSTRAINTS] block is where you define the exact temporal decay formula (e.g., exponential decay with a configurable half-life) and any domain-specific rules, such as absolute staleness cutoffs. The [OUTPUT_SCHEMA] must specify the exact JSON structure for the ranked list, including fields for passage ID, final score, and a brief rationale. Providing 2-3 diverse [EXAMPLES] in the few-shot block is critical for calibrating the model's scoring behavior and ensuring it correctly applies the decay function. Always validate the output against your schema before using the ranking in a downstream answer generation step.

The Evidence Ranking with Temporal Decay prompt is designed to sit between your retrieval step and your answer generation step in a RAG pipeline. After your retriever returns a candidate set of passages with timestamps, this prompt re-ranks them by balancing semantic relevance against a configurable recency weight. The output is a ranked list that your downstream answer generator or citation selector can consume directly. Do not use this prompt as a standalone ranker on static corpora where all documents are equally fresh—the temporal decay logic will distort rankings when recency is irrelevant.

To wire this into an application, construct the prompt payload with three required inputs: [QUERY] (the user's question), [PASSAGES] (a JSON array of objects with id, text, and timestamp fields), and [DECAY_CONFIG] (an object specifying half_life_days, min_weight, and relevance_weight). Validate these inputs before calling the model: timestamps must parse as ISO 8601, the half-life must be positive, and the relevance weight should be between 0 and 1. On the output side, enforce a strict JSON schema with fields ranked_passages (ordered array of id, score, rationale), decay_applied (boolean), and config_used (echoed config). If the model returns malformed JSON, run a repair pass using a lightweight validator like jsonschema in Python. Log every ranking call with the query hash, passage count, decay config, and output schema validity for later debugging.

For production deployments, choose a model that reliably follows structured output instructions—GPT-4o or Claude 3.5 Sonnet with strict JSON mode enabled are good starting points. Implement a retry loop with exponential backoff (max 3 attempts) for schema validation failures. If the ranking output is used in high-stakes domains like financial intelligence, add a human review step for rankings where the top passage score falls below a configurable threshold or where the score gap between rank 1 and rank 2 is less than 0.1. Avoid calling this prompt on retrieval sets larger than 20 passages without chunking—most models exhibit position bias and ranking degradation with long lists. Finally, instrument the harness with trace logging that captures the decay config, input passage count, output ranking length, and validation status so you can detect drift when model behavior or data distributions change.