Anomaly Timeline Reconstruction Prompt

This prompt is designed for incident investigators, SOC analysts, and security engineers who need to reconstruct a coherent chronological narrative from fragmented, multi-source log events. It takes raw event data from SIEMs, application logs, cloud audit trails, and endpoint telemetry and produces a unified timeline with event correlation, causality hypotheses, and explicit evidence gaps. Use this prompt when you have scattered timestamped events and need a structured timeline that surfaces temporal inconsistencies, missing events, and potential attack chains. This prompt belongs in the investigation phase after initial anomaly detection but before root cause confirmation. It is not a replacement for a SIEM correlation engine; it is a reasoning tool that helps analysts make sense of events that automated rules failed to connect.

The ideal user has access to raw event exports and understands the schema of their log sources, but needs help structuring the narrative. You should provide the prompt with a list of events containing at minimum a timestamp, source system, and event description. The prompt works best when the event set is bounded to a specific time window and set of assets. Do not use this prompt for real-time alert triage or as a substitute for deterministic correlation rules. It is a post-hoc analytical tool. Before invoking the prompt, ensure you have already filtered the event set to the relevant investigation scope—feeding it unfiltered SIEM firehose data will produce noisy, low-quality timelines.

Avoid using this prompt when you need sub-second precision or when events must be legally sequenced for forensic admissibility without human review. The model may hallucinate causal links between unrelated events or invent missing events to fill gaps. Always validate the output against raw logs. The prompt includes explicit instructions to flag evidence gaps rather than fabricate connections, but you should implement a post-processing validation step that checks whether every asserted relationship in the timeline is supported by at least one input event. For high-severity incidents, the reconstructed timeline should be treated as an analyst's working hypothesis, not a finished incident report.

This prompt template is designed for incident investigators who need to build a chronological narrative from fragmented log events across multiple systems. It instructs the model to correlate events, hypothesize causality, identify evidence gaps, and flag temporal inconsistencies. The template uses square-bracket placeholders that you must replace with real values before execution—such as the raw log data, the incident time window, and the required output schema.

textCopy
You are an incident investigator reconstructing a chronological timeline from scattered log events.

## INPUT DATA
[RAW_LOG_EVENTS]

## INCIDENT WINDOW
Start: [START_TIMESTAMP]
End: [END_TIMESTAMP]

## OUTPUT SCHEMA
Return a single JSON object with the following structure:
{
  "timeline": [
    {
      "timestamp": "ISO 8601 string",
      "event_description": "concise description of what occurred",
      "source_system": "system or log file that produced this event",
      "source_event_id": "original event identifier from the source",
      "confidence": "high | medium | low",
      "correlated_events": ["list of related event_ids from this timeline"],
      "causal_relationship": "preceded_by | caused_by | unrelated | unknown"
    }
  ],
  "causality_hypotheses": [
    {
      "hypothesis": "description of a possible causal chain",
      "supporting_events": ["event_ids that support this hypothesis"],
      "contradicting_events": ["event_ids that contradict this hypothesis"],
      "confidence": "high | medium | low"
    }
  ],
  "evidence_gaps": [
    {
      "gap_description": "what information is missing",
      "expected_source": "where this information would normally be found",
      "impact_on_investigation": "how this gap affects conclusions",
      "suggested_remediation": "how to obtain the missing data"
    }
  ],
  "temporal_consistency_checks": [
    {
      "check_type": "out_of_sequence | timestamp_gap | duplicate_event | impossible_ordering",
      "affected_events": ["event_ids involved"],
      "description": "what the inconsistency is",
      "severity": "critical | warning | informational"
    }
  ],
  "investigation_summary": "a concise paragraph summarizing the reconstructed timeline and key findings"
}

## CONSTRAINTS
- Sort all timeline events chronologically. If timestamps are identical, order by logical dependency.
- For each event, assess confidence based on source reliability, timestamp precision, and corroborating evidence.
- Flag any event that appears out of sequence or has an impossible timestamp relative to other events.
- If two events have the same timestamp but conflicting descriptions, mark both with confidence "low" and note the conflict in temporal_consistency_checks.
- Do not invent events. If the evidence is insufficient to establish causality, use "unknown" for causal_relationship.
- For evidence gaps, be specific about what is missing and where it would normally reside.
- If the input data contains fewer than 3 events, return a single evidence_gap entry explaining insufficient data for reconstruction.

## RISK_LEVEL
[HIGH] This output may inform incident response actions. Human review is required before using this timeline for remediation decisions.

Adaptation guidance: Replace [RAW_LOG_EVENTS] with your actual log data, formatted as a list of event objects with at minimum timestamp, event_description, source_system, and source_event_id fields. Replace [START_TIMESTAMP] and [END_TIMESTAMP] with the incident window boundaries. If your investigation requires additional fields—such as user identity, asset tags, or severity scores—add them to the event objects in the input and extend the output schema accordingly. For high-stakes incidents, route the output through a human reviewer before acting on any causality hypotheses. Validate the JSON output against the schema before ingestion into your case management system, and log any schema violations for prompt refinement.

The Anomaly Timeline Reconstruction Prompt is designed to be called after an anomaly detection system has flagged a set of related events. In a production investigation workflow, this prompt should not be the first step. A pre-processing layer should gather the raw log events, normalize timestamps to a single timezone (typically UTC), deduplicate records, and attach source system identifiers before assembling the [EVENT_LOG] input. The prompt expects a structured JSON array of events, each with at minimum a timestamp, event_type, source_system, and description field. If your log sources use inconsistent timestamp formats, normalize them in the application layer before calling the model. The model is not a timestamp parser; it is a reasoning engine that assumes clean temporal data.

Wire this prompt into your investigation pipeline as a synchronous call with a timeout of 60-90 seconds for models like GPT-4o or Claude 3.5 Sonnet when processing 50-200 events. For larger event sets, implement a chunking strategy: split events into overlapping time windows, run the prompt on each window, then use a secondary merge prompt to reconcile overlapping hypotheses and produce a unified timeline. The output schema should be validated programmatically before the timeline reaches a human analyst. Check that every event_id referenced in the correlation_links array exists in the events array, that timestamp fields are ISO 8601 strings, and that causality_hypothesis entries include both confidence (a float between 0.0 and 1.0) and evidence (an array of at least one event_id). If validation fails, retry once with the validation errors appended to the [CONSTRAINTS] block. If the retry also fails, escalate the raw event set and partial output to a human analyst with a note that automated reconstruction was incomplete.

For high-severity incidents where the anomaly risk score exceeds your organization's defined threshold, insert a human review gate after timeline generation. The model's output should be rendered into a visual timeline in your investigation UI, with correlation links shown as annotated arrows and evidence gaps highlighted in amber. Analysts should be able to click any event to see the raw log entry, and click any causality hypothesis to see the supporting and contradictory evidence the model cited. Log every prompt invocation with the model version, input event count, output timeline length, validation pass/fail status, and analyst modifications. This audit trail is essential for post-incident review and for detecting when the model's reconstruction quality drifts due to model updates or changing log patterns. Do not allow the reconstructed timeline to auto-trigger downstream actions such as containment or blocking without human approval, even if the model's confidence scores are high.