A fluent ending is not proof of completion
A museum kiosk may show a readable sentence while the model is still delivering text. If the connection closes or the generation reaches a limit, a visitor-facing display could retain a fragment that sounds finished but omits the object restriction or date qualification. The editorial system needs a terminal status, not an attractive last line.
Consider a hypothetical exhibit label about a donated telescope. The draft begins with a correct accession date, then loses the final sentence explaining that the identification remains provisional. Publishing the text visible on screen would change the curatorial claim. The original object record, approved label and generation state must remain three separate records.
Recognize response.incomplete as a terminal event
The Responses streaming reference documents response.incomplete for responses that finish in an incomplete state. Its response object includes status and may include incomplete_details.reason; a documented example uses max_output_tokens. The event is distinct from response.completed, which indicates a complete model response.
The event tells an application that the model did not finish as an ordinary completed response. It does not establish that every sentence in the partial text is false or that a retry will fix the underlying problem. A safe application marks the candidate label blocked, stores limited diagnostic metadata and makes the next decision deliberately.
Keep deltas separate from the completed artifact
When streaming is enabled, response.output_text.delta delivers pieces of output as they are generated. These pieces are useful for a preview, but not equivalent to an approved final message. The server-side stream state and your editorial state should be represented separately, even when they appear on the same kiosk dashboard.
Build a small state machine with Previewing, Terminal Incomplete, Terminal Failed, Terminal Completed and Editorially Approved as distinct states. If your client loses the transport before seeing a terminal event, label the result Unknown rather than Completed. Partial delivery and partial generation can produce similar screens but require different investigations.
Read the reason without overinterpreting it
Record incomplete_details.reason when present, along with response ID, request model, relevant configuration and a controlled identifier for the source record. A max_output_tokens reason suggests the generation stopped at its output budget; it is not an instruction to publish a shortened passage.
Do not write code that assumes max_output_tokens is the only reason that can exist forever. The documented WebSocket steering behavior can also end a response with a steered reason and a successor event. Treat unknown reason strings as incomplete by default, and use transport-appropriate handling without claiming a successor will always arrive.
Show a visible preview-only boundary
Give reviewers an explicit preview state while streaming text arrives. Remove any Publish or Approve control until the client receives a valid completed result and the human source checks pass. Keeping the button disabled for incomplete or unknown outcomes is simpler than trying to infer semantic completeness from punctuation.
For example, a line that ends with a period may still be missing another paragraph on donor restrictions. The visual comparison in this guide contrasts streaming text, a terminal incomplete response and a separately approved caption. These are explanatory mock states, not recorded model output or proof of a specific error rate.
Guard the retry path against duplicate records
A retry can create a different response ID and a materially different label. Preserve an internal attempt key and link it to the exact source revision rather than overwriting the first attempt. If a client has an ambiguous network result, reconcile what completed before submitting a duplicate request.
A production integration should not blindly concatenate the last text delta of an incomplete attempt to the first delta of a new attempt. Keep each stream isolated by response ID. If resuming an interaction, use the documented conversation or response-continuation mechanisms appropriate to the chosen configuration and record the resulting lineage.
Avoid treating terminal success as factual approval
Even response.completed only says the API response completed, not that its claims were checked. The museum must still compare dates, names, object identifications and rights language against an authenticated catalog entry or other authoritative source. A complete but inaccurate label should fail editorial review.
Make the acceptance rule explicit: terminal completed status, full assembled output, source record version, and independent human sign-off. For restricted collections, require additional approval before public display. A text-generation endpoint has no authority to grant reproduction rights or classify a donor agreement as open.
Handle transport errors and partial rendering
Streaming clients can receive an error event or lose their network connection. Both may leave visible text in a preview pane. Your UI should clear a success indicator, retain a recoverable incident reference and prevent the preview from being cached into a visitor page as completed copy.
Monitor the difference between a model status of incomplete and a client that has no terminal status because it disconnected. In both cases publication stays blocked; diagnostics differ. Keep private prompts and archival passages out of ordinary application logs, and log only the event type, timestamps and approved record references needed to investigate.
Test the states with synthetic fixtures
Create an approved fictional object record with a two-sentence restriction and a deliberately incomplete example. Exercise the UI against simulated completed, incomplete, failed and interrupted streams. Verify button states, incident logging and the exact source revision used for review. No real donor materials are needed for this fixture.
A helpful automated test asserts that a last punctuation mark never turns the preview into an approved label. Another test checks that an unknown incomplete reason does not crash the handler. Still another tests that a reviewer cannot approve an output tied to an obsolete catalog revision. These are suggested tests, not ones run for this article.
Publish only after two independent gates
The first gate is technical: a terminal completion outcome and intact output assembly. The second is editorial: factual checking, legal review where applicable, accessibility review and recorded curator approval. A block at either gate prevents a change to the visitor-facing page.
The walkthrough is based on documentation and a hypothetical museum scenario. We have not run streaming API calls, confirmed actual model failure frequencies, timed retries or evaluated visitor-facing releases. Recheck the live event schema and application-specific transport before implementing this policy on a real collections system.
How We Research
Our November 11, 2026 desk review consulted the following named primary vendor documentation: OpenAI Responses streaming events; OpenAI Streaming API responses guide; OpenAI Responses create reference. We compared documented fields and failure semantics with a fictional museum workflow, distinguishing request-level facts from institutional approval decisions. The illustrations are original instructional graphics, not screenshots or observed service outputs. We did not execute API calls, access real museum records, run security or accuracy benchmarks, measure performance, or claim an actual success rate. Recheck version-specific service behavior, accounts, privacy, rights and independent source records before deploying a real workflow.
Frequently Asked Questions
The response finished in an incomplete state rather than through the normal completed event; examine its status and reason before deciding on a new attempt.
No. A period or natural-sounding ending does not prove that required qualifications or source restrictions were delivered.
No. It is an API lifecycle outcome. Human checking against source records is a separate release gate.
Treat the output status as unknown, preserve a minimal incident record and prevent publication until reconciled.
No. Keep response attempts separate and review any new completed output against the original, versioned catalog source.