Handle Partial Results from On-Device AI

Direct answer

Partial output should be represented as a different state from a completed, validated result. A screen that has already shown some generated text must not silently save it as final, let another feature execute it as a complete command, or export it without labeling its status. `COVE-LIFECYCLE-01` describes explicit model states but does not itself define a product-level state for partial user output. `ANDROID-WORK-CANCELLATION-2026-01` says WorkManager cancellation is cooperative and does not guarantee arbitrary native work stops instantaneously. `FUNCTION-01` treats a model-proposed action as a proposal, which reinforces the need to validate output before downstream use. Define a task result state machine before wiring UI. Possible states include not started, running with partial content, stopping, interrupted, validation pending, complete, rejected, and failed; use only states the product actually needs. For each state specify which text is visible, whether it can be copied, saved, exported, summarized again, or used as an input to a tool. Preserve the distinction between generated bytes and an accepted application result. If a parser requires a full JSON object, a truncated prefix is not a usable structured result, even when it looks plausible. Assign a stable task ID and output revision. When a new run starts, an older task must not overwrite it when a delayed callback arrives. Each partial chunk should be linked to its producing run and indicate whether it has passed structural or semantic checks. On cancellation, stop UI collection, request underlying work to stop through the documented mechanism, release owned resources when safe, and mark any retained text partial. Do not assume that cancelling a coroutine or worker means native inference has already halted. Likewise, process death means in-memory partial state may disappear; persist only what can safely be resumed or clearly restore the task as interrupted. Downstream actions need their own gate. A user may review partial prose, but a structured action, medical summary, or data export should require the product's validation and confirmation rules. If a user deliberately saves partial content, record it as a draft and preserve its incomplete status. A later retry can start from scratch or continue only if the runtime and data contract explicitly support continuation; do not invent resumability. Provide clear recovery controls such as discard, retry, or inspect partial output, and keep the original input immutable. Test interruption at multiple boundaries: before first token, after a short fragment, while a parser is waiting for closing structure, after validation but before persistence, during export, during activity recreation, and when background work is stopped. Include duplicate callbacks, reordered events, empty chunks, malformed final output, and a user tapping retry twice. Verify that a previous task cannot be marked complete by a late event from an older run. Use synthetic fixtures, not private conversations, and record task ID, state transitions, validation result, cancellation request, cleanup result, and visible UI. The final report should make the acceptance boundary observable: what was generated, what was validated, what the user approved, and what action actually persisted. A partial fragment is not proof of successful completion. A unit test of a state reducer is not proof native computation halted. Avoid aggregate success claims when interrupted runs are excluded. This guide concerns trustworthy state and user control, not model quality, speed, or the promise that every interrupted task can resume.

A user cancels a streamed draft before the answer is complete

The screen has displayed several sentences when the user taps stop. A delayed callback may still arrive, and the user could otherwise copy or export the fragment as if it were a verified final answer.

Decision

Mark the result partial immediately, reject stale callbacks from the cancelled task, and require explicit review before any save or downstream action.

Expected outcome

The user sees what was produced and what remains incomplete, with safe options to discard, inspect, or start a new task.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Result-state schema
• Interrupted-task fixtures
• Save and resume policy

Task quality needs a versioned corpus and acceptance rules. Fluent sample output is not an accuracy result.

Implementation workflow

To support this distinction, teams should record and compare three evidence items. A result-state schema defines how output states are represented, interrupted-task fixtures provide scenarios where output is cut short, and a save and resume policy governs how incomplete material is preserved across sessions. Together these items enable consistent evaluation.

1. Define result states and permitted actions. Write a state table for running, partial, interrupted, validation-pending, complete, rejected, and failed. For each, decide what may be copied, saved, exported, or used downstream.
2. Bind output to a task and revision. Assign stable run IDs and reject delayed events from old runs. Preserve chunk order and associate validation status with the exact output revision.
3. Implement cooperative cancellation. Stop UI collection, request cancellation through the documented worker/runtime interface, release owned resources, and keep any retained output marked partial.
4. Gate persistence and downstream use. Require schema validation and user confirmation for final actions. If partial output can be saved, store it as an explicitly incomplete draft.
5. Inject interruption and event races. Cancel at multiple stages, recreate the screen, stop background work, reorder callbacks, and retry twice. Confirm stale events cannot complete or overwrite a newer task.

Acceptance criteria

• Partial, complete, rejected, and failed output are separately represented in UI state and persistence.
• A cancelled/interrupted task cannot be completed or overwritten by a late callback, and resource cleanup is observed without assuming instantaneous native stop.
• No downstream action treats unvalidated partial output as a final result; the report records task IDs, transitions, and failure cases.

Decision table

Failure patterns to prevent

• Marking partial output complete
• Executing incomplete structured data

Common pitfalls include marking partial output complete, which conflates unfinished material with final results, and executing incomplete structured data, which treats unvalidated output as if it were reliable. Release wording should remain limited to evidence that has actually been recorded, avoiding claims that extend beyond what these recorded items demonstrate.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• FunctionGemma mobile actions
• Android WorkManager cancellation
• Kotlin cancellation and timeouts
• Android activity lifecycle

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions