Skip to content
Palimem Docsspec v1.7.0

Why governed memory

Most agent memory products optimize recall: store everything, embed it, return the top k chunks that look relevant. That works until facts change. The old deploy target and the new one both rank highly. The agent has to guess which is current — or worse, cites the wrong one with confidence.

Governed memory optimizes correct current state. When a fact changes, the new value supersedes the old one at write time. Recall returns what the system believes now, scoped to the right context, with a trail when you need to prove what changed.

Governed state vs recall@k

Section titled “Governed state vs recall@k”
Approach What it optimizes What goes wrong
Recall@k (RAG-style) Surface the k most similar chunks Contradicting facts coexist; ranking picks a winner at read time
Governed memory One current value per subject key Requires structured writes and supersession semantics

Palimem is in the second category. It does not claim benchmark leaderboard scores on LongMemEval or similar suites. It claims that when you write auth.provider = OAuth2 after auth.provider = SAML, search and memory_get return OAuth2 — not both, not whichever embedded closer.

Three pillars

Section titled “Three pillars”

Supersession

Section titled “Supersession”

Updates resolve at write time, not recall time. Conflicting values for the same subject key (scope + namespace + topic + field + memory type) form a supersession chain. Only the top of the chain is active for agent recall. History stays in the immutable write-ahead log.

See Palimpsest model and Supersession & audit for the mechanics.

Scopes

Section titled “Scopes”

Memory is partitioned by user, session, and repository scope. A session scratch note does not bleed into repository facts. A user preference does not overwrite a team decision. Scoped recall is a correctness feature, not just a filter.

See Scopes.

Audit export

Section titled “Audit export”

Because every write appends to an immutable log, you can ask what was true at a point in time (as_of), trace a belief trajectory (memory_query_temporal), or export the full WAL for compliance (memory_audit_export). Audit is built in — not bolted on after the fact.

Where Palimem sits in the market

Section titled “Where Palimem sits in the market”

Local MCP memory servers for coding agents are a growing category. Products differ on install ergonomics, hook injection, fleet coordination, and cloud vs on-disk storage. Palimem’s public proof points are concrete and verifiable:

  • Spec v1.7.0 — normative behavior for 11 MCP tools and 11 harness integrations
  • 143 automated validation behaviors — black-box tests against the published spec
  • Local-first — SQLite on your disk; no mandatory cloud account
  • Governance — supersession, scopes, retention, PII scan, legal hold, audit export

We do not ship cloud-hosted fleet coordination or claim state-of-the-art on public memory benchmarks. We ship a spec-driven server you can run, test, and audit yourself.

What Palimem is not

Section titled “What Palimem is not”
  • Not a vector database — lexical search by default; embeddings optional
  • Not a project wiki — see Palimem and OKF for how governed runtime memory complements curated knowledge bundles
  • Not AGENTS.md — repo instructions tell the agent how to work here; Palimem tells the agent what to believe now across sessions

Next steps

Section titled “Next steps”