Temporal Grounding Statement Generation Prompt

This prompt is designed for a single, verifiable job: generating a concise statement that anchors an AI-generated answer to the time period of its source evidence. The ideal user is a system builder integrating this step into an answer generation pipeline, specifically after answer synthesis and before the final response is delivered to the user. The required context is a set of evidence passages that have already been vetted for relevance and freshness, each with an associated publication or effective date. The output is a short, transparent prefix like 'Based on Q3 2024 earnings data...' or 'As reported in the last 24 hours...' that can be prepended to the answer or displayed as a metadata tag, giving the end user immediate insight into the recency of the information.

You should use this prompt when your application needs to make the temporal context of an answer explicit and auditable. This is critical in fast-moving domains like financial intelligence, news summarization, or market analysis, where an answer based on stale data is functionally incorrect. The prompt assumes that a temporal relevance scoring or stale evidence detection step has already occurred; it does not decide if the evidence is fresh enough, only how to communicate its time period. Do not use this prompt as a substitute for those upstream checks. If your evidence set contains conflicting publication dates or lacks date metadata entirely, you must resolve those issues before invoking this prompt, as it will faithfully ground the answer to whatever dates it is given, potentially amplifying a data quality problem.

Before wiring this into production, define the exact format of the grounding statement your UI or API requires. A simple 'As of [date]...' might be sufficient for a dashboard, while a legal or compliance workflow may need a more formal 'This answer is based solely on evidence published between [start_date] and [end_date].' The next step is to pair this prompt with an evaluation that checks for temporal grounding faithfulness: does the generated statement accurately reflect the dates in the provided evidence? A common failure mode is the model summarizing a date range as a single point in time, which can be misleading. Plan to log both the generated statement and the source evidence dates for auditability.

This prompt template is designed to be copied directly into your prompt management system or codebase. It instructs the model to produce a concise, accurate temporal grounding statement—such as 'Based on Q3 2024 data...' or 'As reported in the last 24 hours...'—by comparing the provided evidence dates against a reference date. The template uses square-bracket placeholders for all dynamic inputs, making it straightforward to wire into a retrieval-augmented generation (RAG) pipeline or a post-generation verification harness. Before using it in production, ensure that your upstream retrieval system provides the required date fields for each evidence passage; missing or malformed dates are the most common cause of incorrect grounding statements.

textCopy
You are a temporal grounding specialist. Your task is to generate a single, concise statement that connects an answer to the time period of its supporting evidence.

## INPUTS
- Answer: [ANSWER_TEXT]
- Evidence passages with dates:
[EVIDENCE_LIST]
- Current reference date: [CURRENT_DATE]

## CONSTRAINTS
- Produce exactly one sentence.
- Use the evidence dates and the current reference date to ground the statement.
- If evidence dates are missing, ambiguous, or conflicting, state the uncertainty explicitly (e.g., 'Based on data from an unspecified date...').
- Do not fabricate dates or assume recency not present in the evidence.
- Prefer specific time periods over vague terms like 'recently' unless the evidence itself uses only vague language.
- If all evidence is older than [STALENESS_THRESHOLD_DAYS] days relative to the current reference date, include a staleness qualifier (e.g., 'Based on data from over 90 days ago...').

## OUTPUT FORMAT
Return a JSON object with the following schema:
{
  "temporal_grounding_statement": "string",
  "evidence_dates_used": ["ISO8601_date_string"],
  "confidence": "high|medium|low",
  "uncertainty_note": "string or null"
}

## EXAMPLES
Example 1:
Input: Answer='Revenue grew 12%', Evidence=[{date:'2024-09-30', text:'Q3 earnings report...'}], Current='2024-11-15'
Output: {"temporal_grounding_statement": "Based on Q3 2024 data as of September 30, 2024", "evidence_dates_used": ["2024-09-30"], "confidence": "high", "uncertainty_note": null}

Example 2:
Input: Answer='System status is operational', Evidence=[{date:'2024-11-15T08:00:00Z', text:'Latest health check...'}], Current='2024-11-15T10:00:00Z'
Output: {"temporal_grounding_statement": "As reported in the last 2 hours", "evidence_dates_used": ["2024-11-15T08:00:00Z"], "confidence": "high", "uncertainty_note": null}

