Session Replay Incident Reconstruction Prompt

This prompt is purpose-built for incident responders who need to reconstruct a specific user session from raw production trace data to understand its role in a broader incident. The core job-to-be-done is producing a single, unified timeline that overlays user session events, incident markers from external sources (such as monitoring alerts, deployment logs, or infrastructure events), and a clear impact assessment. The ideal user is an on-call engineer or SRE who already has a session ID tied to an incident and access to raw trace spans from an observability platform like Datadog, Honeycomb, or OpenTelemetry collectors. The required context includes the raw trace data for that session, the incident timeline from other systems, and the specific incident markers that define the investigation's boundaries.

Do not use this prompt for general session replay, product analytics, or user experience research. It is not designed for broad pattern discovery across many sessions, nor for generating aggregate metrics about user behavior. The prompt assumes a focused forensic context: a known incident, a known session, and a need to align that session's events with an external incident timeline. Using it outside this scope will produce verbose, misaligned output that confuses forensic analysis with general observability. The prompt also requires that the incident timeline from other sources is available as input; without it, the reconstruction cannot validate alignment and the output will lack the critical overlay that makes it useful for incident response.

Before using this prompt, confirm that you have the session ID, the raw trace spans, and the incident markers from your monitoring or deployment systems. If any of these inputs are missing, the reconstruction will be incomplete and the impact assessment will be unreliable. After running the prompt, validate the output by checking that all incident markers are correctly positioned relative to session events and that no trace spans were omitted. The next step is typically to use this reconstructed timeline to determine whether the session was a cause, a victim, or an unrelated bystander in the incident, which will guide your remediation decisions.

This prompt template is designed for incident responders who need to reconstruct a specific user session from production trace data and align it with known incident markers. The goal is to produce a chronological timeline that connects user-visible events with internal system behavior, helping you determine whether the incident originated from a prompt defect, retrieval gap, tool failure, or model error. Copy the template below, replace every square-bracket placeholder with actual values from your observability platform, and execute it in your incident response workflow. The output should be treated as an investigative artifact—not a final root-cause determination—and must be validated against independent incident timelines from other sources such as monitoring dashboards, on-call reports, or deployment logs.

textCopy
You are an incident response analyst reconstructing a user session from production trace data. Your task is to produce a structured incident timeline that connects user session events with known incident markers and assesses the impact on the user.

## INPUT DATA

### Trace Data
[TRACE_DATA]

### Incident Markers
[INCIDENT_MARKERS]

### User Session Identifier
[SESSION_ID]

### Incident Time Window
[INCIDENT_TIME_WINDOW]

## OUTPUT SCHEMA

Return a JSON object with the following structure:

{
  "session_identifier": "string",
  "incident_time_window": {
    "start": "ISO8601 timestamp",
    "end": "ISO8601 timestamp"
  },
  "reconstruction_timeline": [
    {
      "sequence_number": "integer",
      "timestamp": "ISO8601 timestamp",
      "event_type": "user_input | model_response | tool_call | tool_result | retrieval | state_change | error | incident_marker",
      "description": "string describing what occurred",
      "trace_span_id": "string or null",
      "incident_relevance": "direct | indirect | none",
      "impact_assessment": "string or null if no impact"
    }
  ],
  "incident_alignment": {
    "incident_markers_matched": ["list of matched marker IDs"],
    "alignment_confidence": "high | medium | low",
    "discrepancies": ["list of any mismatches between trace and incident markers"]
  },
  "impact_summary": {
    "user_visible_impact": "string describing what the user experienced",
    "failure_category": "prompt_defect | retrieval_gap | tool_failure | model_error | infrastructure | unknown",
    "severity": "critical | high | medium | low",
    "affected_turns": ["list of turn numbers or span IDs"]
  },
  "candidate_root_causes": [
    {
      "cause": "string description",
      "supporting_evidence": ["trace span IDs or event references"],
      "confidence": "high | medium | low"
    }
  ],
  "reconstruction_completeness": {
    "total_trace_spans": "integer",
    "spans_accounted_for": "integer",
    "gaps_identified": ["list of any missing spans or unexplained gaps"],
    "completeness_score": "0.0 to 1.0"
  }
}

