News Summarization Freshness Check Prompt

This prompt is a temporal gatekeeper for news aggregation and summarization pipelines. Its core job is to evaluate a set of already-retrieved news articles and determine if they are fresh enough to be used for a breaking-news or daily-briefing summary. The ideal user is a system builder who has already solved the retrieval problem—fetching articles from APIs, RSS feeds, or search indices—but now faces the challenge of temporal quality control. The prompt ingests articles with their publication dates and a target freshness window (e.g., 'last 4 hours'), and it outputs a structured assessment: a binary stale/fresh flag for each article, a confidence score, and a concise reason for any staleness determination. This allows downstream summary generation steps to operate only on temporally valid source material, preventing a breaking-news alert from being generated from yesterday's report.

You should use this prompt when your pipeline aggregates from sources with inconsistent or unreliable publication timelines, such as a mix of fast-moving wires, slower editorial pieces, and social media embeds. It is particularly valuable when the cost of presenting stale information is high—for instance, in financial market briefings, crisis response summaries, or competitive intelligence digests. The prompt is designed to be a deterministic filter in a multi-step RAG architecture. A typical implementation involves a retrieval step, this freshness check step, and then a final grounded summarization step that only sees the articles that passed the check. This separation of concerns makes the system easier to debug and evaluate than a single monolithic prompt that tries to do everything at once.

Do not use this prompt as a general relevance scorer or a full RAG answer generator. It assumes that the articles are already topically relevant to the user's query or briefing topic; its only concern is temporal validity. It is also not a replacement for a robust publication date extraction pipeline. The prompt's accuracy is entirely dependent on the quality of the [PUBLICATION_DATE] field you provide for each article. If your upstream extraction logic fails to parse dates correctly or normalizes them to the wrong timezone, this prompt will confidently make the wrong decision. For high-stakes domains, always route articles flagged as 'stale' to a human review queue instead of silently dropping them, and log the prompt's [STALENESS_REASON] output to monitor for systemic extraction errors.

This template is designed to be pasted directly into your orchestration layer. It instructs the model to act as a strict temporal auditor, comparing the publication date and content of each provided article against the current target date and the query's time-sensitivity requirements. The prompt forces a structured output, making it suitable for automated pipelines where a downstream system needs to decide whether to use, flag, or discard a source based on its recency.

codeCopy
You are a strict temporal relevance auditor for a news summarization system. Your task is to evaluate a set of retrieved news articles and determine if they are fresh enough for a [QUERY_TYPE] use case, such as 'breaking-news' or 'daily-briefing'.

**Input Data:**
- Target Date and Time: [TARGET_DATETIME]
- Query Type: [QUERY_TYPE]
- Maximum Acceptable Article Age: [MAX_AGE_HOURS] hours
- Articles to Evaluate: [ARTICLES_JSON]
  (Each article object must contain 'id', 'title', 'publication_date' in ISO 8601 format, and 'content'.)

**Evaluation Steps:**
1. For each article, calculate the time difference between [TARGET_DATETIME] and its 'publication_date'.
2. Compare this difference against the [MAX_AGE_HOURS] threshold.
3. Analyze the article's content for any time-sensitive statements (e.g., 'yesterday', 'last week', 'earlier today') that may indicate the information is older than the publication date suggests.
4. Classify each article into one of three categories: 'FRESH', 'STALE', or 'BORDERLINE'.
   - 'FRESH': Publication date is within the threshold, and content appears current.
   - 'STALE': Publication date exceeds the threshold, or content contains clearly outdated temporal references.
   - 'BORDERLINE': Publication date is within the threshold, but content contains ambiguous or potentially outdated temporal references.

**Output Schema:**
You must return a single JSON object with the following structure:
{
  "query_type": "[QUERY_TYPE]",
  "target_datetime": "[TARGET_DATETIME]",
  "max_age_hours": [MAX_AGE_HOURS],
  "articles": [
    {
      "id": "string",
      "freshness_status": "FRESH" | "STALE" | "BORDERLINE",
      "time_difference_hours": number,
      "rationale": "A concise, evidence-based explanation for the classification, citing specific temporal references from the article's content or the publication date."
    }
  ],
  "overall_freshness_summary": "A brief summary of the retrieval set's freshness, noting the proportion of fresh vs. stale articles and any critical risks for the [QUERY_TYPE] use case."
}

