Memory Lifecycle

ZMem treats memory as governed state. Useful facts can be proposed, reviewed, promoted, revoked, restored, and explained instead of silently becoming permanent context.

Daily Commands

zmem status --summary-only
zmem queue
zmem promote <memory-id>
zmem revoke <memory-id>

Project Stores

Most local workflows use a project store:

zmem --db .zerker/memory.sqlite ui

The local console makes memory status visible: proposed, quarantined, active, expired, deprecated, revoked, forgotten, withheld, injected, or budget-dropped.

An explicit expires_at boundary does not silently delete a memory. Memory Maintenance can move one eligible active memory to the non-cascading expired state and produce a mutation receipt.

A private consolidation summary can be discarded only before admission. Once admitted, it is canonical memory with source parents and a write receipt; remove it through the normal zmem revoke <memory-id> lifecycle so descendants and history remain visible.

Snapshots

Export a portable memory-state snapshot:

zmem snapshot --out-dir .zerker/exports
zmem snapshot verify .zerker/exports/<snapshot>.snapshot.json

Restore into a new empty store:

zmem --db .zerker/restored.sqlite restore .zerker/exports/<snapshot>.snapshot.json

Product Principle

Memory should be easy for agents to use and hard to smuggle into trust. Status, provenance, and revocation need to be first-class product surfaces.