SSE Event Stream Parsing and Assembly Prompt Template

This prompt is designed for streaming infrastructure teams that consume raw Server-Sent Events (SSE) directly from LLM providers, real-time APIs, or internal event buses. The core job-to-be-done is transforming an unstructured, multi-event text stream into a single, validated, and ordered payload. Use this prompt when you have captured the raw text of an SSE stream—including event:, data:, and id: fields—and need a model to interpret the stream's structure, deduplicate data fields, and handle reconnection gaps signaled by Last-Event-ID headers. The ideal user is a backend engineer or platform developer who already has the raw SSE text in hand and needs to offload the complex parsing logic to an LLM before the assembled payload is passed to downstream application code.

This prompt is not a general-purpose streaming text assembler. Do not use it for simple text chunk assembly from streaming LLM APIs that lack SSE framing; for that scenario, use the Streaming Chunk Assembly Prompt Template. This prompt assumes the input is a complete, captured SSE stream, not a live, incremental feed. It excels at interpreting the protocol-level structure of the stream: extracting multiple data: lines, associating them with their event types, ordering them by id: where present, and resolving the state after a reconnection. A concrete example is processing a stream from an LLM provider that sends tool call arguments across multiple data: events, where the final payload must be a single, valid JSON object with all arguments correctly merged and ordered.

Before using this prompt, ensure you have already captured the raw SSE text and that your application has handled the HTTP connection lifecycle. The prompt's output should be validated against your expected schema using a deterministic post-processing step. If your primary challenge is real-time chunk buffering, overlap detection, or incremental rendering, start with the streaming-specific sibling prompts in this content group. This prompt is the right choice when the problem is interpreting the SSE protocol itself, not managing the live stream.

This template is designed for streaming infrastructure teams that consume Server-Sent Events (SSE) and need to reassemble discrete event fragments into coherent, validated payloads. The prompt expects a raw SSE stream as input and produces a structured output that includes the assembled content, a gap report, and an ordering audit. Use this template when your application layer receives raw event text that must be parsed, deduplicated, and validated before downstream consumption. Do not use this template for WebSocket streams, chunked transfer encoding, or non-SSE streaming protocols without adapting the event boundary logic.

textCopy
You are an SSE event stream parser and assembly engine. Your job is to consume a raw Server-Sent Events stream, extract data fields from each event, detect and report gaps caused by reconnection or dropped events, and assemble the complete response payload in correct order.

## INPUT
Raw SSE stream text:

[RAW_SSE_STREAM]

codeCopy

## OUTPUT SCHEMA
Return a single valid JSON object with the following structure:
{
  "assembled_content": string,          // The complete reassembled payload from all data fields, concatenated in event order
  "event_count": integer,               // Total number of events processed
  "last_event_id": string | null,       // The id of the final event in the stream, or null if no id field present
  "gaps_detected": boolean,             // True if any event sequence gaps were found
  "gap_report": [                        // List of detected gaps, empty if none
    {
      "expected_id": string | null,     // The event id that was expected but missing
      "received_id": string | null,     // The event id that was actually received after the gap
      "gap_type": "missing" | "duplicate" | "out_of_order" | "unknown",
      "description": string             // Human-readable explanation of the gap
    }
  ],
  "ordering_valid": boolean,            // True if all events arrived in ascending id order (when ids are present)
  "truncated_stream": boolean,          // True if the stream appears to end mid-event or with an unclosed data block
  "warnings": [string]                  // Any non-fatal issues encountered during parsing (encoding artifacts, empty data fields, etc.)
}

## CONSTRAINTS
- Parse event boundaries using the standard SSE double-newline delimiter (\n\n).
- Extract the `data` field from each event. If an event contains multiple `data` lines, join them with newlines.
- Track event `id` fields for sequence validation. If no id field is present, rely on event order in the stream.
- If the stream contains a `retry` field, note it in warnings but do not apply it.
- Handle comment lines (starting with `:`) by ignoring them.
- If the stream ends with an incomplete event (no double-newline terminator), set `truncated_stream` to true and assemble whatever partial data is available.
- Do not invent or hallucinate event content. Only use data explicitly present in the input stream.
- If the input is empty or contains no valid SSE events, return `assembled_content` as an empty string with `event_count` set to 0.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

