Cross-Format Temporal Claim Consistency Prompt

This prompt is designed for investigators, verification engineers, and compliance analysts who need to confirm that claims about event timing are consistent across a heterogeneous evidence set. The core job-to-be-done is reconciling temporal assertions—such as 'the transaction occurred at 3:00 PM'—when that claim might appear in a text log, a video frame timestamp, an audio timecode, and a metadata field, all of which may have different clock sources, precision, and timezone representations. The ideal user is building an automated fact-checking or audit pipeline and needs a structured, machine-readable output that flags inconsistencies and explains their likely cause, rather than a simple true/false verdict.

Use this prompt when you have a single, atomic temporal claim that must be verified against multiple source artifacts in different formats. The required inputs include the specific claim string, a set of evidence objects with their format type (e.g., text, video, audio, metadata), the raw timestamp value, and any known context about the clock source. Do not use this prompt for general fact-checking, non-temporal claims, or when all evidence is in a single format; a simpler text-to-text verification prompt is more efficient and less prone to format-specific hallucination in those cases. This prompt is also inappropriate for real-time streaming data where clock synchronization is a live operational problem rather than a post-hoc audit task.

The primary risk is a false positive where a legitimate clock drift or timezone normalization is flagged as a factual inconsistency, or a false negative where a genuine discrepancy is explained away by an over-eager model. To mitigate this, the prompt requires an explicit [UNCERTAINTY_TOLERANCE] parameter and demands that the output separate the raw offset from its explanation. Before deploying this prompt into a production pipeline, you must test it against a golden dataset that includes known timezone edge cases (e.g., a +14:00 offset), sub-second precision differences, and NTP-synchronized versus unsynchronized clock sources. Always route outputs with a severity of high or critical for human review before accepting the unified timeline as an audit record.

This prompt template is designed to be dropped into a verification pipeline that has already extracted claims and their associated timestamps from multiple source formats. The model receives a set of claims, each tagged with its format origin and temporal metadata, and is instructed to produce a unified timeline, flag inconsistencies, and explain potential clock-drift or timezone issues. The square-bracket placeholders allow you to inject the specific claims, evidence context, and output requirements for your use case.

textCopy
You are a temporal claim verification specialist. Your task is to analyze a set of claims about event timing that originate from different formats (text, audio transcripts, video frame metadata, file timestamps). Produce a unified, reconciled timeline and flag any inconsistencies.

## INPUT CLAIMS
[CLAIMS_JSON]
- Each claim object includes: claim_id, claim_text, source_format (text|audio|video|metadata), asserted_timestamp (ISO 8601 or relative), timezone (if known), and source_identifier.

## EVIDENCE CONTEXT
[EVIDENCE_CONTEXT]
- Additional metadata, clock references, or corroborating sources that can help resolve ambiguities.

## OUTPUT SCHEMA
Return a single JSON object with the following structure:
{
  "unified_timeline": [
    {
      "event_label": "string",
      "canonical_timestamp": "ISO 8601 in UTC",
      "supporting_claim_ids": ["string"],
      "confidence": "high|medium|low",
      "notes": "string"
    }
  ],
  "inconsistencies": [
    {
      "claim_ids": ["string"],
      "type": "direct_contradiction|timezone_mismatch|clock_drift|format_precision_mismatch|ordering_violation",
      "description": "string",
      "severity": "critical|high|medium|low",
      "resolution_suggestion": "string"
    }
  ],
  "clock_drift_explanations": [
    {
      "source_identifier": "string",
      "estimated_drift_seconds": number,
      "explanation": "string",
      "evidence": "string"
    }
  ],
  "unresolved_ambiguities": ["string"]
}

## CONSTRAINTS
- Normalize all timestamps to UTC. If a timezone is missing, flag it as an ambiguity rather than guessing.
- Account for format-specific timestamp precision: video frame times may be precise to milliseconds, while text descriptions may only specify a date.
- Distinguish between a true temporal contradiction and a precision mismatch.
- If clock drift is suspected, explain the pattern and estimate the drift magnitude.
- Do not invent timestamps or events to fill gaps. Mark missing information explicitly.
- If two claims are consistent within a reasonable tolerance for their format, treat them as supporting the same event.

## RISK_LEVEL
[HIGH] - Temporal inconsistencies in this domain can have significant downstream consequences. Flag all uncertainties.

