Skip to main content

How version chains work

Every memory has these version-tracking fields:
FieldDescription
isCurrentWhether this is the active version. Only current memories appear in search and list results.
supersedesIdThe ID of the memory this version replaced.
rootIdThe ID of the original memory in the chain.
versionIncrementing version number starting at 1.
When a new memory is classified as an update to an existing one:
  1. A new memory row is inserted with incremented version, supersedesId, and rootId
  2. The old memory is marked isCurrent = false
  3. 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:
  1. v1: “Long LinkedIn posts are performing well right now”
  2. v2: “Short hook-first posts are now outperforming long posts”
Version 2 supersedes version 1. Search returns only v2, but the full history is preserved and accessible via the history endpoint.

Inspecting history

Use GET /api/memories/:id/history to see how a memory evolved:
curl https://api.memcontext.in/api/memories/a1b2c3d4-.../history \
  -H "X-API-Key: mc_your_key"
Response:
{
  "current": {
    "id": "e5f6g7h8-...",
    "content": "Short hook-first posts are now outperforming long posts",
    "version": 2,
    "isCurrent": true,
    "supersedesId": "a1b2c3d4-...",
    "createdAt": "2026-04-10T00:00:00Z"
  },
  "history": [
    {
      "id": "a1b2c3d4-...",
      "content": "Long LinkedIn posts are performing well right now",
      "version": 1,
      "isCurrent": false,
      "createdAt": "2026-03-15T00:00:00Z"
    }
  ]
}

Soft delete vs hard delete

MemContext supports two deletion modes:
MethodEndpointBehavior
Forget (soft delete)POST /api/memories/:id/forgetSets deletedAt — memory is excluded from results but preserved in DB
Delete (hard delete)DELETE /api/memories/:idPermanently removes the memory
Use forget for audit-safe removal. Use delete only when permanent removal is required.