Partial Array Streaming Prompt Template

This prompt template is for frontend and backend engineers building real-time applications that render structured list data as it arrives from a streaming LLM. Use it when your UI needs to display array elements incrementally—think infinite scroll feeds, progressive search results, activity logs, or dashboard widgets—and every emitted element must conform to a consistent record schema. The prompt instructs the model to emit array elements one at a time with explicit start-of-element and end-of-element markers, a total count hint, and a final completion signal. This is not a prompt for generating a complete JSON array in one response. It is designed for streaming protocols where the client parses partial chunks and appends validated records to a growing list.

The ideal user has a streaming endpoint (SSE, WebSocket, or chunked HTTP response) and a client-side parser that can buffer text between markers. You should use this prompt when you need to render the first few list items before the entire collection is generated, when the total result count is unknown at request time, or when you want to avoid the latency spike of waiting for a complete JSON array. The prompt works best with models that support true token-by-token streaming emission. Do not use this prompt when the output is consumed by a batch process that expects a single valid JSON document, when your downstream parser cannot handle incremental marker-based extraction, or when the model does not support streaming at all.

Before adopting this prompt, verify that your application layer can handle the marker protocol: [START_ELEMENT], [END_ELEMENT], [TOTAL_COUNT_HINT], and [STREAM_COMPLETE]. Your client must be prepared for partial chunks that may split a marker across two network frames. Implement a buffer that accumulates raw text, extracts complete elements between marker pairs, validates each record against your target schema, and appends only valid records to the UI list. If a record fails validation, decide whether to discard it, request a repair, or surface a placeholder. Also consider what happens when the stream disconnects mid-emission—your client should have a timeout and a fallback state that shows whatever valid elements were received before the interruption. This prompt is a streaming contract, not a fire-and-forget convenience.

This template instructs the model to emit a JSON array one element at a time as a stream of newline-delimited JSON (NDJSON) objects. Each line is a complete, valid record that can be parsed independently by a client rendering an infinite scroll list or progressive table. The prompt enforces homogeneous field presence, stable ordering, and explicit completion signaling so the client knows when the collection is finished.

textCopy
You are a streaming array generator. Your task is to produce a JSON array of records based on the provided [INPUT] and [CONTEXT]. You must emit the array incrementally as newline-delimited JSON (NDJSON), with each line containing exactly one complete array element.

## Input
[INPUT]

## Context
[CONTEXT]

## Output Schema
Each record must conform to this schema:
[OUTPUT_SCHEMA]

## Constraints
[CONSTRAINTS]

## Emission Rules
1. Emit exactly one record per line. Do not emit the opening bracket `[` or closing bracket `]`.
2. Every record must contain all fields defined in the schema. Do not omit fields, even if the value is null.
3. Field types must match the schema exactly. Do not coerce numbers to strings or vice versa.
4. Emit records in the order specified by [ORDERING_RULE]. If no ordering rule is provided, emit in the most logical order based on the input.
5. After the final record, emit a single line containing only the token `__COLLECTION_COMPLETE__` to signal the end of the array.
6. If no records can be produced, emit only the `__COLLECTION_COMPLETE__` token.
7. Do not include any explanatory text, markdown fences, or commentary outside the NDJSON lines and the completion token.

## Examples
[EXAMPLES]

## Risk Level
[RISK_LEVEL]

To adapt this template, replace each square-bracket placeholder with your specific values. [OUTPUT_SCHEMA] should be a JSON Schema object defining the exact shape of each record. [CONSTRAINTS] should list any business rules, such as "exclude records where status is 'archived'" or "limit to 50 records." [ORDERING_RULE] should specify the sort order, for example "by created_at descending." [EXAMPLES] should include one or two sample NDJSON lines showing correct field presence and types. For high-risk domains such as finance or healthcare, set [RISK_LEVEL] to high and ensure a human reviews the complete output before ingestion. Before deploying, validate that your client can parse each NDJSON line independently and that the __COLLECTION_COMPLETE__ token reliably triggers end-of-stream logic.

Integrating a partial array streaming prompt into an application requires a stateful client that can consume newline-delimited JSON (NDJSON) chunks and progressively build a UI list. The server-side harness should send each completed array element as a single NDJSON line, followed by a final control message that signals collection completion. This pattern allows the client to render items as they arrive without waiting for the full array, which is critical for infinite scroll and progressive list UIs where perceived latency directly impacts user experience.

On the server, wrap the model call in a streaming loop that reads tokens and assembles complete JSON objects. Use a buffer to accumulate characters until a valid JSON object boundary is detected—typically a closing } followed by a newline. Validate each object against the target record schema before emitting it as an NDJSON line. If a chunk fails validation, log the malformed object with the request ID and attempt a single retry with the accumulated context and a repair instruction. After the retry, if the object still fails validation, emit a structured error object with an _error field and a recoverable: false flag so the client can decide whether to skip the item or halt rendering. The final message should be a control object like {"_stream": "complete", "total_elements": 47} to signal that the array is finished and no more elements will arrive.

For production deployments, choose a model that supports streaming with low time-to-first-token and consistent JSON structure. Implement idempotency by attaching a stream_id to each request and storing emitted element hashes in a short-lived cache. If the client reconnects after a dropped connection, it can send the last received element index and the server can resume from the next element. Avoid emitting partial elements—only emit complete, validated objects. Monitor for element drift, where later elements in the stream change field types or omit required keys, by running a periodic eval that checks field homogeneity across the first 10, middle 10, and last 10 elements of test streams. When the prompt is used in high-stakes contexts such as financial record generation or clinical data extraction, require human review of the first three elements before the stream continues to the client.