Passage Freshness and Temporal Relevance Filter Prompt

This prompt is designed for RAG pipeline engineers and search architects who must filter retrieved passages based on temporal relevance before answer generation. It is essential for time-sensitive domains such as financial intelligence, news summarization, and operational incident response where outdated information produces factually wrong answers. The prompt assesses each passage against a reference date or the user's implied temporal intent, producing a structured freshness assessment with staleness flags and a calibrated temporal relevance score. Use this prompt as a post-retrieval filter, placed after initial vector or keyword search and before context assembly and answer generation. It assumes that passages include publication dates or that dates can be inferred from metadata.

The ideal user is a production engineer who has already observed that their RAG system returns stale information for queries like 'What is the current stock price?' or 'Summarize today's incident reports.' They need a deterministic, auditable step that prevents old passages from polluting the context window. The prompt requires a reference date—either the current system time or a date extracted from the user's query—and a list of passages with associated timestamps. Without these inputs, the prompt cannot function. Do not use this prompt when the user query is explicitly historical ('What caused the 2008 financial crisis?') or when the knowledge base contains only static reference material like mathematical proofs or physical constants. In those cases, temporal filtering adds noise rather than signal.

Before integrating this prompt, verify that your retrieval pipeline consistently surfaces publication dates or that you can infer them from metadata fields like last_updated, published_at, or ingestion_timestamp. If your document store lacks reliable date metadata, invest in extraction or enrichment before applying temporal filtering. The prompt's output includes a staleness_flag and a temporal_relevance_score for each passage, which you should log for observability. Track the distribution of these scores over time to detect drift in your knowledge base's freshness. A sudden spike in staleness flags may indicate that your ingestion pipeline has stalled or that a critical data source has stopped updating.

For high-stakes domains like financial reporting or medical guideline retrieval, do not rely solely on this prompt's freshness assessment. Implement a secondary check that compares the passage's date against a known list of critical update events (e.g., earnings releases, FDA guideline revisions). If a passage falls after a known update event but the prompt scores it as fresh, flag it for human review. This defense-in-depth approach catches cases where the model misinterprets relative date language or fails to recognize that a source has been superseded by a more recent authoritative update.

Next, review the prompt template in the following section to understand the exact input schema and output contract. Then proceed to the implementation harness section to learn how to wire this prompt into your application with validation, retries, and logging.

This prompt template evaluates whether retrieved passages are temporally appropriate for time-sensitive queries. It produces freshness assessments, staleness flags, and temporal relevance scores that your application can use to filter, rerank, or flag passages before answer generation. The template is designed for domains where information currency directly affects correctness—news summarization, financial intelligence, incident response, regulatory monitoring, and competitive analysis. Each placeholder maps to a variable your application should populate at runtime. The output schema is structured for machine consumption, making it suitable for pipeline automation rather than end-user display.

textCopy
You are a temporal relevance assessor for a retrieval-augmented generation system. Your task is to evaluate whether each provided passage is fresh enough to support accurate answers for a time-sensitive query.

## INPUT
Query: [QUERY]
Query Date: [QUERY_DATE]
Passages to evaluate:
[PASSAGES]

## PASSAGE FORMAT
Each passage includes:
- passage_id: unique identifier
- content: the passage text
- publication_date: when the passage was published or last updated (ISO 8601 format, or "unknown" if unavailable)
- source_type: the type of source (e.g., news_article, financial_filing, technical_documentation, social_media_post, research_paper, regulatory_update)

## EVALUATION CRITERIA
For each passage, assess temporal relevance by considering:
1. **Time-sensitivity of the query**: Does the query require recent information, historical context, or is it time-agnostic?
2. **Publication recency**: How close is the publication_date to the query_date?
3. **Domain decay rate**: How quickly does information in this domain become stale? (e.g., stock prices decay in minutes; legal precedents may remain valid for years)
4. **Content indicators**: Does the passage contain time-bound language ("today," "this quarter," "upcoming") that may be misleading if read later?
5. **Event anchoring**: Does the passage reference specific events, releases, or periods that define its temporal scope?

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "query_temporal_profile": {
    "time_sensitivity": "high|medium|low|time_agnostic",
    "required_recency_window": "string describing the acceptable time range (e.g., 'within 24 hours', 'past 90 days', 'any period')",
    "rationale": "brief explanation of why this query has this temporal profile"
  },
  "passage_assessments": [
    {
      "passage_id": "string",
      "freshness_score": 0.0-1.0,
      "staleness_flag": "fresh|acceptable|stale|indeterminate",
      "temporal_relevance_score": 0.0-1.0,
      "assessment_rationale": "specific evidence from the passage supporting this assessment",
      "staleness_indicators": ["list of specific time-bound phrases or references found"],
      "recommended_action": "use|use_with_caveat|exclude|request_update",
      "caveat_text": "if use_with_caveat, provide the exact warning to attach to this passage"
    }
  ],
  "overall_freshness_summary": {
    "usable_passage_count": 0,
    "stale_passage_count": 0,
    "indeterminate_count": 0,
    "recommendation": "proceed|proceed_with_caveats|insufficient_fresh_sources|request_fresher_retrieval"
  }
}

## SCORING GUIDELINES
- freshness_score: 1.0 = published within the ideal recency window for this domain; 0.0 = definitively outdated
- temporal_relevance_score: 1.0 = passage temporality perfectly matches query needs; 0.0 = temporally irrelevant regardless of recency
- staleness_flag "indeterminate": use when publication_date is "unknown" and content lacks sufficient temporal signals
- recommended_action "request_update": use when the passage would have been relevant but is now too old

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

Evaluate all passages and return only the JSON object with no additional text.

To adapt this template for your application, populate the placeholders at runtime. The [QUERY] and [QUERY_DATE] fields should come directly from the user request and system clock. The [PASSAGES] array should be constructed from your retrieval pipeline output, with each passage enriched with publication_date and source_type metadata—if your retrieval system doesn't provide these fields, add a metadata extraction step before invoking this prompt. The [CONSTRAINTS] placeholder lets you inject domain-specific rules, such as "financial data older than 15 minutes must be flagged stale" or "legal precedents from higher courts remain relevant regardless of age." The [EXAMPLES] placeholder should contain 2-4 few-shot examples showing correct assessments for your domain's typical query-passage pairs, including edge cases like passages with unknown dates or conflicting temporal signals. The [RISK_LEVEL] placeholder accepts values like "low," "medium," or "high" and should trigger different downstream behaviors—for high-risk domains such as financial trading or clinical decision support, always route staleness_flag: indeterminate and recommended_action: request_update results to human review before allowing answer generation. After receiving the model response, validate the JSON structure against the schema, check that all input passage_ids appear in the output, and verify that freshness_score and temporal_relevance_score values are within 0.0-1.0 before passing results to your filtering or reranking stage.