User Review for Offline AI Results

Direct answer

Reviewing an AI result is a product state transition, not a decorative thumbs-up after generation. Preserve the source input, generated draft, uncertainty markers, user edits, and final accepted version as distinguishable records. `FUNCTION-01` demonstrates that a model-generated action is proposed to a host rather than automatically executed; `PRIVACY-01` states that local inference does not prove every other data path is absent. These facts support a deliberate review boundary: the model can suggest, but application policy and user action determine what becomes an accepted result or leaves the device. Define what “reviewed” means for the actual task. Reading a summary, correcting a sentence, approving a structured extraction, and confirming a translation are not identical. Give each operation a review state such as draft, needs attention, edited, accepted, rejected, or superseded only where the implementation needs it. Link each candidate to its source revision and the model/runtime/prompt/parser versions available. Do not overwrite the original input or erase earlier corrections when a new generation arrives. Keep provenance proportional to the need; avoid storing raw chain-of-thought or diagnostic rationale as review evidence. Show uncertainty in a way the user can act on. Highlight spans that were missing, changed, inferred, or failed deterministic validation. A global confidence badge without a defined calculation can mislead; if confidence is not exposed by the runtime, do not invent a score. Offer concrete actions: compare source and result, edit, accept, reject, retry a failed portion, or keep as an explicitly partial draft. If the result triggers a consequential operation, acceptance of text and authorization of the operation should remain separate controls. A model's wording “I have done this” is not proof that any external action happened. Test review transitions with fixed synthetic examples. Include a correct output, a fluent but source-inaccurate output, missing information, contradiction, unsupported field, malformed structure, interruption, and duplicate generation. Verify that an accepted version points to the exact reviewed candidate; a later regenerated draft should not silently replace it. Exercise navigation and process recreation so an unsaved edit is either restored according to policy or clearly marked as not saved. If sharing is supported, preview the accepted content and distinguish it from the untouched source and earlier draft. Privacy follows the entire review lifecycle. User edits may add details not present in the original source. Check where drafts and accepted versions are stored, whether they are backed up, searchable, copied, logged, or exported, and how deletion affects derived versions. Avoid analytics fields that serialize the whole conversation. For a sensitive task, use a redacted or synthetic fixture and let the user review a share bundle before it crosses the app boundary. The acceptance record should capture build, task type, source and result IDs, review state transitions, validation rules, user edits, storage/export behavior, and failure results. It should not pretend that a human clicked “accept” for a test they did not inspect. A passing review-state test confirms that the interface preserved distinctions; it does not certify that the model's content is true, safe, or high quality. Keep those claims tied to a separate evaluation process.

A user reviews a generated local summary before saving it

The app produces a summary from a source note containing a qualification that must not be dropped. The user edits the first draft, then a delayed second-generation result arrives and could overwrite that reviewed correction unless the workflow distinguishes draft versions.

Decision

Keep source, first draft, user correction, and accepted version linked but distinct; prevent a late response from overwriting the version the user reviewed.

Expected outcome

The history shows what was generated, what the user changed, and exactly which version was accepted without labeling generation itself as approval.

Evidence to collect

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

• Review-state schema
• Accepted and rejected fixtures
• Edit and export record

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

Implementation workflow

Use a defined review-state structure to log, compare, and follow the progress of approved and rejected fixtures alongside every recorded edit and export action, ensuring that each element is traceable within the workflow and that changes can be reviewed against the underlying source at every stage. (FUNCTION-01)

1. Specify task-specific review states. Define draft, needs-review, edited, accepted, rejected, and partial states only where they match the user task. Identify which actions are allowed in each state.
2. Preserve source and candidate provenance. Link each candidate to source revision and available model/runtime/prompt/parser identity. Keep original input and prior accepted output immutable when new drafts arrive.
3. Make uncertainty actionable. Show missing, inferred, changed, and failed-validation spans. Let the user compare, edit, accept, reject, retry, or keep a labeled partial result.
4. Test state transitions and races. Use synthetic correct, incorrect, contradictory, malformed, interrupted, and duplicate outputs. Recreate the screen and ensure late responses cannot overwrite the reviewed version.
5. Audit persistence and share boundaries. Verify drafts, edits, accepted results, backups, search, logs, deletion, and export separately. Preview only the selected content before any user-directed share.

Acceptance criteria

• Source, generated candidate, user edits, and accepted result are distinguishable and linked to the exact candidate revision.
• A later or duplicated model response cannot silently overwrite an accepted or edited version, including after screen recreation.
• Review evidence is limited to the interface/state test; the report does not claim content truth, safety, or quality from an acceptance click.

Decision table

Failure patterns to prevent

• Overwriting source content
• Treating generation as approval

Avoid letting modifications overwrite the original source content, and resist the assumption that a generated result constitutes approval; any language about a release or acceptance should be limited strictly to what the recorded evidence explicitly supports. (PRIVACY-01)

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
• Google Gemma function calling guide
• Android app architecture guide
• Android Compose state saving

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

Frequently asked questions