Incident Report Structured Extraction Prompt

This prompt is designed for SRE, security, and operations engineers who need to convert narrative incident reports—postmortem drafts, on-call handoff notes, or ticketing system free-text—into a predictable, machine-readable JSON record. The core job is strict schema field extraction: pulling out the incident type, severity, a temporally ordered timeline of events, affected systems, and resolution steps from prose that is often messy, incomplete, or written under time pressure. The primary consumer is a downstream ingestion pipeline (e.g., an incident database, a dashboard, or an automated analysis tool) that breaks when fields are missing, mistyped, or hallucinated.

Use this prompt when you have a single, self-contained incident narrative and you need a typed record that can be inserted directly into a system of record. It is appropriate for post-incident review workflows, automated incident metric aggregation, and on-call tooling that enriches alerts with structured context. The prompt expects a narrative text block as input and returns a JSON object with fields for incident_id (if available), incident_type (from a defined enum), severity (with an explicit level mapping), status, affected_systems (as a list of canonical system names), timeline (an ordered array of events with timestamps, actions, and observations), resolution_steps, and contributing_factors. Every field includes null handling instructions so the model distinguishes between 'not mentioned' and 'explicitly absent.'

Do not use this prompt for real-time alert triage where latency is critical and the model call adds unacceptable delay. It is not a replacement for a human-authored postmortem; it extracts and structures what is already written. Avoid this prompt when the input spans multiple documents or requires cross-referencing external system logs—this is a single-document extraction task. If the incident report contains regulated data (e.g., PII in security incidents), ensure redaction occurs before the text reaches the model, and always route the structured output through a human review step before it lands in an immutable system of record. For high-severity incidents, the extracted severity field should be treated as a suggestion, not an automated declaration—human confirmation is required before paging or escalation actions fire.

This prompt template is designed to convert a free-text incident narrative into a strict, machine-readable JSON record. It forces the model to extract key fields—incident type, severity, affected systems, a temporally ordered timeline, and resolution steps—while explicitly handling missing or ambiguous information. Use this as the core instruction block in your extraction pipeline, replacing the square-bracket placeholders with your specific input text, desired output schema, and operational constraints.

textCopy
You are an incident data extraction system. Your task is to read the provided incident report narrative and extract structured information into a strict JSON schema.

[INPUT]

[OUTPUT_SCHEMA]

[CONSTRAINTS]

### Extraction Rules
1.  **Temporal Ordering:** Extract all events into a `timeline` array. Each event must have a `timestamp` (ISO 8601 if possible, otherwise the original text), an `event` description, and the `system` affected. Order events chronologically. If a timestamp is missing or relative ("30 minutes later"), set the `timestamp_confidence` field to `"low"` and use the best available text.
2.  **Null Handling:** If a field specified in [OUTPUT_SCHEMA] is not present in the report, set its value to `null`. Do not invent information. If a field is present but its value is ambiguous, set the value to `null` and add a note to the `extraction_notes` array explaining the ambiguity.
3.  **System Identification:** List all affected systems in the `affected_systems` array. Use the exact names from the report. If a system is implied but not named, do not guess; add a note to `extraction_notes`.
4.  **Resolution Steps:** Extract the steps taken to resolve the incident into the `resolution_steps` array. Preserve the order of actions as described.
5.  **Confidence Scoring:** For the top-level `severity` and `incident_type` fields, include a `confidence` score ("high", "medium", "low") based on how explicitly the information is stated in the report.

### Output Format
Return ONLY a single valid JSON object conforming to the provided schema. Do not include any text outside the JSON object.

To adapt this template, replace the placeholders with your specific operational context. [INPUT] should contain the raw incident report text. [OUTPUT_SCHEMA] must be a strict JSON Schema definition that includes fields for incident_type, severity, affected_systems, timeline, resolution_steps, and extraction_notes. The [CONSTRAINTS] placeholder is where you inject business logic, such as allowed values for severity (e.g., "enum": ["SEV1", "SEV2", "SEV3"]) or required system name formats. For high-stakes environments like security or SRE, always route outputs with confidence scores of "low" for critical fields to a human review queue before automated ingestion.

This prompt is designed to be called as a single step within an incident management or SRE automation pipeline. The primary input is an unstructured narrative incident report, which may come from a chat transcript, an email thread, a monitoring alert description, or a manually written postmortem draft. The application layer is responsible for assembling the final prompt by injecting the raw report text into the [INCIDENT_REPORT] placeholder and providing the expected [OUTPUT_SCHEMA] as a strict JSON schema. The model should be instructed to output only valid JSON that conforms to this schema, with no surrounding markdown or explanatory text. For production use, prefer models with strong JSON mode or structured output capabilities, such as gpt-4o or claude-3.5-sonnet, and enable their native constrained decoding features to prevent schema drift.

After the model responds, the application must validate the output before ingestion. First, confirm that the JSON is parseable and that all required fields defined in your schema are present. For fields marked as nullable in the schema, verify that the model returned null rather than an empty string or a placeholder like 'N/A'. Second, validate the temporal ordering of the timeline_events array: each event must have a timestamp in ISO 8601 format, and the array should be sorted chronologically. If the model's output fails structural validation, implement a retry loop (maximum 2 retries) by appending the validation error message to the prompt as a [PREVIOUS_ERROR] context and re-requesting the corrected JSON. If the output fails validation after retries, log the raw response and route the incident to a human review queue for manual structuring.

For high-severity incidents (e.g., severity: critical or severity: major), always require a human-in-the-loop approval step before the structured record is written to the system of record. The extracted fields should be presented in a review UI that highlights fields with low confidence or those that were inferred from ambiguous language. The confidence_notes field in the output schema is critical here; it should contain a brief explanation for any field where the model is uncertain. Wire this prompt into your observability stack by logging the full prompt, the raw model response, validation results, and the final approved record. This trace is essential for debugging extraction failures and for demonstrating auditability during post-incident reviews. Do not use this prompt for real-time alert triage where latency is critical; it is best suited for post-hoc report structuring where correctness and completeness outweigh speed.