Direct answer
A retention policy is more specific than a delete button. It defines which data classes remain, for what product purpose, when an expiry or user action applies, and which derived copies follow the source. PRIVACY-01 and ANDROID-PRIVACY-01 support documenting local storage and user control; they do not define a universal retention period or prove a particular app’s cleanup behavior. Keep user-saved results distinct from temporary tensors, thumbnail caches, search indexes, crash diagnostics, and model artifacts. Those classes can have different owners and deletion triggers. Begin with a data-class inventory based on code and storage inspection. For every class record its origin, location, creation event, use, owner, whether the user can see it, and whether it is copied into a database, file, cache, log, backup, export, or derived index. Do not list only database tables: transient files, thumbnails, operation queues, and a result copied into a support package may persist elsewhere. If an item is not implemented, mark it absent for the tested build rather than copying a generic checklist. Define retention triggers instead of guessing a number of days. Possible events include explicit user deletion, completion of a temporary operation, expiration of a draft, sign-out, app reset, or a product-configured purge. The appropriate event depends on the function and user expectation; this guide does not prescribe a legal schedule. State whether saved content remains until the user deletes it, whether incomplete tasks are discarded after a recoverable interval, and how the interface explains the choice. If the policy is not implemented, mark it as unresolved. Map derived data back to its source. A transcript may have summaries, embeddings, thumbnails, language metadata, or a failure record. Deleting the transcript should trigger a test for every derived record that can reveal its content or relationship. A cached model artifact is not the same as user-created content; don't erase it when a user removes one result unless that is an explicit product action. Conversely, don't assume deleting a visible history card removes its source file or backup copy. Test retention with synthetic canaries. Create uniquely identifiable test data, execute normal completion, cancellation, reset, sign-out if relevant, and expiry events, then inspect the app database, files, temporary directories, queues, local index, export folder, and backup/restore path. Search for the canary after each trigger. Also test process death during cleanup and retry so a partial purge is not displayed as complete. Keep device and Android version in the report because platform storage and backup behavior vary. Separate local deletion from remote deletion. If any route transmitted data, an on-device purge cannot erase server-side copies. Record the recipient and deletion mechanism separately and describe only what was verified. Likewise, Android backup or device transfer can restore data if configured to include it. The team should check actual backup rules and restore outcomes rather than inferring retention from app-private storage. An account or analytics identifier may have a different lifecycle from a transcript. Make the product state legible. Users should be able to tell saved content from temporary processing state, know what a reset will remove, and see whether a cache or downloaded model is excluded. Avoid a single “clear data” label if it deletes different classes or can destroy user work. A retention test should verify previews, confirmations, undo where supported, and empty states after cleanup. Do not promise secure erasure beyond what the storage system and implementation demonstrate. The final matrix should name data class, purpose, owner, location, retention trigger, derived copies, backup/export paths, user control, cleanup test, and unresolved limitation. It can say a synthetic canary was absent from the inspected locations after a specified action. It cannot assert a general number of days, complete forensic erasure, legal compliance, or deletion of unobserved server copies. Review after introducing a feature, cache, analytics SDK, or backup change. Retention is a testable lifecycle contract, not a guessed global duration.
A user deletes one local result but keeps the source recording
A user asks to remove a generated summary while keeping the original recording and an unrelated saved note. The application stores temporary processing data and may maintain derived search entries, so the team must identify which records should expire and which should remain.
Decision
Map every data class and derived copy to a retention trigger, then exercise deletion with a synthetic canary and inspect each store.
Expected outcome
The test shows what was removed and preserved without claiming that backups or remote copies were erased.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Data-class inventory
- Retention settings
- Expiry and deletion tests
A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.
Implementation workflow
- Inventory data classes and locations. Trace saved input, generated output, temporary buffers, caches, indexes, logs, queues, exports, and backup scope from implementation, including each owner.
- Assign purposes and retention triggers. For each class name its product purpose, owner, expiry or user action, visible control, and status if no policy is implemented.
- Map derived records to their source. List summaries, thumbnails, embeddings, metadata, and failure records that can reveal or remain linked to the deleted source after the user action.
- Run canary deletion and expiry tests. Create synthetic markers, trigger delete, reset, cancellation, and cleanup retry, then inspect each store and backup path for residual values.
- Review user messaging and exceptions. Check confirmation, preview, empty state, model-cache scope, and any remote deletion path; label unverified forensic or server behavior for each store.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- Every data class has a purpose, owner, storage location, retention trigger, derived-copy list, and user-control state.
- Synthetic canaries are checked in primary and derived stores after each tested trigger, including cleanup interruption and backup scope.
- The page invents no retention duration and makes no secure-erasure, legal-compliance, or unobserved remote-deletion promise.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| User-saved result | Retain until an explicit product or user action | Must remain distinguishable from temporary processing state and derived copies. |
| Temporary inference data | Expire or clear at a documented task boundary | Requires testing cancellation, process death, and cleanup retries. |
| Model or application cache | Manage under a separate cache policy | Deleting cache should not silently remove unrelated user-created content. |
Failure patterns to prevent
- One retention rule for every class
- Leaving derived data after expiry
Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.
Minimum reproducibility record
| Layer | Record |
|---|---|
| Device | Manufacturer, model, chipset, RAM class, operating-system build |
| Software | Application version and git commit |
| Model | Family, variant, revision, format, file length, hash, quantization |
| Runtime | Name, revision, requested backend, observed backend evidence |
| Workload | Fixture revision, input hash, prompt hash, output policy |
| Outcome | Completed, failed, cancelled, fallback, and privacy-safe diagnostics |
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
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
How many days should an offline AI app keep user data?
There is no universal duration in this guide. Define it by data class, product purpose, user expectation, implementation, and applicable review instead of inventing a number.
Does deleting a history card remove every related copy?
Not automatically. Check source files, derived indexes, thumbnails, queues, exports, backups, and any remote recipient with synthetic canaries, including after restart.
Can local deletion erase a copy already sent to a server?
Not by itself. Identify each recipient and test its separate deletion mechanism; report only the copies and outcomes that were verified.