Direct answer
Deletion in a local AI application is a contract over a data inventory, not a button label. Before implementing “delete,” list the original input and every derivative that can remain: transcript, generated summary, embedding or vector row, search index, thumbnail, temporary tensor or cache, export, model reference, logs, and operating-system backup. `RAG-01` describes a local retrieval pipeline as several independent stages from ingestion through generation, which means deleting only the visible document row can leave derived records behind. `PRIVACY-01` also prevents the mistaken leap from local inference to a claim that no other data path exists. State which copies the app controls and what happens to copies managed by a user export or platform backup. Model deletion and user-content deletion are separate operations. Removing an app-owned model artifact should not silently erase a user's notes or history, and deleting a conversation should not remove a shared model file needed by another feature. Conversely, deleting a source document while keeping searchable vectors or snippets may leave sensitive meaning accessible. Design separate user-visible actions with clear scope, consequence, and confirmation where the result is irreversible. A “hide” or archive action is not deletion; neither is clearing a screen while retaining its Room row or embedding. Build a source-to-derivative graph. Each edge should name the component that creates the derivative, its storage location, stable linkage key, deletion trigger, and whether it is included in backup or export. Include partial writes and failure states: a worker may have stored a transcript before the parent operation is marked complete. An index may be rebuilt from a source later, so deleting only the current vector row may not be durable if a queue or sync task recreates it. A cleanup transaction should be idempotent and safe to retry; it should report partial completion rather than claiming success when one owned store failed. Android backup requires separate treatment. Auto Backup can include most app data by default, and Android 12+ data-extraction rules distinguish cloud backup and device transfer. Do not claim that deleting an app database deletes a backup already held by an OS-managed service, nor claim that an artifact is excluded without checking the actual rules and test configuration. Explain whether app deletion covers local state only, asks the platform to remove backup data under its documented behavior, or requires another explicit action. Avoid promises of forensic erasure: ordinary application deletion semantics do not prove every storage block or external copy has been physically overwritten. Test deletion with labeled synthetic records, not personal user data. Create one source item and known derivatives in each store; run delete, close/reopen the app, search, export, trigger workers, recreate an index if supported, and perform a backup/restore test in the configured environment. Verify both positive and negative results: the user-facing record is gone, derivatives are not returned, unrelated model assets and user records remain, and a failed store produces an honest partial/error state. Inspect logs and notification content for snippets. Repeat after schema, embedding, cache, or backup-rule changes. The interface should describe the actual scope: “remove this local conversation and its derived search entries” is more useful than a vague “erase everything” promise. Present remaining boundaries such as copies the user exported or platform-managed backup, but only where the behavior is confirmed. Maintain a deletion matrix reviewed alongside the data map. This evidence supports an honest, narrow user promise while avoiding unsupported claims about absolute erasure or privacy beyond the application-controlled stores.
Deleting a document must also remove searchable derivatives
A user imports a private document, asks questions about it, and later removes it from the library. The app stores an original file, extracted chunks, local embeddings, and cached answer snippets in different components.
Decision
Use a source-linked deletion operation that enumerates each owned derivative and reports completion per store; keep model artifact removal as a separate action.
Expected outcome
After deletion, reopening and searching does not return the document or its derivatives, while unrelated conversation history and shared model assets remain intact.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Data inventory
- Deletion cascade test
- Backup disclosure
A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.
Implementation workflow
- Inventory sources and derivatives. Trace originals, parsed text, summaries, vectors, index rows, thumbnails, caches, temporary files, exports, logs, and backup rules. Name each storage owner and the identifiers connecting derivative to source.
- Specify separate deletion scopes. Define actions for a source item, conversation, derived index, model artifact, and full app data separately. Explain confirmation, reversibility, and what each action intentionally leaves untouched.
- Make cleanup idempotent and observable. Delete dependent records in a retry-safe order. Handle workers and index rebuilds so they cannot recreate deleted content, and return partial failure if any app-owned store cannot confirm completion.
- Test reopen, search, export, and restore. Use synthetic labeled records, run deletion, restart the process, query indexes, create an export, allow pending workers to run, and perform a configured backup/restore test. Check that unrelated data survives.
- Update copy when storage changes. After adding a derivative, cache, export route, or backup rule, update the data map, deletion matrix, user-facing wording, and regression fixtures before release.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- Every app-owned derivative has a source linkage and deletion behavior, including pending worker and index-rebuild paths.
- Synthetic tests show deleted records and derivatives are absent after reopening and search, while unrelated user data and shared model assets remain.
- Product copy distinguishes app-controlled deletion from user exports and platform backup, and makes no physical-erasure guarantee unsupported by evidence.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Hide or archive | Remove from the current screen | Improves visibility control but may retain source and derivatives. |
| Delete a source item | Cascade through linked app-owned derivatives | Requires an inventory, stable linkage, worker coordination, and verification. |
| Delete model artifact | Remove a shared inference dependency | A separate action; it should not silently erase user conversations or exports. |
Failure patterns to prevent
- Hiding records only
- Leaving embeddings behind
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
Does removing a document row delete its embeddings?
Only if the implementation links that row to every derived index entry and executes the cleanup. Test reopening and searching after deletion instead of assuming a cascade.
Does app deletion prove all backups are gone?
No. Android backup behavior is separately configured and platform-managed. Verify the app rules and explain the boundary without claiming control over every external copy.
Can an app promise secure physical erasure?
Not from an ordinary database delete alone. Avoid claims about overwriting all storage blocks or removing user-exported copies unless the exact behavior is independently established.