The short answer
Treat deletion as a check across every place the information was copied or derived.
Map source files, extracted text, indexes, conversations and backups before removing information from an AI knowledge workflow.Find the surviving copies
You delete a note, start a fresh session and the agent repeats a detail from it. Where did the detail come from? A surviving summary, an old index, another source or the conversation may still hold it. Removing the file alone cannot answer that question.
List the places the information has traveled. Identify what was stored locally, what was sent to a hosted model and which components created derived copies. Use this method to check your workflow, and consult each provider's terms for how long it keeps data.
Map the places a fact can survive
| Location | Question to resolve |
|---|---|
| Original source | Is the original file still present in another approved folder? |
| Extracted notes and summaries | Did another record preserve the fact or a quotation? |
| Retrieval index | Has the supported update or removal operation completed? |
| Agent conversation | Does an open session already contain the passage? |
| Remote copies and backups | Which sync, Git or backup destinations hold it? |
| Hosted services | What controls and retention terms apply to submitted content? |
Embeddings and search indexes are derived data, not a reason to assume a fact has disappeared. Check the actual implementation and supported removal path. Do not delete internal database files as an improvised cleanup.
Use a harmless marker to test the path
On a disposable test copy, create a fictional fact with a unique marker such as "Moss lantern 47." Retrieve it once, then remove it through the supported workflow. Update derived records and the index as required.
Start a fresh session and search both the exact marker and a paraphrase of its meaning. Inspect returned passages. If it remains, follow the cited source or retrieval record rather than repeatedly asking the model to forget. A successful test covers the inspected path, not every unseen backup or provider system.
Record what was removed and what remains
Removal scope: Synthetic test project
Source: Test note containing the marker
Derived records: List inspected summaries and exports
Index action: Supported refresh/removal, with result
Fresh-session check: Query and returned evidence
Remote copies: Destinations reviewed
Residual copies: Known backups or unresolved provider scope
Owner and review date: Record explicitlyKeep the ledger free of the very sensitive information you are trying to remove. Use a record identifier and scope description. If a backup remains under an established retention policy, record that boundary rather than reporting complete erasure.
Prevent accidental reintroduction
A later sync or restore can bring the source back. Before reconnecting the cleaned workspace, decide which copy is authoritative and check which way sync will copy changes. Document the treatment of historical copies so a restoration does not silently undo the removal.
For future imports, approve a small scope and avoid copying whole archives just because access is available. Less unnecessary ingestion means fewer places to review when a source changes or must be removed.
Check the operating model before choosing a system
You can open Gigabrain's local files to see what they contain. A hosted agent may also receive retrieved passages, so check where those copies go. Review the local-versus-hosted guide.
Use the removal checklist during a small pilot. Check how your agent connects and choose a package only when you understand where your workflow sends information.
Start with the product's deletion plan
Gigabrain's memory deletion-plan command is read-only. It lists the source copy, derived data and affected records. It does not delete them.
The recorded schedule deletion plan reports applied=false and erasure_guaranteed=false. The test also checks that the source remains present after planning.
For a registered project, remove or exclude the approved original before the next sync. Otherwise sync may restore its local copy.
Keep active removal separate from retained history
- Run the deletion plan for the approved source.
- Review the affected records and retained copies.
- Remove the authorized source copy through the documented workflow.
- Run ingestion with the documented prune option.
- Rebuild the relevant index.
- Reconcile the affected graph scope.
- Materialize its readable views.
- Test the exact marker in a new session.
These steps follow the 1.1.0 memory guide. The recorded component checks cover the read-only plan and removal of retired graph support. They do not establish complete source erasure.
The graph ledger can retain earlier references and text. Git history, backups, exports, external originals and provider histories need separate review. Use the removal checklist to record those limits.
Method note: Gigabrain Labs prepared this material with AI assistance. Fictional exercises and executed component checks have separate labels.