**Constraints:**
- Do not summarize the articles. Only evaluate their temporal freshness.
- If an article's 'publication_date' is missing or unparseable, classify it as 'STALE' and state the reason clearly in the rationale.
- If the [QUERY_TYPE] is 'breaking-news', apply a stricter interpretation of 'BORDERLINE', leaning towards 'STALE' when in doubt.

To adapt this template, replace the square-bracket placeholders with live data from your system. The [ARTICLES_JSON] input should be a serialized JSON array of article objects from your retrieval step. The [MAX_AGE_HOURS] parameter should be configured per use case; for a breaking-news system, this might be 4 hours, while a daily briefing could use 24 hours. Before deploying, test the prompt with a golden dataset of articles with known publication dates and intentional staleness to ensure the model's classifications and rationales align with your operational definitions of 'FRESH' and 'STALE'.

For high-stakes applications where a stale article could cause reputational harm, do not rely solely on this prompt. Implement a post-processing validation step in your application code that independently calculates the time difference using the article's metadata and flags any output where the model's time_difference_hours field deviates from your own calculation by more than a small tolerance. This acts as a safety net against model arithmetic errors.

The News Summarization Freshness Check Prompt is designed to operate as a pre-generation gate in a news summarization pipeline. Before any summary is produced, retrieved articles pass through this freshness evaluation step. The prompt expects a batch of articles with their publication dates and a query specifying the temporal requirements (e.g., 'breaking news, last 4 hours' or 'daily briefing, last 24 hours'). The output is a structured freshness assessment that downstream components can act on: fresh articles proceed to summarization, stale articles are flagged for replacement or exclusion, and borderline cases can be routed for human review. This separation of freshness checking from summary generation prevents the summarizer from synthesizing outdated information into what appears to be a current briefing.

Integration pattern: Wire this prompt as a synchronous validation step between retrieval and summarization. The retrieval layer fetches candidate articles with their metadata (publication timestamps, source identifiers). Before passing articles to the summarization prompt, call the freshness check prompt with the full candidate set and the temporal requirements. Parse the structured output—which should include a freshness_status per article, an overall recency_score, and a stale_article_flags list—and use it to filter the article set. Only articles marked fresh or acceptable proceed to summarization. Validation layer: Implement a post-processing validator that checks: (1) every article in the input received a freshness classification, (2) no article with a publication date outside the required window was marked fresh, and (3) the overall recency score is above your configured threshold (e.g., 0.7). If validation fails, log the mismatch and either retry with adjusted temporal parameters or escalate to a human editor. For retry logic, if the model returns an unparseable freshness assessment, retry once with the same input plus an explicit instruction to return valid JSON matching the expected schema. If the second attempt fails, route the entire batch to a human review queue rather than proceeding with unvalidated articles.

Model choice and latency considerations: For breaking-news use cases where latency matters, use a fast model (e.g., GPT-4o-mini, Claude Haiku) for the freshness check and reserve a more capable model for the final summarization of verified-fresh articles. The freshness check is a classification and flagging task that does not require deep reasoning—smaller models perform well here when the schema is clear. Logging and observability: Log every freshness check invocation with: the query's temporal requirements, the number of articles evaluated, the count of articles flagged stale, the overall recency score, and whether the batch passed the freshness gate. This creates an audit trail for debugging stale-content incidents. When a stale article reaches users despite the gate, you can trace whether the freshness check misclassified it, whether the publication date was extracted incorrectly upstream, or whether the temporal requirements were too permissive. Human review integration: For high-stakes briefings (financial summaries, crisis updates), configure the harness to route any batch where more than 20% of articles are flagged stale or where the overall recency score falls below 0.8 to a human editor. The editor receives the flagged articles, the freshness justifications, and can override classifications or trigger re-retrieval before summarization proceeds.