Historical vs. Current Evidence Labeling Prompt

This prompt is designed for RAG system engineers and evidence organization pipeline builders who need to impose temporal order on a mixed retrieval set before answer generation. The core job-to-be-done is classification: given a passage and a user query, label the passage as historical_context, current_state, or forward_looking_projection. This separation prevents a downstream answer generator from treating a 2019 market report as the current state of an industry or from presenting a speculative analyst forecast as an established fact. The ideal user is integrating this prompt as a filtering or metadata-tagging step between retrieval and synthesis, where the temporal label becomes a structured field that the answer-generation prompt can use to decide what to cite and how to frame it.

Use this prompt when your retrieval pipeline pulls from sources with wide date ranges—corporate filings spanning a decade, academic papers mixed with breaking news, or product documentation that includes both deprecated and current versions. The prompt works best when the retrieval set is already reasonably relevant to the query and the primary problem is temporal confusion, not topical irrelevance. It is not a replacement for date filtering at the retrieval stage; if you can filter by publication date before retrieval, do that first and use this prompt to handle the remaining ambiguity. Do not use this prompt for real-time streaming data freshness checks or for assigning numerical recency scores. For those tasks, pair it with the Temporal Relevance Scoring Prompt or the Stale Evidence Detection Prompt, which produce calibrated scores and staleness flags rather than categorical labels.

Before deploying, define what current_state means for your domain. In financial intelligence, 'current' might mean the most recent fiscal quarter. In medical literature, it might mean the last two years. In software documentation, it might mean the latest major release. Document these boundaries and include them in the [CONSTRAINTS] placeholder so the model applies consistent criteria. Also plan for the forward_looking_projection label: this category covers analyst forecasts, strategic outlooks, roadmap items, and any statement about what might happen. Downstream answer generators should treat these as speculative, not factual. If your application cannot tolerate speculation being presented as fact, add a post-classification rule that strips or quarantines forward_looking_projection passages before they reach the answer generator. Finally, run this prompt against a human-annotated corpus before production. Labeling accuracy degrades when passages contain mixed temporal signals—a document that summarizes historical context before stating current facts, for example. Your eval set should include these ambiguous cases so you can measure whether the prompt's precision meets your application's tolerance for temporal misclassification.

This template provides a complete, copy-ready prompt for the Historical vs. Current Evidence Labeling task. It is designed to be dropped into a RAG pipeline immediately after retrieval and before answer generation. The prompt instructs the model to classify each passage into one of three temporal categories—historical_context, current_state, or forward_looking_projection—using strict definitions. The output is a valid JSON object that can be parsed by downstream systems to filter, prioritize, or annotate evidence before synthesis. Use this prompt when your application needs to distinguish background information from actionable current data, such as in financial intelligence, news summarization, or regulatory monitoring systems.

textCopy
You are an evidence classification system. Your task is to classify each retrieved passage by its temporal relationship to the user's query. Use only the labels defined below. Return only valid JSON matching the output schema.

## Labels
- `historical_context`: The passage describes events, states, or data that are definitively in the past relative to the query's temporal frame. This includes background information, prior periods, and completed events.
- `current_state`: The passage describes the present condition, most recent available data, or ongoing situation that is current as of the query's implied timeframe. This is the actionable present.
- `forward_looking_projection`: The passage contains predictions, forecasts, plans, guidance, or expectations about future states or events.

## Input
**Query:** [QUERY]
**Query Date Context:** [QUERY_DATE]
**Passages:** [PASSAGES]

## Output Schema
Return a JSON object with a single key `classifications` that maps to an array of objects. Each object must have:
- `passage_id` (string): The identifier of the passage from the input.
- `label` (string): One of `historical_context`, `current_state`, or `forward_looking_projection`.
- `rationale` (string): A one-sentence explanation referencing specific temporal signals in the passage and query.

## Constraints
- Classify every passage. Do not skip any.
- If a passage contains mixed temporal signals, choose the dominant temporal relationship.
- Do not add labels beyond the three defined.
- If the query date context is ambiguous, assume the current date is [DEFAULT_DATE].
- Return only the JSON object. No markdown fences, no commentary.