## CONSTRAINTS

1. Include every trace span in the reconstruction. If a span cannot be placed in the timeline, list it under `gaps_identified`.
2. For each event, cite the specific trace span ID that supports it.
3. Do not invent events not present in the trace data.
4. When aligning with incident markers, note any discrepancies explicitly—do not force alignment.
5. If the trace data is incomplete or truncated, state this in `gaps_identified` and reduce `completeness_score` accordingly.
6. For `failure_category`, select exactly one value. Use `unknown` only if the trace evidence is insufficient to determine the category.
7. Mark `incident_relevance` as `direct` only if the event coincides with a known incident marker; use `indirect` for events in the same time window without clear causal connection.
8. If the trace contains sensitive data, redact it before including it in the output. Flag any remaining PII concerns in a separate note.

## VALIDATION RULES

Before returning the output, verify:
- The timeline is in strict chronological order.
- Every incident marker in the input appears in `incident_markers_matched` or is explained in `discrepancies`.
- `completeness_score` equals `spans_accounted_for / total_trace_spans`.
- No event description contradicts the trace data.

## RISK LEVEL: [RISK_LEVEL]

If RISK_LEVEL is `high`, append a human-review note to the output recommending that an incident commander validate the reconstruction before using it for root-cause determination.

After pasting this template, replace [TRACE_DATA] with the raw trace export from your observability platform—include all spans, tool calls, model responses, and retrieval steps for the session. Replace [INCIDENT_MARKERS] with the known incident timeline markers such as alert timestamps, deployment events, or error-rate spikes. Set [RISK_LEVEL] to high if the incident affects production users or involves regulated data; otherwise use medium or low. The output JSON can be ingested directly into your incident document or postmortem tool. Before relying on the reconstruction, cross-reference it against at least one independent data source—such as your monitoring dashboard or a separate trace query—to confirm the timeline alignment. If the completeness_score is below 0.9 or alignment_confidence is low, escalate for manual trace review rather than treating the output as authoritative.

This prompt is designed to be called during an active incident or post-incident review, not as a real-time streaming component. The primary integration point is an incident response bot or a runbook automation that receives an incident ID and a user session ID. The harness must first fetch the raw trace data from your observability platform (e.g., LangSmith, Arize, Datadog LLM Observability) and the incident timeline from your incident management tool (e.g., PagerDuty, FireHydrant). These two datasets become the [SESSION_TRACE] and [INCIDENT_TIMELINE] inputs. The prompt should only be invoked after both datasets are available and normalized to a common timezone, typically UTC, to prevent chronological misalignment.

Validation is critical because an incorrect reconstruction can misdirect an incident response. Implement a post-generation validation step that checks the output against a strict JSON schema. The schema must enforce that every session_event has a non-null timestamp, event_type, and trace_span_id, and that every incident_marker has a corresponding incident_timeline_id. Additionally, run a cross-reference check: for every incident_marker in the output, confirm that its correlated_session_event trace span ID actually exists in the input [SESSION_TRACE]. If validation fails, do not retry blindly. Log the validation error, append it to the prompt as a new [CONSTRAINTS] block (e.g., 'The previous output failed validation because incident marker X referenced a missing trace span'), and retry once. If the second attempt also fails, escalate to a human responder with the raw trace, the incident timeline, and both failed outputs.

Model choice matters here. Use a model with a large context window (at least 128k tokens) because production traces can be verbose. GPT-4o or Claude 3.5 Sonnet are strong defaults. Set temperature=0 to maximize determinism in the timeline reconstruction. Enable prompt caching on the static system instructions and the output schema to reduce latency and cost during repeated incident use. Log every invocation—including the prompt version, model, input trace IDs, and validation results—to an audit table. This log becomes part of the incident record and is essential for postmortem reviews. Never expose raw user inputs or PII in these logs without redaction. Finally, wire the validated output into your incident dashboard as a pinned timeline view, so that all responders share the same reconstructed session context.