Incident Timeline Narrative to Structured Timeline Prompt Template

This prompt is designed for incident response engineers and SRE teams who already have a free-text postmortem or incident summary generated by a model and need to force it into a strict, ordered schema. The primary job-to-be-done is extracting discrete event records—each with a timestamp, action, impact, and resolution—from a narrative that may be verbose, chronologically tangled, or missing explicit time markers. The ideal user is an engineer integrating AI-generated incident summaries into an incident management system, a time-series database, or a reporting dashboard that requires structured data, not prose. You should use this prompt when the upstream model failed to produce structured output directly, and you need a reliable repair step before ingestion.

Do not use this prompt to generate the initial incident summary from raw logs or alerts. It is not a root-cause analysis tool, nor is it designed to classify incident severity or assign ownership. It assumes the narrative already contains the relevant facts and only needs to be reorganized. The prompt is also inappropriate when the source text is too sparse to support temporal ordering—if the narrative lacks timestamps, durations, or sequential cues, the model will either hallucinate an ordering or produce records with null timestamps, both of which require downstream handling. In high-severity production incidents where timeline accuracy is critical, always pair this prompt with a human review step to verify event ordering and source grounding before the structured output enters any system of record.

Before using this prompt, ensure you have the complete narrative text, a defined output schema for your event records, and a clear understanding of which fields are required versus optional. The prompt template includes placeholders for constraints like timezone normalization and minimum required fields. After extraction, validate the output by checking that every event record can be traced back to a specific sentence or paragraph in the source narrative, that timestamps are in strictly non-decreasing order, and that no events from the source were dropped. If the narrative describes an incident spanning multiple services, consider running the prompt once per service scope to avoid interleaving errors.

This prompt is designed as a post-generation repair step. Use it when a model has already produced a free-text incident report or postmortem narrative, and you need to extract a machine-readable, chronologically ordered timeline of events. The prompt instructs the model to parse the narrative, identify discrete events, normalize timestamps, and output a strict JSON array. It is not intended for generating the initial narrative; it is a conversion harness that enforces temporal ordering and source traceability.

textCopy
You are an incident timeline extraction engine. Your task is to convert the provided free-text incident narrative into a structured, chronologically ordered timeline of events.

## INPUT NARRATIVE
[INPUT_NARRATIVE]

## OUTPUT SCHEMA
Return a single JSON object with a key "events" containing an array of event objects. Each event object must conform to this exact schema:
{
  "event_id": "string, a unique identifier for the event (e.g., 'EVT-01')",
  "timestamp": "string, ISO 8601 format (YYYY-MM-DDTHH:MM:SSZ). If the exact time is unknown, use the most precise time available and note it in the 'certainty' field.",
  "action": "string, a concise description of what happened (max 120 characters)",
  "actor": "string, the system, service, or person responsible for the action. Use 'unknown' if not specified.",
  "impact": "string, the immediate observable consequence of the action (e.g., '503 errors increased to 15%', 'database writes blocked')",
  "status": "string, one of: 'trigger', 'escalation', 'mitigation', 'resolution', 'investigation'",
  "source_quote": "string, the exact sentence or phrase from the input narrative that provides evidence for this event",
  "certainty": "string, one of: 'exact', 'approximate', 'inferred'"
}

## CONSTRAINTS
1. **Ordering**: The "events" array MUST be sorted by "timestamp" in ascending chronological order.
2. **Grounding**: Every event MUST have a "source_quote" that is a direct, verbatim copy from the [INPUT_NARRATIVE]. Do not paraphrase.
3. **Completeness**: Extract ALL events described in the narrative. Do not summarize or omit low-severity events.
4. **No Hallucination**: Do not invent timestamps, actions, or impacts not present in the narrative. If a detail is missing, use 'unknown' for strings and 'inferred' for certainty.
5. **Temporal Consistency**: If two events have the same timestamp, order them by their logical sequence as described in the narrative.

