Temporal Inconsistency Detection Prompt for Event Timelines

This prompt is designed for verification engineers and analysts who need to validate chronological consistency across event timelines sourced from multiple documents. Use it when you have a set of dated events extracted from reports, news articles, legal filings, or intelligence briefs and you need to surface out-of-order sequences, impossible durations, date mismatches, and relative-to-absolute date conflicts. The primary job-to-be-done is post-extraction verification: taking a structured list of events that have already been pulled from source text and checking whether the implied timeline is logically coherent before the data is ingested into a knowledge base, timeline visualization, or investigative report.

The ideal user has already normalized events into a structured input format containing at minimum an event identifier, a date or date range, and a source reference. The prompt assumes events are pre-extracted and formatted—it does not perform extraction from raw text. Required context includes the full event list, any known timezone or calendar assumptions, and a clear definition of what constitutes a violation (e.g., an event dated after its own cause, a duration that contradicts stated bounds, or a relative date like 'three days later' that conflicts with absolute timestamps). The prompt works best when events share a common temporal frame of reference; mixing events from different calendar systems or timezones without normalization will produce unreliable results.

Do not use this prompt for real-time streaming event correlation, for validating events without date anchors, or as a substitute for source credibility assessment. It is not designed to detect factual errors in event descriptions—only temporal ordering and duration inconsistencies. Avoid using it when the event list contains intentionally non-linear narratives, flashbacks, or hypothetical scenarios unless those are explicitly tagged, as the prompt will flag them as violations. This prompt belongs in a verification pipeline after extraction and normalization but before ingestion into downstream systems. For high-stakes domains like legal proceedings or intelligence analysis, always pair the output with human review and source grounding checks.

This prompt template is designed to be pasted directly into your orchestration layer. It instructs the model to act as a temporal reasoning engine, comparing a set of provided events and their associated dates to identify out-of-order sequences, impossible durations, and date mismatches. The model is forced to normalize relative dates (e.g., 'last quarter') against absolute dates and explain any conflicts it finds, making the output auditable.

textCopy
You are a temporal reasoning engine. Your task is to analyze a list of events with their reported dates from one or more sources and produce a structured timeline conflict report.

### INPUT EVENTS
[EVENT_LIST]

### INSTRUCTIONS
1. Parse all events and their dates from the input.
2. Normalize all relative dates (e.g., 'next month', 'last year') into absolute dates based on the provided [REFERENCE_DATE] or the most frequent year mentioned.
3. Sort the events into a chronological sequence.
4. Identify and report the following temporal inconsistencies:
   - **Out-of-Sequence Events:** Events reported in an order that contradicts their dates.
   - **Impossible Durations:** An event's reported start and end dates that create a negative or zero duration, or a duration that conflicts with another source's report of the same event.
   - **Date Mismatches:** The same event reported with different dates across sources.
   - **Impossible Sequences:** An event that is reported to have occurred before an event it depends on.
5. For each inconsistency found, provide:
   - The conflicting event IDs or descriptions.
   - The specific dates in conflict.
   - A clear, one-sentence explanation of the conflict.
   - A severity score (Critical, High, Medium, Low) based on whether the conflict breaks the entire timeline's logic or is a minor discrepancy.

### CONSTRAINTS
- Do not invent events or dates not present in the input.
- If no reference date is provided, state your assumption for normalization.
- If the timeline is fully consistent, output a single confirmation message.
- Output ONLY the valid JSON object described in the output schema. Do not include any other text.

### OUTPUT SCHEMA
{
  "analysis_metadata": {
    "reference_date_used": "string",
    "total_events_analyzed": "integer",
    "inconsistencies_found": "integer"
  },
  "timeline_conflicts": [
    {
      "conflict_type": "Out-of-Sequence | Impossible Duration | Date Mismatch | Impossible Sequence",
      "event_ids_or_descriptions": ["string"],
      "conflicting_dates": ["string"],
      "explanation": "string",
      "severity": "Critical | High | Medium | Low"
    }
  ]
}

To adapt this prompt, replace the [EVENT_LIST] placeholder with your structured or semi-structured event data. For best results, each event should be a discrete object with an ID, a description, and at least one associated date. The [REFERENCE_DATE] is optional but strongly recommended for grounding relative time expressions. If your application layer already handles date parsing, you can remove the normalization instruction and provide pre-parsed ISO 8601 timestamps to reduce model error. After pasting, wire the output into a JSON validator to catch malformed responses before they enter your fact-checking pipeline.

This prompt is designed to operate as a stateless verification step within a larger fact-checking or document-audit pipeline. The typical integration pattern involves: (1) extracting dated event claims from one or more source documents, (2) normalizing those claims into a structured timeline with absolute dates where possible, (3) passing the normalized timeline and source metadata into this prompt, and (4) routing the resulting conflict report to either automated downstream actions or a human review queue based on severity scores. The prompt expects a pre-normalized timeline as input—do not rely on the model to perform date parsing, timezone conversion, or calendar normalization without pre-processing. Implement these transformations in application code before constructing the prompt payload to reduce hallucination risk and improve consistency across model versions.

Validation and output contracts. The prompt's output schema should be enforced at the application layer, not just described in the prompt. Define a strict JSON schema for the conflict report that includes required fields: conflict_id, event_pair (with event_a and event_b references), conflict_type (one of out_of_order, impossible_duration, date_mismatch, relative_absolute_conflict), severity (an enum: critical, high, medium, low), explanation, and resolution_suggestion. After receiving the model response, validate structural completeness before accepting the output. If validation fails, implement a retry loop with a maximum of two additional attempts, each time appending the validation error details to the prompt context so the model can self-correct. Log all validation failures for prompt debugging. For high-severity conflicts (critical or high), route the output to a human review queue with the full source context and normalized timeline attached. Low-severity conflicts can be auto-appended to an audit log without blocking downstream workflows.

Model selection and latency considerations. This prompt performs best with models that have strong reasoning capabilities for temporal logic and date arithmetic. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are suitable defaults. Avoid using smaller or faster models (e.g., GPT-3.5 Turbo, Claude Haiku) for production use unless you have calibrated their performance on your specific timeline complexity and are willing to accept higher false-positive rates on ambiguous date expressions. For batch processing of large document sets, implement a pre-filter that only invokes this prompt when the normalized timeline contains at least two dated events with overlapping or adjacent time ranges—single-event timelines or events separated by decades with no causal linkage do not require contradiction detection. Set a latency budget of 5-10 seconds per prompt call and implement a timeout with fallback behavior that flags the timeline as unverified rather than silently dropping the check.

Observability and continuous improvement. Log every prompt invocation with: the input timeline hash, the model version used, the output conflict count, validation pass/fail status, retry count, and human review outcome if escalated. Use these logs to build a dashboard tracking false-positive rates (conflicts flagged by the model but dismissed by human reviewers) and false-negative rates (conflicts missed by the model but caught later in the pipeline). Periodically sample 50-100 logged cases and run them through an LLM-as-judge eval using a contradiction detection eval rubric prompt to measure precision, recall, and explanation quality drift across model updates. When updating the prompt template, run a regression test suite against a golden dataset of known temporal conflicts and non-conflicts before promoting the change to production. The highest-risk failure mode is the model normalizing relative dates incorrectly (e.g., treating 'last quarter' as a fixed date without context), so include relative-date edge cases in your golden dataset and monitor for this pattern specifically in production logs.