Temporal Claim Extraction and Normalization Prompt

This prompt is built for verification pipeline engineers who need to extract time-sensitive factual assertions from unstructured text and normalize them to a consistent, machine-readable date format. The core job-to-be-done is converting messy temporal language—explicit dates, relative durations, and sequence relationships—into absolute, sortable timestamps anchored to a known reference point. Use this when downstream fact-checking accuracy depends on precise date anchoring, such as verifying 'launched last quarter' against a financial filing or confirming 'three days before the announcement' in an investigative timeline. The ideal user is integrating this prompt into an automated claim extraction stage where temporal precision is the primary verification risk, not a general entity extraction workflow.

This prompt is not a general-purpose claim extractor. Do not use it when temporal accuracy is secondary to the verification task, or when the source text lacks a clear reference date for normalization. It is also unsuitable for extracting non-temporal claims, opinions, or predictions unless they contain a date-bound assertion that requires normalization. The prompt requires a [REFERENCE_DATE] input to convert relative expressions; without it, relative durations like 'next month' or 'two weeks ago' will remain unresolved and produce low-confidence outputs. If your pipeline handles documents without a known publication or event date, you must either infer a reference date upstream or route those inputs to a different extraction prompt.

Before wiring this into production, confirm that your verification architecture can supply a reliable [REFERENCE_DATE] for each document or segment. If your system cannot anchor relative time expressions to an absolute date, the prompt's core value is lost. Also, avoid using this prompt in isolation for high-stakes verification without a human review step for normalized outputs that fall below a confidence threshold. The next section provides the copy-ready template, followed by implementation guidance on validation, retries, and eval checks to catch relative-to-absolute conversion errors before they propagate downstream.

This prompt template is designed to be the core instruction set for a temporal claim extraction module in a verification pipeline. It instructs the model to identify assertions that are anchored in time—specific dates, durations, or relative sequences—and to normalize them to the ISO 8601 standard. The primary goal is to transform vague language like 'last quarter' or 'recently' into concrete, queryable date ranges, which is a prerequisite for automated evidence matching against dated sources. Use this template as a starting point; you will need to populate the placeholders with your specific source text, the desired output structure, and any domain-specific constraints before integration.

codeCopy
You are an expert temporal reasoning engine. Your task is to extract all factual claims that contain a temporal element from the provided [INPUT_TEXT]. For each extracted claim, you must normalize its temporal expression to a precise date or date range in ISO 8601 format (YYYY-MM-DD).

Follow these rules strictly:
1.  **Identify Temporal Claims:** Extract only claims that include a date, duration, or a relative time reference (e.g., 'last month', 'Q3 2023', 'two weeks ago', 'by next year'). Do not extract atemporal facts.
2.  **Preserve Original Text:** For each claim, output the exact original sentence or clause from [INPUT_TEXT] in the `original_text` field.
3.  **Normalize to ISO 8601:** Convert every temporal expression into an absolute `start_date` and `end_date`. Use the reference date [REFERENCE_DATE] to resolve relative expressions. If a claim refers to a single date, `start_date` and `end_date` should be the same. If a duration is open-ended (e.g., 'since May'), use a null-like placeholder like "9999-12-31" for the `end_date` and note this in `normalization_note`.
4.  **Handle Vagueness:** If a temporal expression is inherently vague and cannot be normalized to a precise date (e.g., 'in the coming months', 'a long time ago'), still extract the claim but set both `start_date` and `end_date` to null. You must provide a `normalization_note` explaining the ambiguity and, if possible, a reasonable estimated range based on context.
5.  **Output Format:** Return your findings as a single, valid JSON object with a key `temporal_claims` containing an array of objects. Each object must conform to the following [OUTPUT_SCHEMA].

[OUTPUT_SCHEMA]
{
  "temporal_claims": [
    {
      "claim_id": "string",
      "original_text": "string",
      "claim_subject": "string",
      "claim_predicate": "string",
      "start_date": "date or null",
      "end_date": "date or null",
      "normalization_note": "string"
    }
  ]
}

[INPUT_TEXT]:
{{user_input}}

[REFERENCE_DATE]:
{{reference_date}}

To adapt this template for production, you must first harden the [OUTPUT_SCHEMA] to match your downstream ingestion contract. For instance, you might add fields for confidence_score or source_span character offsets. The [REFERENCE_DATE] placeholder is critical; in an automated pipeline, this should be injected programmatically, often defaulting to the document's publication date or the current processing timestamp. For high-stakes verification, always include a normalization_note field, as shown, to make the model's reasoning auditable. This allows a human reviewer or a secondary evaluator LLM to quickly spot-check conversions of relative dates, which are the most common failure point.

The temporal claim extraction prompt is designed to be the first stage in a time-sensitive fact-checking pipeline. It should be called immediately after document ingestion, before evidence matching or contradiction detection. The prompt expects raw text input and returns structured temporal claims with normalized dates. In production, you will wrap this prompt in an application harness that validates output schema, retries on malformed responses, logs extraction provenance, and routes low-confidence extractions for human review.

Start by implementing a strict output validator. The prompt returns JSON with a claims array where each claim object must include claim_id, original_text, normalized_claim, temporal_expressions, normalized_dates, temporal_relationships, and extraction_confidence. Your validator should check that every normalized_date conforms to ISO 8601 (YYYY-MM-DD format), that temporal_relationships only contains values from the allowed enum (before, after, during, overlaps, equals, unspecified), and that no claim object is missing required fields. If validation fails, implement a single retry with the error message appended to the prompt as a [CORRECTION_INSTRUCTION]. After two consecutive failures, log the raw output and route to a human review queue rather than silently dropping the claim. For model selection, prefer models with strong date parsing and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or fine-tuned variants). Set temperature=0 to minimize date hallucination and format drift.

The most common production failure mode is relative-to-absolute date conversion errors, particularly with expressions like 'last quarter,' 'next fiscal year,' or 'three weeks ago' when the reference date is ambiguous. Mitigate this by always passing an explicit [REFERENCE_DATE] parameter in your prompt context, defaulting to the document publication date or ingestion timestamp. Log every relative-to-absolute conversion alongside the reference date used so you can audit conversion accuracy later. For high-stakes domains (financial filings, clinical trial timelines, legal documents), require human review on any claim where extraction_confidence is below 0.85 or where the temporal relationship is unspecified. Wire these claims into a review queue with the original source text, the extracted claim, and the normalized dates displayed side by side. Do not auto-verify temporal claims without human confirmation when the source contains vague or conflicting date references.