## EXAMPLE
[FEW_SHOT_EXAMPLE]

## RISK LEVEL
[RISK_LEVEL: low | medium | high]

Now, process the INPUT NARRATIVE and return only the JSON object. Do not include any text before or after the JSON.

To adapt this template, replace the square-bracket placeholders with your specific context. The [INPUT_NARRATIVE] should contain the full free-text report. The [FEW_SHOT_EXAMPLE] is critical for teaching the model the expected level of granularity and the difference between 'trigger' and 'escalation' statuses. For high-stakes incident reviews, set [RISK_LEVEL] to 'high' and ensure a human reviews the extracted timeline against the original narrative. The source_quote field is your primary defense against hallucination—every extracted fact must be directly attributable. Before integrating this into a production pipeline, run it against a golden dataset of 20-30 incident narratives and measure exact-match accuracy on timestamps and event counts.

This prompt converts an unstructured incident narrative into a structured JSON timeline. In production, you should never trust a single model call to produce a valid, temporally consistent timeline without verification. The harness wraps the prompt in a pipeline that validates the output schema, checks temporal ordering, grounds events to source text, and escalates ambiguous or conflicting entries for human review. The prompt itself is the core transformation step, but the harness is what makes it safe to ship.

Start by defining a strict output schema using Pydantic, Zod, or JSON Schema. Each event record must include timestamp (ISO 8601), event_type (enum: detection, diagnosis, action, escalation, resolution, communication), description (string), actor (string or null), impact (string or null), source_quote (string), and confidence (enum: high, medium, low). After the model responds, run a multi-stage validator: (1) schema conformance—reject malformed JSON and retry with the repair prompt from the Malformed JSON and Structured Format Repair playbook; (2) temporal ordering—iterate through the sorted timeline and flag any event whose timestamp precedes the previous event, then route flagged sequences to a human reviewer; (3) source grounding—for each event, verify that source_quote is a verbatim substring of the input narrative using a fuzzy string match with a minimum similarity threshold of 0.85, and flag events below threshold as potentially hallucinated; (4) completeness—check that at least one event of each required event_type is present if the narrative describes a full incident lifecycle, and warn if critical phases are missing.

Wire the prompt into an incident management pipeline where it fires after a postmortem narrative is submitted. Use a model with strong JSON mode and long-context support—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are good defaults. Set temperature=0 for deterministic output. Implement a retry loop with a maximum of three attempts: if validation fails, append the specific validation errors to the retry prompt as [CONSTRAINTS] so the model can self-correct. If all retries fail, log the raw narrative and partial timeline to an internal review queue and notify the on-call engineer. For high-severity incidents, add a mandatory human approval step before the structured timeline is published to the incident record system. Store the prompt version, model version, and validation results alongside each generated timeline for auditability.

Common failure modes to monitor: the model invents timestamps when the narrative uses relative time expressions like 'an hour later' or 'by morning'—your harness should detect missing absolute timestamps and either prompt the model to infer them with explicit assumptions or flag them for human annotation. The model may also merge distinct events into one or split a single event into multiple entries; temporal ordering checks catch some of this, but periodic spot-checks against the source narrative are essential. Finally, the model may assign incorrect event_type values—for example, labeling a diagnosis step as an action—so include a few-shot examples in the prompt that clearly distinguish each type and consider adding a lightweight classification check in the harness that verifies event_type assignment against simple keyword heuristics from the source_quote.

Next steps: deploy the prompt with the validation harness in a staging environment and run it against a golden dataset of 20–30 annotated incident narratives to measure schema conformance rate, temporal ordering accuracy, and source grounding precision. Use the LLM Judge and Evaluation Rubrics playbook to build automated eval criteria. Once precision exceeds 95% and hallucination rate is below 2%, promote to production with the human review gate active for all high-severity incidents. Revisit the prompt and harness quarterly as your incident taxonomy evolves.