Should an AI product show a partial result while a job is still running? The question sounds like a presentation choice, but it also changes what a reader may infer about evidence, completion and approval. A polished paragraph can look final even when later stages have not checked it.
This is an original discussion exercise using fictional workflows. It does not report a team's experience or claim that one interface pattern always performs better. The goal is to compare the benefits of early visibility with the need to distinguish a draft, an incomplete calculation and an approved result.
Consider two different partial results
In the first fictional workflow, an assistant drafts a summary while the source-selection stage is still collecting documents. The visible paragraph may change when additional evidence arrives. The product needs a way to explain that the reader is seeing an intermediate interpretation rather than the full evidence set.
In the second workflow, deterministic code has finished calculating validated counts, but the assistant is still drafting an explanation. The completed counts and the unfinished explanation have different statuses. Hiding both until the prose finishes may be unnecessary, while displaying both as final would blur an important distinction.
These examples suggest a useful starting question: which part of the output is partial? An incomplete evidence set, an unfinished calculation and an unreviewed narrative should not automatically receive the same label or the same interaction design.
Name what the reader can rely on
Write an output contract for each visible section. A source list might be complete for one stage while the final answer remains unreviewed. A progress count might describe accepted inputs without saying anything about whether the proposed conclusion is supported.
Choose labels that describe the actual state. Drafting, waiting for evidence and awaiting review communicate different conditions. A generic spinner or a confident opening sentence may leave the reader guessing which work has happened and which checks remain.
Avoid using the assistant's own statement of confidence as the completion signal. The application should know which stages completed and which review events occurred. A reader should not have to infer those facts from the tone of generated prose.
Decide which actions partial results permit
A reader may want to copy a partial result, share a link or act on a suggestion. Decide which actions the product supports before exposing an intermediate artifact. If copying is allowed, consider how the copied text preserves its draft or incomplete status.
For the fictional summary workflow, the team might allow a reviewer to inspect evidence as it arrives while keeping external publication unavailable. Another product might let a person export a clearly labeled draft. Those are different operating choices, and neither follows automatically from the ability to stream text.
A saved link should not silently change its meaning. If an intermediate version later becomes a revised final result, preserve enough version information for a reviewer to understand what was visible when the link was shared. The appropriate design depends on the application, but the question should be explicit.
Think through interruption
What should remain visible if the job stops halfway through? A blank screen loses potentially useful progress, while a normal-looking report can hide the interruption. A useful failure state can preserve completed sections and name the work that did not finish.
For a fictional document comparison, the application may have validated two inputs but failed while reading the third. The visible result should not imply that all three were compared. An unresolved-input list can be more informative than a generic error message pasted above an otherwise confident conclusion.
Decide whether a retry replaces the visible artifact or creates a new version. Keep verified completed work distinct from uncertain remote outcomes. A user should be able to tell whether the application resumed a stage, repeated it or started a new job with different inputs.
Keep evidence and narrative connected
If an early claim depends on an incomplete source set, show that limitation near the claim. A status banner at the top may be overlooked when a section is copied or viewed in isolation. Consider how the artifact will be read outside the original screen.
Stable evidence identifiers can help a reviewer inspect a draft as it changes. If a claim loses its supporting passage after a later selection step, the product should make that change detectable. A smooth stream of revised text can otherwise conceal a substantive shift in evidence.
Do not assume that showing more intermediate material always improves transparency. Unfiltered logs or raw private documents may expose information the reader does not need. Decide which progress evidence is useful and permitted, and keep debugging access separate from ordinary product access.
Evaluate the interface with fictional tasks
Prepare a small review exercise before choosing the final design. Give a reviewer an unfinished result and ask which sections they believe are complete, which sources they think were checked and which actions they think are authorized. Compare their interpretation with the application's actual state.
Include a successful run, an interrupted run and a run that finishes but fails review. These are distinct outcomes. If the interface presents all three as a completed answer, improving the wording of one label may not be enough; the state model itself may need clarification.
Record misunderstandings as observations rather than inventing an engagement statistic. A few fixture reviews can identify confusing cases without establishing that one design is universally superior. Explain the limits of the exercise and keep the examples available for later revisions.
Questions for the community
Which partial outputs would be useful in your workflow: accepted inputs, verified calculations, retrieved sources or a draft narrative? Which ones could create a misleading impression of completion? Describe a hypothetical task if you cannot share real application details.
Where should the approval boundary appear? Would a persistent status label be sufficient, or should a person take a separate action to mark a draft as reviewed? What information would need to accompany a copied excerpt for its status to remain clear?
How would you handle a result that is useful but permanently incomplete because one source is unavailable? Consider whether the product should preserve it as a partial artifact, hide it, or allow an explicit reviewer decision. Name the tradeoff instead of assuming every workflow needs the same answer.
A practical starting point
Try writing a small state table before implementing streaming or progress UI. Give each state a visible label, completed checks, remaining checks and permitted actions. Use the workflow planning guide to define the task boundary, and the evaluation worksheet to record whether a reviewer understands the result.
The discussion is less about whether partial text should exist and more about whether the application can explain what that text represents. A useful design lets a reader distinguish progress from evidence, a draft from an approved artifact, and a finished process from a successful outcome.