Example 3:
Input: Answer='Market conditions are favorable', Evidence=[{date:null, text:'Analyst commentary without date...'}], Current='2024-11-15'
Output: {"temporal_grounding_statement": "Based on data from an unspecified date", "evidence_dates_used": [], "confidence": "low", "uncertainty_note": "Evidence date is missing; temporal grounding cannot be verified."}

To adapt this template for your application, start by mapping your retrieval pipeline's output into the [EVIDENCE_LIST] placeholder. Each evidence object must include a date field in ISO 8601 format and a text field with the passage content. If your retrieval system does not return dates, you will need an upstream extraction step—consider pairing this prompt with a Publication Date Extraction Prompt for unstructured documents. The [STALENESS_THRESHOLD_DAYS] parameter should be set based on your domain's freshness requirements: 1 day for breaking news, 90 days for quarterly financial data, or 365 days for annual reports. For high-risk domains such as healthcare or finance, always route outputs with confidence: "low" or non-null uncertainty_note fields to human review before displaying them to users. The JSON output schema is designed to be machine-readable so that your application can programmatically decide whether to show the grounding statement, flag it for review, or suppress it entirely.

This prompt is designed to be called after answer generation and evidence retrieval, not as a standalone step. The typical integration point is a post-processing stage in a RAG pipeline: the system has already produced a candidate answer and has a set of retrieved passages with known publication dates. The Temporal Grounding Statement Generation Prompt takes the answer, the evidence metadata, and the user query, and produces a grounding statement that explicitly connects the answer to the temporal scope of its supporting sources. This statement can be prepended to the final answer, stored as a separate metadata field, or used downstream for audit and compliance checks.

Validation is mandatory before the grounding statement reaches users. Implement a post-generation check that verifies: (1) the grounding statement references at least one actual source from the evidence set by title or identifier, (2) any date mentioned in the grounding statement matches a publication date in the evidence metadata, and (3) the statement does not claim recency (e.g., 'as of today') unless the evidence timestamp is within a configurable freshness window. A simple regex or JSON schema validator can catch format errors, but semantic checks require a second LLM call or a structured comparison against the evidence metadata. If validation fails, retry once with the validation error message appended to the prompt as additional [CONSTRAINTS]. After two failures, fall back to a generic statement like 'Based on available sources' and log the incident for review.

Model choice matters for temporal precision. This prompt requires the model to compare dates, reason about recency, and avoid fabricating temporal claims. Use a model with strong instruction-following and low hallucination rates on structured metadata tasks. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are suitable. Avoid smaller or older models that tend to paraphrase dates incorrectly or invent freshness claims. Set temperature to 0 or a very low value (0.1 maximum) to reduce variability in date handling. If your evidence metadata includes timestamps in multiple formats, normalize them to ISO 8601 before passing them into the [EVIDENCE_METADATA] placeholder to reduce parsing errors.

Log every grounding statement alongside its inputs for audit and debugging. Store the user query, the candidate answer, the evidence metadata (with source IDs and timestamps), the generated grounding statement, and the validation result. This log becomes essential when users challenge the temporal accuracy of an answer or when you need to debug why a grounding statement claimed recency on stale data. For high-risk domains like financial reporting or medical information, route grounding statements that fail validation to a human review queue before the answer is surfaced. The review interface should show the candidate answer, the evidence timestamps, and the failed grounding statement side by side so reviewers can quickly decide whether to correct, override, or suppress the output.

Avoid wiring this prompt directly to user-facing output without validation. The most common production failure is a grounding statement that says 'Based on the latest data from Q3 2024' when the evidence is actually from Q1 2023. This erodes user trust faster than having no grounding statement at all. Always run the validation checks described above, and consider adding an eval dataset of 50-100 examples with known temporal ground-truth to measure grounding accuracy before deployment. If your system uses streaming responses, generate the grounding statement first, validate it, and only then stream the full answer with the grounding statement prepended.