How version chains work
Every memory has these version-tracking fields:| Field | Description |
|---|---|
isCurrent | Whether this is the active version. Only current memories appear in search and list results. |
supersedesId | The ID of the memory this version replaced. |
rootId | The ID of the original memory in the chain. |
version | Incrementing version number starting at 1. |
update to an existing one:
- A new memory row is inserted with incremented
version,supersedesId, androotId - The old memory is marked
isCurrent = false - The old memory remains in the database — nothing is deleted
Why this matters
This is what makes evolving memory possible without losing context. For example, a content strategy might evolve:- v1: “Long LinkedIn posts are performing well right now”
- v2: “Short hook-first posts are now outperforming long posts”
Inspecting history
UseGET /api/memories/:id/history to see how a memory evolved:
Soft delete vs hard delete
MemContext supports two deletion modes:| Method | Endpoint | Behavior |
|---|---|---|
| Forget (soft delete) | POST /api/memories/:id/forget | Sets deletedAt — memory is excluded from results but preserved in DB |
| Delete (hard delete) | DELETE /api/memories/:id | Permanently removes the memory |
