Collect Local AI Feedback Without User Content

Direct answer

A feedback button can create a data path even when the inference itself runs on-device. Treat each report as a deliberate user action and define the payload before collecting anything. PRIVACY-01 and PRIVACY-02 support separating local execution, optional transmission, and disclosure, but they do not establish that any Cove app currently sends feedback. The test should ask which fields are attached, whether the user can inspect them, where they go, and how long copies remain. Start with the smallest useful report. A default can be a selected category such as incomplete answer or app error, plus app version and task mode. Prompts, transcripts, photos, health information, generated output, file paths, account identifiers, and diagnostic packages should not attach automatically. If an investigation needs a source sample, make that a separate choice with a clear purpose. Show the exact text or file before it leaves the device and allow cancellation. Keep a feedback form distinct from automatic analytics. A user-submitted report is a per-submission action that can be previewed and rejected; analytics may be transmitted without a new prompt on every event. They need different schemas, controls, and retention periods. Do not turn every poor rating into an upload or place user free text in an event name. Confirm that canceling a feedback screen does not leave a queued request that sends later. Use synthetic canaries to test the full path. Create fake prompts, outputs, transcripts, file names, and identifiers with unique markers. Submit each allowed category, cancel before sending, go offline, retry, and reconnect. Capture destination, payload fields, response, and any server-side test receipt. Compare the same workflow with feedback disabled and enabled. A quiet session does not prove that another feature or error path cannot transmit data. Consent and retention should be visible. Explain before sending whether the report leaves the device, its purpose, and any optional attachment. If deletion or withdrawal is offered, test how it affects client queues and downstream copies; do not promise all copies disappear unless the system can verify that. A saved draft differs from a transmitted report. Keep retention for feedback separate from retention for model results or crash diagnostics. Test failure cases: upload interrupted, duplicate tap, retry after reconnect, app process death, changed account, and a worker continuing after the screen closes. Assign stable request identifiers, protect authentication material, and avoid logging payloads. If TLS capture cannot reveal request contents, mark the limitation and use an approved test endpoint or server-side receipt. An empty inspector panel is not evidence that no payload was sent. The report should list app build, feedback schema version, event choices, user preview, synthetic fixture revision, observed fields, destination, retention, delete behavior, and blind spots. Keep model quality or product performance claims out of scope. This guide evaluates an explicit data transfer; it does not say Cove has a feedback feature, that a privacy policy is legally sufficient, or that feedback data is automatically anonymous.

A user reports an incomplete local answer

A user sees an incomplete answer from an on-device task and opens the feedback action. The team needs enough evidence to reproduce a failure but must not attach the original prompt or generated text without a separate, informed choice.

Decision

Send a minimal category and build metadata first; offer a separately previewed attachment only if a specific investigation needs it.

Expected outcome

The test shows the user can inspect or cancel and that the default payload excludes prompt, transcript, image, and generated output.

Evidence to collect

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

• Feedback schema
• Payload preview
• Network capture

A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.

Implementation workflow

1. Define the allowed feedback schema. List every field, its purpose, necessity, destination, retention, and owner before implementation; prohibit free-form source content unless each field is separately approved.
2. Create synthetic payload canaries. Use unique fake prompts, transcripts, photos, file paths, and outputs to detect whether source or result content enters the report.
3. Exercise preview, consent, and cancel. Submit each category, inspect all selected fields before sending, cancel at every stage, and verify no request remains queued afterward.
4. Capture retries and destination. Test offline submission, retry, reconnect, duplicate prevention, opt-out, and account changes against an approved endpoint using synthetic fields, then inspect queued events.
5. Check retention and deletion paths. Inspect client queues and any test server copy, then compare deletion and withdrawal behavior with the documented retention policy after cancellation.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• Default feedback excludes prompts, transcripts, images, generated answers, and private paths unless a user separately selects and previews them.
• Users can inspect, cancel, or opt out; a canceled or disabled report is not sent later through background retry.
• The evidence record shows payload and retention behavior without making a legal conclusion or model-quality claim.

Decision table

Failure patterns to prevent

• Attaching conversation text by default
• Encoding content in free-form metadata

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

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

• Cove network audit
• Google Play Data safety section
• Google Play user-data and SDK requirements
• Android security and privacy overview

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

Frequently asked questions