Event Timeline Reconstruction Prompt

This prompt is designed for research assistant and intelligence analysis systems that must reconstruct a chronological sequence of events from multiple, temporally-diverse source documents. The core job-to-be-done is converting a messy corpus of reports, articles, and filings into a single, ordered, and verifiable timeline. The ideal user is an engineering lead or AI builder integrating this capability into a product where analysts need to understand what happened and when, without manually cross-referencing dates across dozens of documents. Required context includes a set of source documents with explicit or implicit temporal markers, a target topic or entity to track, and a defined time window of interest.

Use this prompt when you have a static or slowly-updating corpus covering a topic over time and you need a structured output that resolves date conflicts, identifies information gaps, and attaches source citations and confidence indicators to each event. This is a batch processing pattern, not a real-time detection system. It excels in post-hoc analysis, such as building a litigation timeline from discovery documents, reconstructing a product's development history from internal memos, or synthesizing a competitive landscape's evolution from news archives. The prompt's value lies in its ability to handle implicit dates (e.g., 'last quarter'), normalize them to a standard format, and flag when sources disagree on the sequence or details of events.

Do not use this prompt for real-time streaming event detection, where latency and incremental updates are the primary concern. It is also the wrong tool when the temporal order is already known and trivial, or when you are summarizing a single, chronologically-structured document. Avoid this prompt if your source documents lack any temporal signals, as the model will be forced to hallucinate a sequence. For high-stakes intelligence or legal use cases, always pair this prompt's output with a human review stage and an eval harness that checks for temporal ordering accuracy, citation grounding, and conflict resolution quality before the timeline is accepted as a work product.

This prompt template is designed to be pasted directly into your model call. It instructs the model to act as an intelligence analyst, reconstructing an event timeline from the provided sources. The template uses square-bracket placeholders for all dynamic inputs—replace these with your specific query, source documents, output format requirements, and operational constraints before execution. The prompt is self-contained and includes instructions for handling date conflicts, identifying information gaps, and assigning confidence levels to each timeline entry.

textCopy
You are an intelligence analyst reconstructing a chronological event timeline.

## TASK
Reconstruct a detailed, chronologically ordered timeline of events related to the query below, using only the provided source documents. Resolve date conflicts where possible, identify information gaps, and assign a confidence level to each event.

## QUERY
[QUERY]

## SOURCE DOCUMENTS
[DOCUMENTS]

## OUTPUT SCHEMA
Produce a JSON object with the following structure:
{
  "timeline_title": "string",
  "query_temporal_scope": {
    "earliest_event_date": "ISO 8601 or null",
    "latest_event_date": "ISO 8601 or null",
    "scope_confidence": "high | medium | low"
  },
  "events": [
    {
      "event_id": "string",
      "date": "ISO 8601 date or date-time",
      "date_precision": "exact | day | month | year | range | approximate",
      "headline": "string (one-line summary)",
      "description": "string (detailed factual description)",
      "confidence": "high | medium | low",
      "source_ids": ["string"],
      "conflicting_sources": [
        {
          "source_id": "string",
          "conflicting_date": "ISO 8601",
          "conflict_note": "string"
        }
      ],
      "information_gaps": ["string"]
    }
  ],
  "unresolved_conflicts": [
    {
      "event_description": "string",
      "conflicting_dates": ["ISO 8601"],
      "source_ids": ["string"],
      "resolution_attempt": "string"
    }
  ],
  "information_gaps_summary": ["string"],
  "methodology_notes": "string"
}

## CONSTRAINTS
[CONSTRAINTS]

## INSTRUCTIONS
1. Extract all events from the source documents that are relevant to the query.
2. Order events chronologically from earliest to latest.
3. For each event, assign a confidence level:
   - **high**: Multiple sources agree on the date and details, or a single highly authoritative source provides precise information.
   - **medium**: A single source provides the information, or sources agree on the event but differ slightly on details.
   - **low**: The date or details are inferred, approximate, or come from a source with questionable authority.
4. When sources disagree on a date:
   - Prefer the source with higher authority or closer temporal proximity to the event.
   - Document the conflict in the `conflicting_sources` array.
   - If unresolvable, add the conflict to `unresolved_conflicts` and use the most likely date with `confidence: "low"`.
5. For each event, explicitly list any missing information (e.g., "exact time unknown," "location not reported").
6. If a date is approximate, set `date_precision` accordingly and note the uncertainty.
7. Do not fabricate events, dates, or details not present in the source documents.
8. If the provided sources are insufficient to reconstruct a meaningful timeline, return an empty `events` array and explain the insufficiency in `methodology_notes`.

To adapt this template for your application, replace the [QUERY] placeholder with the user's question or the topic of the timeline. Populate [DOCUMENTS] with your retrieved passages, ensuring each has a unique source_id for citation. The [CONSTRAINTS] placeholder is where you inject domain-specific rules, such as "Only include events from the last 30 days" or "Prioritize sources from regulatory filings over news articles." For high-stakes domains like legal or financial intelligence, always route the final output through a human review step before it is considered authoritative.

The Event Timeline Reconstruction Prompt is designed to be embedded in a multi-step pipeline, not called once in isolation. A typical harness ingests a set of temporally-diverse source documents, calls the prompt to produce a structured timeline, validates the output against temporal ordering constraints, and either returns the result or triggers a repair loop. The prompt expects a list of source texts with associated publication dates as input, so the application layer must handle document ingestion, date extraction, and deduplication before the prompt is invoked. For high-stakes intelligence or research workflows, the harness should also log every reconstruction attempt with the full input set, model version, and raw output for auditability.

Validation and Repair Loop: After the prompt returns a JSON timeline, the harness must run structural and temporal validation before the output reaches a user. Structural checks verify that every event has the required fields: event_id, date, description, source_ids, and confidence. Temporal ordering checks confirm that events are sorted chronologically and that no event has a date earlier than its preceding event. Conflict resolution quality can be scored by a separate LLM-as-judge eval that checks whether the conflict_notes field adequately explains date disagreements across sources. If validation fails, the harness should retry the prompt once with the validation errors appended as additional context. After two failures, the harness should escalate to a human reviewer rather than silently returning a broken timeline. For model choice, use a model with strong structured output support and a context window large enough to hold all source documents plus the prompt. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are all suitable; open-weight models like Llama 3.1 70B can work but require stricter output format enforcement.

Confidence Thresholds and Human Review: The prompt produces per-event confidence scores, which the harness should use to gate output delivery. Events with confidence below 0.6 should be flagged for human review before inclusion in the final timeline. Events where source_ids contains only one source and that source has low authority should also be escalated. The harness can implement a simple rule: if more than 20% of events in a timeline fall below the confidence threshold, the entire reconstruction is held for review. For applications where timelines feed downstream decision-making, log every confidence score alongside the event for later analysis of reconstruction reliability. Avoid the temptation to strip low-confidence events silently; users need to see information gaps, not a falsely clean timeline. The next step after implementing this harness is to build a regression test suite with known timelines, intentionally conflicting sources, and edge cases like missing dates or documents with no temporal information.