To adapt this template, replace the square-bracket placeholders with your application's runtime values. [QUERY] should contain the user's original question or search string. [QUERY_DATE] provides temporal context—this could be the current date, the date the query was submitted, or a specific reporting period. [PASSAGES] must be a structured list of passage objects, each with an id and text field. The [DEFAULT_DATE] placeholder acts as a fallback when the query's temporal frame is unclear; set this to your system's reference date. For high-stakes domains like financial reporting or clinical data, add a [RISK_LEVEL] parameter that triggers additional validation or human review when set to high. Wire the output into a post-processing step that validates the JSON schema, checks that all passage IDs are accounted for, and routes forward_looking_projection passages to a separate disclaimer or confidence-adjustment module before they reach the answer generation stage.

This prompt is designed to operate as a post-retrieval, pre-generation classification step in a RAG pipeline. After your retriever returns a set of passages but before those passages are fed to an answer-generation model, each passage should be independently labeled as historical_context, current_state, or forward_looking_projection. The prompt expects a single passage as [PASSAGE] and an optional [QUERY] for temporal intent alignment. In production, you will typically call this prompt in a fan-out pattern: one call per retrieved passage, executed concurrently. The resulting labels are then attached as metadata to each passage, enabling downstream components—such as a recency-aware reranker or a time-sensitive answer generator—to make informed decisions about which evidence to prioritize or exclude.

Wire this prompt into your application with a thin service wrapper that handles concurrency, retries, and output validation. For each passage, construct the prompt by injecting the passage text into the [PASSAGE] placeholder and the user's original query into [QUERY]. Use a structured output API (e.g., OpenAI's response_format with a JSON schema or function-calling mode) to enforce the expected output shape: {"label": "historical_context|current_state|forward_looking_projection", "confidence": 0.0-1.0, "rationale": "string"}. Validate every response before accepting it: check that label is one of the three allowed enum values, that confidence is a float between 0 and 1, and that rationale is a non-empty string. If validation fails, retry once with the same passage and a stronger instruction to adhere to the output schema. If the retry also fails, log the passage and the malformed response, and default the label to current_state with a confidence of 0.0 and a rationale indicating a parsing failure. This fallback prevents a single bad output from blocking the entire pipeline.

Model choice matters for this task. The labeling logic requires nuanced temporal reasoning—distinguishing a historical summary from a current description of the same entity, or identifying forward-looking language in earnings guidance or product roadmaps. Use a capable instruction-following model (e.g., GPT-4o, Claude 3.5 Sonnet, or a fine-tuned open-weight model on temporal classification data). For high-throughput pipelines, consider batching multiple passages into a single call with a list-structured output schema to reduce API overhead, but be aware that batch size affects label quality when passages are long or complex. Implement structured logging that captures the passage ID, the assigned label, confidence, rationale, model version, and latency for every call. This log becomes your primary debugging tool when downstream answer quality degrades due to mislabeled evidence.

For high-risk domains—financial reporting, medical guidelines, legal analysis—add a human review gate for low-confidence labels. If the model returns a confidence score below your threshold (start with 0.7 and calibrate based on your eval results), route that passage to a review queue rather than automatically accepting the label. The review interface should display the passage, the query, the model's label and rationale, and allow a human to confirm or override the classification. Over time, collect these human corrections and use them to fine-tune your temporal classification model or to adjust your confidence threshold. Do not skip this gate in regulated workflows where mislabeling a stale financial figure as current_state or a speculative projection as current_state could cause material harm.

Before deploying, build an evaluation harness against a human-annotated corpus of passages with known temporal labels. For each passage in your test set, run the prompt and compare the model's label to the ground-truth annotation. Measure precision, recall, and F1 per label class—forward_looking_projection is often the hardest class and deserves focused error analysis. Also measure calibration: the model's confidence scores should correlate with actual accuracy. If the model is overconfident on errors, you have a calibration problem that will undermine your human review threshold. Run this eval on every prompt or model version change before releasing to production. A regression test suite of 200-500 labeled passages across your domains is a reasonable starting investment for a production system.