An AI assistant learns something from a source note. Later, you ask it to forget that note. The stored conclusion may still carry the information into the next decision.
That is why a useful deletion workflow follows the relationships around a record. It asks which contributions can be removed, which later records need review and what evidence should remain about the change.
8DB, our omnimodal database, includes braid primitives for one part of that work: inspecting interactions in an encoded history and removing a contribution when the supported independence condition holds. The opportunity is to give applications a deletion decision they can explain, with the affected structure and evidence connected.
Check the relationship before changing the history
A braid represents an ordered history of interactions between strands. An application defines what those strands and interactions mean. The structure can then expose a relationship that a delete command on one record would leave for the application to investigate separately.
The implemented removal operation checks a target crossing against later crossings. If the target is isolated under the supported rule, the operation returns a new mathematical state with that contribution removed and an algebraic certificate. If a later crossing shares a strand with it, the simple removal path refuses and returns the conflicting positions for review.
That distinction gives the application a useful choice: proceed with an admitted structural change or inspect the relationship that prevents it. The check operates on the encoded crossings. Finding every real-world consequence of a record still depends on how completely the application represents those relationships.
Illustrative braid history · two events, four strands
One relationship changes the removal decision
The target event joins strands A and B. Change which strands the later event touches.
The later event uses C and D. In this declared example, the target qualifies for removal from the mathematical state, with an algebraic certificate.
Read both outcomes without changing the diagram
A–B followed by C–D: the target meets the independence rule. A–B followed by B–C: the shared strand prevents the simple removal. Lines show strand participation; vertical position shows event order.
Apply the idea to agent memory
Consider a source note and a conclusion derived from it. If the application records that dependency, a request to remove the note can also trigger review of the conclusion. The reviewer can ask whether another source supports it, whether it should be recomputed, or whether it should be removed from use.
The braid primitive supplies a structural operation within this proposed workflow. It does not, by itself, perform that whole application review or remove information from trained model weights. The practical design goal is to connect the removal request to the decisions it affects, instead of leaving each subsystem to interpret “deleted” separately.
This complements 8DB's approach to controlled agent memory: applications need a deliberate rule for both what may be recalled and what should happen when its supporting information changes.
Keep evidence of the change
A separate signed erasure statement can identify the subject and the before and after fingerprints without carrying the original content. That gives a reviewer something concrete to check after the operation.
Checking a signed statement requires both signature verification and statement-binding verification. Those checks authenticate the recorded assertion. Validating the actual state change requires the corresponding transition evidence. The standalone algebraic certificate does not independently reconstruct the original history and prove its before/after relationship.
A useful review therefore connects three things: the admitted operation, evidence of the resulting state and the signed account of what changed. Keeping a record of a deletion need not require keeping the deleted payload in that record. Identifiers and retained evidence still need their own access and retention rules.
Give each deletion guarantee its own evidence
| Question | Evidence the workflow needs |
|---|---|
| Can the record still be retrieved? | Checks of the declared query and access paths. |
| Was its represented contribution removed? | The permitted transformation and evidence about the remaining structure. |
| Can the protected content still be decrypted? | Checks of the required key paths under the declared threat model. |
| Have storage media been sanitized? | Evidence for the relevant media and sanitization procedure. |
| Are the covered replicas and exports accounted for? | A declared copy inventory and completion evidence for those locations. |
NIST's media-sanitization guidance addresses making access to target data on media infeasible under a specified level of effort. That is a separate contract from removing a contribution from a mathematical state. A deployment can need both, along with checks for keys and copies.
This separation helps a team select the right evidence for the promise it makes. A structural certificate can support its declared change; a signature alone cannot establish completion across unknown copies.
Start with one deletion your team needs to explain
The value of a native braid modality is the operation its structure makes available. For deletion, that means an explicit independence check, an admitted transformation and evidence that can become part of a wider application workflow.
Which part is hardest for your team to establish: removed content, affected conclusions or completed copy cleanup? Bring one non-sensitive example and the guarantee you need. We can map the represented dependencies, the supported primitive and the remaining storage or key-management checks.
Discuss an erasure workflow with Ashley.
For the underlying idea of ordered interactions, read When the Order Changes the Answer.
Scope: this article describes source-reviewed primitives and an illustrative application. The supported structural removal covers admitted isolated-crossing cases. A complete application deletion workflow must connect and verify its own storage, key, dependency and replica handling.
Evidence scope Source-reviewed braid primitives · Illustrative application workflow. Explore the evidence.
Continue the technical conversation
Where could this help your work?
Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.
Discuss this work