Estratos

Version history and rollback

Every memory in Estratos is versioned, so no change is ever silently lost and you can always see how a memory got to where it is.

A new version on every save

Each memory is append-only under the hood. Saving writes a new version, recording its change type and author. The current version is what retrieval returns; the older versions stay in the memory's history.

Compare and roll back

Open a memory's version history to see its versions listed newest-first. From there you can:

  • Compare any earlier version against the current one as a line diff, so you can see exactly what changed.
  • Roll back to an earlier version. Rollback doesn't erase anything — it writes that earlier content forward as a new version, so the full trail is preserved and you could roll back again.

Version history and rollback are available on both the scoped and tagged editors (Memories › Scoped and Memories › Tagged). Over MCP, rollback is a web action — the memory tools cover reading and writing, not history navigation.

Soft deletes keep the history

Deleting a memory writes a tombstone version rather than hard-deleting the row. The memory drops out of retrieval and listings, but its version history is preserved. This means a delete is auditable and the record of what once existed isn't destroyed.

For a Basic user, a delete goes through review as a delete proposal, exactly like a create or edit.

What's recorded

Because versions carry their author and change type, and because the audit log records creates, updates, deletes, and rollbacks, you have a complete picture of how any memory evolved — who changed it, when, and how. Memory content itself is never written to the audit log; the version history is where the content of each revision lives.

Next steps