Governance for OpenClaw-style Markdown memory — without changing how you search it
OpenClaw-style runtimes search Markdown memory with memory_search and read it with memory_get. Heartwood Memory backs the same two calls — and filters every result through policy before it's ranked, signs every record, and emits a key-destruction proof on erasure.
Markdown memory is readable by humans — and by every agent, with no rules
An OpenClaw-style runtime keeps memory as Markdown and searches it with a hybrid of vector similarity and keyword match. It's transparent and easy to reason about. But “easy to read” cuts both ways:
- Every search sees everything. memory_search ranks across the whole store. There's no tenant partition, no clearance, no rule that stops one agent's query from surfacing another's data.
- No record of origin. A Markdown line doesn't carry a signature. You can't tell an authentic memory from one an attacker or a hallucination wrote into the file.
- Delete ≠ gone. Remove a line from the Markdown and the derived embedding that encoded it still lives in the index. You have no auditable proof of what was erased.
Same memory_search and memory_get — policy-filtered, signed, erasable
Heartwood Memory ships an OpenClaw-style runtime example contract: memory_search and memory_get over Heartwood-backed memories. Missing files degrade gracefully, path traversal is blocked, and — the part the local runtime can't do — recall is policy-filtered before ranking.
Tenant boundary enforced before ranking, not after.
Policy gates the candidate set first, so a similarity hit can never cross a tenant — and denials are constant-shape, so a blocked record is invisible by count, score, or latency.
Every record is signed and re-verified at read.
Ed25519 provenance binds each memory to its producer; verification is fail-closed. A line cannot impersonate a higher trust level than it was signed for.
Erasure leaves a proof.
forget(hard) shreds the per-subject key and purges derived embeddings down the deletion lineage; the erasure event is retained in a hash-chained, tamper-evident audit log. This is a per-subject key-destruction proof, not a claim of instant or whole-content deletion — full key destruction completes within ≤72h on dedicated-vault plans, or up to 90 days on shared-vault plans.
In an ungoverned Markdown + SQLite store, the only thing stopping Agent A's memory_search from returning Agent B's memories is that you remembered to filter — in application code, every time. Heartwood enforces the tenant partition inside the recall path, on the candidate set, before anything is ranked or returned. The boundary isn't a convention you maintain; it's a gate the store enforces.
Is this an official OpenClaw integration? No. Heartwood's OpenClaw-style runtime is an example contract that matches the common Markdown-memory shape — not a verified or official integration with any specific public framework.
Keep your Markdown memory. Govern what's underneath it.
Questions
What is an OpenClaw-style agent memory runtime?
An OpenClaw-style agent memory runtime stores memory as human-readable Markdown and retrieves it through two calls — memory_search (hybrid vector + keyword search) and memory_get (fetch a file). It optimizes for transparency and simplicity; it does not enforce tenant isolation, provenance, or auditable erasure on its own.
Can I add governance to OpenClaw-style memory without changing my search code?
Yes. Heartwood Memory backs the same memory_search and memory_get calls while filtering recall through policy before ranking, signing every record, and emitting a key-destruction proof on erasure. Your retrieval surface stays the same; the store underneath becomes governed.
How does Heartwood isolate memory between tenants?
Heartwood enforces a hard tenant partition inside the retrieval path: policy filters the candidate set before similarity ranking, so a search hit can never cross a tenant boundary, and denials are constant-shape — a blocked record cannot be detected through result count, score, or latency. Isolation is enforced by the store, not by application-code discipline.
Is Heartwood a verified OpenClaw integration?
No. Heartwood ships an OpenClaw-style runtime example contract matching the common Markdown-memory shape. It is not a verified or official integration with any specific public framework.
What happens to derived embeddings when I delete a memory?
In Heartwood, a hard erasure crypto-shreds the per-subject key and physically purges derived artifacts — embeddings and postings — through the deletion lineage, because an embedding is a recoverable encoding of its source text. The erasure event itself is retained in the audit log. This follows recognized crypto-shredding practice — destroying the key that decrypts the data, alongside physically purging the derived artifacts. Whether crypto-shredding satisfies a specific erasure obligation depends on your circumstances and is a question for your counsel.