Streaming Chunk Assembly Prompt Template

This prompt is for real-time application developers and streaming infrastructure engineers who consume LLM outputs via chunked transport (Server-Sent Events, WebSockets, or streaming HTTP responses) and must reassemble fragmented text into a single, coherent, and valid payload. The core job-to-be-done is taking an ordered or semi-ordered sequence of text chunks—which may contain overlaps, split words, duplicated phrases, or encoding artifacts—and producing a clean, deduplicated, and correctly sequenced final output that matches an expected schema or format. The ideal user is building a production system where a malformed stream breaks a downstream parser, corrupts a user-facing UI, or violates an API contract.

Use this prompt when your streaming pipeline exhibits specific failure modes: consecutive chunks that repeat the last sentence of the previous chunk, token-boundary splits that leave words broken across chunk edges, out-of-order delivery from parallel backends, or encoding corruption introduced during transport. The prompt is designed to operate as a post-stream repair step, not as a real-time interceptor. It expects the full set of received chunks as input, along with metadata such as expected ordering keys or overlap window sizes. Do not use this prompt for real-time token-by-token rendering where latency is measured in milliseconds; this is a batch assembly operation that trades latency for correctness. It is also not a substitute for fixing the upstream chunking logic—if your provider consistently sends malformed chunks, address that at the source before applying this repair layer.

Before wiring this prompt into your application, define the expected output schema and the failure modes you are targeting. If your stream includes structured data (JSON, XML, or function call arguments), pair this prompt with a schema validation step after assembly. For high-risk domains where assembly errors could cause data corruption, financial misstatement, or clinical inaccuracy, require human review of the assembled output or implement a confidence threshold that escalates ambiguous merges. The next section provides the copy-ready prompt template you can adapt to your specific chunk format and output requirements.

This template is designed to be dropped into a post-streaming assembly pipeline. It expects a collection of raw text chunks, optional metadata about their order or overlap, and a target output schema. The prompt instructs the model to detect and resolve overlaps, remove duplicate content, repair split tokens at chunk boundaries, and produce a single valid output that conforms to the provided schema. Use this when your streaming consumer has accumulated all chunks and needs a final assembly step before the payload enters downstream systems.

textCopy
You are an output assembly engine. Your task is to reconstruct a coherent, complete, and valid payload from a set of streaming text chunks that may contain overlaps, duplicates, split tokens, or minor ordering issues.

## INPUT CHUNKS
Below are the raw chunks received from the streaming API. Each chunk is labeled with a sequence number and may contain partial content.

[CHUNKS]

## ASSEMBLY RULES
1. **Ordering**: Chunks are labeled with sequence numbers. Use these to determine the intended order. If sequence numbers are missing or conflicting, use semantic continuity to infer correct ordering.
2. **Overlap Detection**: Identify overlapping text between consecutive chunks. When overlap is detected, merge the chunks by aligning the overlapping region and including it only once. Overlaps may be partial words, sentences, or paragraphs.
3. **Token Boundary Repair**: If a word or token is split across a chunk boundary (e.g., "hel" in one chunk and "lo" in the next), repair it to the complete word ("hello").
4. **Deduplication**: Remove any content that appears verbatim in multiple chunks unless it is clearly intentional repetition (e.g., a repeated refrain, a structured list item, or a template header). Flag any ambiguous cases in the [ASSEMBLY_NOTES] field.
5. **Schema Compliance**: The assembled output MUST conform to the [OUTPUT_SCHEMA] provided below. If the assembled content cannot satisfy a required field, set that field to null and note the gap in [ASSEMBLY_NOTES].
6. **Truncation Handling**: If the final chunk appears truncated (incomplete sentence, unclosed bracket, or partial field), mark the output as incomplete by setting `"complete": false` in the assembly metadata and include the last complete valid state.

## OUTPUT SCHEMA
[OUTPUT_SCHEMA]

## OUTPUT FORMAT
Return a JSON object with the following structure:
{
  "assembled_output": { ... }  // The reconstructed payload conforming to [OUTPUT_SCHEMA]
  "assembly_metadata": {
    "complete": true | false,
    "chunks_used": [1, 2, 3, ...],
    "overlaps_resolved": [
      {"between_chunks": [1, 2], "overlap_text": "..."}
    ],
    "repairs_applied": [
      {"type": "token_boundary" | "deduplication" | "ordering", "description": "..."}
    ]
  },
  "assembly_notes": ["Human-readable notes about any ambiguities, gaps, or decisions made during assembly."]
}

## CONSTRAINTS
[CONSTRAINTS]

Adaptation guidance: Replace [CHUNKS] with your accumulated streaming chunks, each annotated with a sequence number or timestamp. Replace [OUTPUT_SCHEMA] with your target JSON Schema, Protobuf definition, or type specification. Use [CONSTRAINTS] to add domain-specific rules—for example, maximum field lengths, forbidden content patterns, or required citation formats. If your streaming provider does not supply sequence numbers, modify the ordering rule to rely on timestamps or arrival order with explicit caveats. For high-risk domains (healthcare, finance, legal), add a human review step before the assembled output is committed to any system of record, and include a [RISK_LEVEL] placeholder that gates whether automated assembly is permitted or must be queued for review.

The streaming chunk assembly prompt is designed to sit between your raw SSE or WebSocket event handler and your downstream application logic. It should be invoked only after the stream has ended or when a timeout threshold is reached without a complete payload. Do not call this prompt on every individual chunk—it is a post-stream repair step. The typical integration pattern is: accumulate raw chunks in a buffer, detect stream termination (or a configurable silence window), then pass the concatenated buffer and the expected output schema to the assembly prompt. The prompt returns a repaired, deduplicated, and schema-conformant payload that your application can parse and use.

For production wiring, implement a lightweight state machine around the prompt call. First, validate that the assembled output matches your expected schema using a deterministic parser (e.g., jsonschema in Python, zod in TypeScript). If validation fails, retry the assembly prompt once with the validation error message appended to the [CONSTRAINTS] field. If the second attempt also fails, log the raw chunks and the failed output to your observability pipeline and fall back to a degraded response—never expose raw, unassembled chunks to end users. For high-throughput systems, consider batching assembly requests or using a dedicated model with lower latency for this repair step, as the primary generation model may be overkill for what is essentially a text-normalization task.

Observability is critical here because chunk assembly failures often indicate upstream issues like provider-side truncation, encoding corruption, or schema drift. Log the number of chunks received, the total byte length, the assembly prompt's latency, and the validation pass/fail status as structured metrics. Set alerts on assembly failure rates exceeding 1% of streams. If you are operating in a regulated domain where output correctness is mandatory, route all assembled outputs through a human review queue when the assembly prompt modifies more than a configurable percentage of the original content or when it flags uncertainty in its own output. Avoid the temptation to silently patch outputs—every repair should be traceable to the raw stream for audit purposes.