Date-Anchored Claim Verification Prompt

This prompt is a precision instrument for fact-checking and claims verification pipeline builders who need to verify whether a claim with an explicit or implied date is supported by evidence from the correct time period. The core job-to-be-done is temporal alignment: matching a claim's temporal scope to the publication or effective date of supporting evidence. For example, verifying 'Company X reported $2B in revenue in Q3 2024' requires evidence from Q3 2024, not Q2 2024 or Q1 2025. The ideal user is an engineer or AI architect integrating this prompt into a post-retrieval verification step, after evidence has been gathered but before a final answer is delivered to the user. The prompt produces verification results with temporal alignment scores, source date comparisons, and explicit grounding statements that connect claims to their time-bound evidence.

This prompt belongs in a specific architectural position: after retrieval and evidence selection, but before answer generation or user-facing output. It assumes the upstream system has already gathered candidate evidence passages with date metadata. Without date metadata on retrieved passages, this prompt cannot function. The verification logic depends on comparing the claim's temporal anchor (explicit dates like 'Q3 2024' or implied recency like 'latest earnings') against the evidence's publication, last-updated, or effective dates. The prompt expects structured inputs including the claim text, a temporal anchor specification, and an evidence set with per-passage date fields. It returns a structured verification result with an alignment score, a temporal match/mismatch classification, and a human-readable justification suitable for audit trails.

Do not use this prompt for claims without any temporal dimension, or when the evidence set has no date metadata available. It is not a general fact-checking prompt for atemporal claims like 'water boils at 100 degrees Celsius.' It is also not a replacement for retrieval query rewriting or temporal context window selection—those are upstream concerns. If your evidence retrieval pipeline cannot attach publication dates to passages, invest in a Publication Date Extraction Prompt first. For high-risk domains such as financial reporting, clinical claims, or regulatory filings, always route verification failures to human review rather than suppressing them. The temporal alignment score is a signal for downstream decision-making, not a final arbiter of truth. Use it to flag claims that need human investigation, to suppress answers with temporally misaligned evidence, or to trigger re-retrieval with tighter date constraints.

This section provides the core prompt template for the Date-Anchored Claim Verification workflow. The template is designed to be copied directly into your prompt assembly pipeline, with square-bracket placeholders that your application layer must populate before sending the request to the model. The prompt instructs the model to extract the claim's temporal anchor, compare it against source publication dates, assess temporal alignment, and produce a structured verification result. It is built for claims that contain explicit or implied date references—such as 'Q3 revenue grew 12%' or 'the CEO stated last week that...'—where evidence from the wrong time period would produce a factually incorrect verification.

textCopy
You are a date-anchored claim verification system. Your task is to verify whether a claim with an explicit or implied date is supported by evidence from the correct time period.

## INPUT

**Claim:** [CLAIM]

**Retrieved Evidence Passages:**
[EVIDENCE_PASSAGES]

**Current Reference Date:** [REFERENCE_DATE]

## INSTRUCTIONS

1. **Extract the claim's temporal anchor.** Identify any explicit dates, relative time references (e.g., 'last quarter', 'earlier this year'), or implied temporal scopes in the claim. Normalize all extracted anchors to ISO 8601 dates or date ranges.

2. **Extract publication dates from evidence.** For each evidence passage, identify its publication date, last-updated date, or effective date. If a passage lacks a clear date, note it as 'UNDATED' and assign it a lower temporal confidence.

3. **Assess temporal alignment.** Compare the claim's temporal anchor against each evidence passage's date. Classify alignment as:
   - **ALIGNED:** Evidence date falls within the claim's temporal scope.
   - **MISALIGNED:** Evidence date falls outside the claim's temporal scope.
   - **INDETERMINATE:** Evidence date is missing or ambiguous.

4. **Verify the claim.** Determine whether the temporally-aligned evidence supports, contradicts, or is insufficient to verify the claim. Only use evidence classified as ALIGNED for support assessment. If no evidence is ALIGNED, the claim cannot be verified.

5. **Produce the output.** Follow the output schema exactly.

## OUTPUT SCHEMA