To adapt this template, replace [CLAIMS_JSON] with your structured claim objects and [EVIDENCE_CONTEXT] with any additional metadata your pipeline can provide. The output schema is designed to be machine-readable for downstream routing: critical inconsistencies can trigger human review, while low-severity precision mismatches can be auto-resolved. Before deploying, test this prompt against a golden dataset that includes known timezone edge cases, clock-drift scenarios, and format-precision mismatches to calibrate the model's severity classification.

This prompt is designed to be a single step within a larger multimodal verification pipeline, not a standalone application. It expects pre-extracted claims with their format-specific timestamps already normalized into a common schema. The implementation harness must therefore handle upstream claim extraction, timestamp normalization, and format-specific precision metadata before this prompt is ever invoked. The prompt itself focuses on the cross-format temporal reasoning task: aligning events on a unified timeline, detecting inconsistencies, and explaining clock-drift or timezone discrepancies. It should not be responsible for OCR, transcription, or initial claim decomposition—those are separate upstream concerns with their own failure modes.

Input Contract: The prompt expects a structured input containing: (1) a list of claims, each with a claim ID, the claim text, the source format type (e.g., text, video_frame, audio_timecode, metadata_date, table_row), the original timestamp value, the normalized UTC timestamp, and the precision level (e.g., millisecond, second, minute, hour, day, month, year); (2) an optional reference timeline or event anchor for alignment; (3) a timezone context block specifying the primary timezone and any known clock-drift tolerances. Output Contract: The model must return a JSON object with a unified_timeline array of chronologically ordered events, an inconsistency_flags array containing conflict pairs with severity scores, and a drift_explanations array for any detected clock-skew or timezone-normalization issues. Each output field must include source claim IDs for traceability. Validate the output schema strictly before passing results downstream—reject malformed JSON, missing required fields, or claim IDs that don't reference the input set.

Validation and Retry Logic: After receiving the model response, run a schema validator that checks: (1) all claim_id references in the output exist in the input claim set; (2) the unified_timeline is sorted chronologically; (3) every inconsistency flag includes both conflicting claim IDs, a severity score between 0 and 1, and a human-readable explanation; (4) drift explanations include the affected claim IDs and the estimated drift magnitude. If validation fails, retry with the same prompt but append the validation error message as a [CORRECTION_FEEDBACK] block. Set a maximum of 2 retries before escalating to human review. For high-stakes verification (legal, compliance, investigative), always route outputs with severity >= 0.7 or any unresolved drift explanations to a human reviewer with the full claim-evidence context attached.

Model Choice and Tool Integration: This prompt benefits from models with strong temporal reasoning and structured output capabilities. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are suitable starting points. Avoid smaller or older models that struggle with timezone arithmetic or multi-step temporal alignment. If your pipeline uses tool-augmented models, provide a resolve_timezone tool that the model can call to look up IANA timezone offsets for specific timestamps rather than relying on internal knowledge. This reduces timezone-normalization errors. For RAG-augmented pipelines, retrieve any relevant timezone policy documents, daylight saving time change logs, or known system clock-drift records and include them in the prompt context as [TIMEZONE_POLICY_CONTEXT]. Log every invocation with the input claim set, the raw model output, validation results, retry count, and final disposition (auto-accepted, auto-rejected, or escalated). This audit trail is essential for debugging temporal reasoning failures and for compliance with verification governance requirements.

Production Failure Modes to Monitor: The most common failure is timezone normalization mismatch—when different upstream extractors apply different timezone assumptions to the same event. Mitigate this by enforcing a strict UTC-normalization step before this prompt is called. Another frequent failure is precision-level conflation: a claim with day-level precision (e.g., 'occurred on 2024-03-15') should not be flagged as inconsistent with a claim at millisecond precision (e.g., '2024-03-15T14:32:01.123Z') unless the day-level claim explicitly rules out that time. The prompt includes precision-awareness instructions, but monitor production outputs for false-positive inconsistency flags caused by precision mismatches. Finally, watch for hallucinated timeline events—the model may invent bridging events to resolve gaps. Validate that every event in the unified_timeline corresponds to at least one input claim ID. If you observe hallucination rates above 2%, consider adding a stricter output constraint or switching to a model with lower hallucination propensity for temporal tasks.