Adaptation guidance: Replace [RAW_SSE_STREAM] with the actual SSE text your application received. The [EXAMPLES] placeholder should be replaced with 2-3 few-shot examples showing correct parsing behavior, including at least one example with a detected gap and one with a truncated stream. Set [RISK_LEVEL] to low, medium, or high based on your use case—this controls whether the prompt includes additional validation instructions or requests for human review. For high-risk applications such as financial transaction streams or clinical data feeds, add a constraint requiring that any gap of type missing triggers an immediate escalation rather than silent assembly.

Before deploying this prompt, validate the output against the JSON schema defined above. Common failure modes include the model treating SSE comment lines as data, failing to join multi-line data fields correctly, or misidentifying out-of-order events when id fields are non-numeric. Run this prompt against a golden dataset of known SSE streams—including streams with injected gaps, duplicates, and truncation—and confirm that gaps_detected, ordering_valid, and truncated_stream match expected values before releasing to production.

This prompt template is designed to sit inside a stream-processing worker that consumes raw Server-Sent Events from an upstream provider or internal service. The worker's job is to accumulate discrete data: lines, detect event boundaries, handle reconnection gaps, and pass the assembled buffer to the LLM only when assembly is required—typically after a connection drop, an out-of-order sequence, or a malformed event payload. Do not call the model for every event; reserve it for repair and assembly scenarios where deterministic parsing fails.

Wire the prompt into an event-processing pipeline with the following stages: (1) Raw ingestion—a long-lived HTTP client or WebSocket listener that buffers SSE lines and tracks id and retry fields. (2) Deterministic pre-processing—a lightweight parser that extracts data fields, decodes UTF-8, and appends to an ordered buffer keyed by event ID or sequence number. (3) Anomaly detection—a rules engine that flags gaps in sequence numbers, unclosed JSON objects, duplicate IDs, or events arriving outside the expected time window. (4) LLM assembly gate—only when anomalies exceed a threshold (e.g., missing sequence range > 3 events, or unparseable JSON), construct the prompt with [RAW_EVENT_STREAM], [GAP_DESCRIPTION], and [EXPECTED_SCHEMA], then call the model. (5) Output validation—run the model's assembled output through a JSON Schema validator matching [EXPECTED_SCHEMA]. On failure, retry once with the validation error injected into [PREVIOUS_ERRORS]. If the retry also fails, log the raw events and assembled output, then escalate to a dead-letter queue for human review or offline repair.

Model choice and latency budget: Use a fast, instruction-following model with strong JSON output capabilities (e.g., GPT-4o, Claude 3.5 Sonnet, or a fine-tuned open-weight model). Set response_format to json_object or equivalent structured output mode. Keep the prompt concise—token overhead directly adds latency to an already-latent repair path. Target < 500ms p95 for the LLM call; if your provider cannot meet this, consider a local model for the assembly path. Retry strategy: Implement exponential backoff with jitter for transient provider errors (429, 503). For validation failures, retry exactly once with the error context. Do not retry on safety refusals or content policy blocks—escalate immediately. Logging and observability: Emit structured logs at each stage: sse.raw.received, sse.anomaly.detected, sse.assembly.llm_called, sse.assembly.validation_passed, sse.assembly.dead_letter. Include the event range, gap description, model latency, and validation result. This trace is essential for tuning anomaly thresholds and identifying upstream providers that frequently produce malformed streams.

What to avoid: Do not send the entire event stream history to the model on every call—include only the affected window plus a small context buffer (e.g., 2 events before and after the gap). Do not use this prompt for real-time event-by-event processing; it is a repair path, not a hot path. Do not trust the model's output without schema validation—models can hallucinate event data to fill gaps. Finally, ensure your dead-letter queue has retention and alerting; silent data loss in event assembly can corrupt downstream state for hours before detection.