```json
{
  "claim": "[original claim text]",
  "extracted_temporal_anchor": {
    "anchor_type": "explicit_date | relative_date | implied_period | none",
    "normalized_date_range": {
      "start": "ISO 8601 date or null",
      "end": "ISO 8601 date or null"
    },
    "extraction_confidence": 0.0_to_1.0,
    "anchor_phrase": "[the specific phrase from which the anchor was extracted]"
  },
  "evidence_assessments": [
    {
      "passage_id": "[identifier from input]",
      "passage_date": "ISO 8601 date or null",
      "date_extraction_confidence": 0.0_to_1.0,
      "temporal_alignment": "ALIGNED | MISALIGNED | INDETERMINATE",
      "alignment_explanation": "[brief explanation of why this classification applies]"
    }
  ],
  "verification_result": {
    "verdict": "SUPPORTED | CONTRADICTED | INSUFFICIENT_EVIDENCE | TEMPORALLY_UNVERIFIABLE",
    "verdict_explanation": "[explanation grounded in temporally-aligned evidence only]",
    "supporting_passage_ids": ["list of passage_ids that support the verdict"],
    "contradicting_passage_ids": ["list of passage_ids that contradict"],
    "temporal_alignment_score": 0.0_to_1.0,
    "confidence": 0.0_to_1.0
  },
  "caveats": ["[any limitations, missing date warnings, or uncertainty notes]"]
}

CONSTRAINTS

[CONSTRAINTS]

EXAMPLES

[EXAMPLES]

Adaptation guidance: Replace [CLAIM] with the claim text to verify, [EVIDENCE_PASSAGES] with retrieved passages including their identifiers and full text, and [REFERENCE_DATE] with the current date in ISO 8601 format. The [CONSTRAINTS] placeholder should be populated with domain-specific rules—for example, financial claims might require evidence from the exact fiscal quarter, while news claims might accept evidence within a 24-hour window. The [EXAMPLES] placeholder should contain one or two few-shot examples showing correct temporal anchor extraction and alignment classification for your domain. If your application handles high-stakes verification (financial reporting, regulatory compliance, clinical claims), add a constraint requiring the model to flag any claim where temporal alignment is INDETERMINATE for human review rather than producing a low-confidence verdict.

What to do next: After copying this template, build the application harness that populates placeholders, validates the JSON output against the schema, and routes INDETERMINATE or TEMPORALLY_UNVERIFIABLE results to a human review queue. Do not deploy this prompt without eval tests that measure temporal anchor extraction accuracy and alignment classification against a labeled dataset of claims with known publication dates. The most common production failure is the model extracting the wrong temporal anchor from an ambiguous claim—test this edge case thoroughly before shipping.

The Date-Anchored Claim Verification Prompt is designed to operate as a single step within a larger fact-checking or claims verification pipeline. It expects a claim with an explicit or implied date, a set of evidence passages with known publication dates, and an optional output schema. The prompt returns a structured verification result that includes a temporal alignment score, source date comparisons, and a justification. In production, this prompt should be called after evidence retrieval and date extraction have already occurred—it does not perform its own search or date parsing. The caller is responsible for providing clean, date-annotated evidence passages and a well-formed claim object.

Wiring the prompt into an application requires a thin orchestration layer that handles input assembly, model invocation, output validation, and escalation. Before calling the model, assemble the [CLAIM] object with claim_text, claimed_date (ISO 8601 or null if implied), and temporal_scope (e.g., 'exact date', 'month', 'year', 'implied recent'). Each evidence passage in [EVIDENCE] must include passage_text, publication_date (ISO 8601), and source_authority (a numeric score or categorical label). If your retrieval system cannot provide publication dates, insert a prior step using the Publication Date Extraction Prompt for Unstructured Documents before this verification step. For model choice, use a model with strong instruction-following and JSON output capabilities (e.g., GPT-4o, Claude 3.5 Sonnet) and set response_format to json_object with the expected schema provided in [OUTPUT_SCHEMA]. Set temperature to 0 or a very low value (0.0–0.1) to maximize consistency across repeated verification runs.

Validation and retry logic is critical because temporal verification errors can produce false confidence in outdated evidence. After receiving the model response, validate that: (1) the output is valid JSON matching the expected schema, (2) temporal_alignment_score is a float between 0 and 1, (3) source_date_comparisons contains an entry for every evidence passage provided, (4) verification_justification is non-empty and references specific dates, and (5) verification_status is one of the allowed enum values (supported, contradicted, temporally_misaligned, insufficient_evidence). If validation fails, retry once with the same prompt plus the validation error message appended as a [CONSTRAINTS] update. If the retry also fails, escalate to a human review queue with the original claim, evidence, and both failed responses attached. For high-stakes domains (finance, healthcare, legal), always route contradicted and temporally_misaligned results to human review before surfacing to end users.

Logging and observability should capture the full prompt, model response, validation results, and any retry or escalation events. Log the temporal_alignment_score as a metric so you can monitor drift over time—a sudden drop in average alignment scores may indicate a retrieval pipeline problem or a change in evidence freshness. Include the claim_id and evidence_set_id in all log entries to enable traceability back to specific verification requests. For eval and regression testing, maintain a golden dataset of claims with known temporal alignment outcomes and run this prompt against it on every prompt or model version change. The eval framework described in the topic's description provides specific test cases for claims with exact dates, implied recency, and ambiguous temporal references. Finally, avoid using this prompt for real-time streaming claims where evidence publication dates may be seconds old—the prompt assumes stable, dated evidence passages, not live feeds with sub-minute latency.