Persistence¶

What is stored, how edits behave, and what you are responsible for.

What Venkai persists¶

For every memory: its content, type, importance, confidence, metadata, author (agent_key), project, organization, timestamps, and the version history of its edits. Everything needed to rank it is computed and stored when it is written, so a memory is retrievable as soon as the write returns.

Edits¶

A PATCH that changes content takes effect for retrieval immediately — an edited memory is matched on its new text, never its old one.
A PATCH that only changes metadata keeps the content as is.
Every edit records a version entry.

Versioning¶

curl -s https://api.venkai.fr/api/context/ctx_cc55e4a7bbc5/versions \
  -H "Authorization: Bearer $VENKAI_API_KEY"

{"context_id": "ctx_cc55e4a7bbc5", "versions": [ ... ], "count": 1}

Restore:

curl -sX POST https://api.venkai.fr/api/context/ctx_cc55e4a7bbc5/restore \
  -H "Authorization: Bearer $VENKAI_API_KEY" \
  -H 'Content-Type: application/json' -d '{"version": 1}'

A restore creates a new version entry rather than rewinding history, so the trail is append-only.

Durability and data handling¶

Aspect	Behaviour
Isolation	Every memory belongs to exactly one organization and is only reachable with that organization's credentials
Retention / TTL	None. Memories persist until edited or the organization is deleted
Ageing	Handled by ranking (recency), never by deletion
Bulk export	`GET /api/export`
Bulk delete	`DELETE /api/organization` — removes the organization and its data
Single-memory delete	Not available. Supersede with a `PATCH`

Keep your own export

GET /api/export returns your organization's data. Schedule it if your compliance posture requires an independent copy.