Why we wrote an open format for AI memory

Every AI product now promises "memory." What it usually ships is a row in someone else's database, reachable only through their API, shaped by their retrieval code, and gone the day you leave. You can read it back through the product that produced it, and nowhere else. You cannot open it, diff it, verify who wrote it, or move it to another tool. Memory in that form is not something you own — it is something you rent, and the lease terminates with the account.

We think portable memory needs a file, not an API. A file can be copied, signed, inspected with tools its author never anticipated, and read a decade later with no server running. So instead of another memory service, we wrote a format: .laplaspack, an MIT-licensed open specification for a self-contained memory container built on a plain SQLite database. This post walks through the design and is equally explicit about the parts that are still draft or client-only.

A pack is a SQLite file, and the source is the truth

A .laplaspack is one SQLite database that any SQLite client can open read-only. That choice matters: no bespoke parser, no network dependency, no proprietary runtime stands between you and your memory. The spec (currently v3 draft) divides the tables into three tiers, and the division is the whole idea.

The canonical tables are the only ones that carry truth: lmd_source (the human-authored source text), commits (build provenance), and manifest (pack metadata). The derived tables — entities, edges, thinks, schema_types — are projections of the source. A conformant reader must tolerate their absence and reconstruct them from lmd_source alone. On top of those sit optional acceleration tables (FTS, sparse postings, embeddings) that are recall aids and never authoritative; a pack with none of them is still fully valid.

The source is canonical; the index is derived. Every queryable table is a rebuildable projection of the human-authored text — which is what makes a third party able to adopt the format with only the source and this spec.

Six causal roles, and provenance that isn't decorative

An entity carries a stable opaque id (a lp_-prefixed ULID, authored into the source as >>id:), a display label, a type, and its properties as fields_json. Properties are adjectival facts — >>key: value — not a prose blob. What most memory formats lack is the layer above facts: the reasoning.

Edges are partitioned by kind. subject edges are associations and containment. knowing edges form the reasoning DAG, and their role is one of exactly six canonical causal roles: derived-from, supports, raises, closes, supersedes, contradicts. These are what a --why walk traverses to reconstruct the recorded chain behind a claim — not a similarity ranking done after the fact, but the ancestry the author actually wrote down.

Every derived row is stamped with the commit_sha that produced it. Provenance answers "when, and from which source revision, did this fact enter the pack" — which is exactly the question a rented memory service cannot answer for you.

Fold-on-read: history is kept, the reader computes the present

A think is a typed, dated human thought attached to an entity — one of question, decision, todo, hypothesis, insight, note. Think rows are stored raw: every authored version, including tombstones. Current state is computed at read time by Last-Writer-Wins on (host, think_id), newest wins, tombstones remove. The pack keeps the full history; the reader folds it. A pleasant consequence is that concurrent think histories converge on read, so thinks are CRDT-free by construction when two packs are combined.

LMD: the human-readable source that compiles to a pack

The canonical lmd_source is LMD (Laplas Markdown), a small Markdown-compatible grammar. A ## Heading plus [[Heading]] declares an entity; >>key: value sets a property; >>derived-from: [[X]] or [[A]] →(supersedes) [[B]] declares an edge; a @@decision … @@ block is a think. The .md file and the pack built from it are two views of the same memory, and either rebuilds from the other. That round-trip invariant is the freshness gate: a pack is stale iff manifest.head_sha no longer matches the hash of its lmd_source.

What this is — and what it is not yet

To be precise about the state of things: this is a v3 draft spec, authored by one person and published in the open under MIT. It is not an industry standard, not blessed by any standards body, and has no third-party implementations that we can point to. Field names and conformance levels may still move.

The reference tools are honest about their split. The reader, writer, and merge tools are Python stdlib-only. The one exception is the seal tool: Ed25519 signing requires pip install cryptography, because Python's standard library has no Ed25519. A sealed pack lets anyone verify offline who sealed it and that the content is untampered; an unsigned pack is valid but unattributed.

Three pieces are spec-ahead-of-tools, and we would rather say so than imply otherwise:

• Redaction (SPEC §3.8) — the open/masked/secret visibility tiers are specified, but a reference redact tool does not exist; redaction currently ships only in the desktop client's export path.
• The Hub / laplas:// registry — publish, fetch, grant, and mount semantics are drafted in HUB.md, not reference-implemented.
• Class-3 semantic merge — the deterministic, zero-model merge of packs that share an authored stable_id is implemented; merging entities that are the same thing but were never declared so needs a model pass and is an open question, out of scope for the reference tools.

The retrieval claims behind this design live in a preprint draft — not peer-reviewed, not yet posted to arXiv. On one synthetic relational-query corpus, both vector RAG and our own ranked retrieval score find@1 = 0.00 on a relational-state task, while the structured match operator returns the exact set at F1 = 1.00. That result is self-reported; external baselines like GraphRAG and SQL-RAG are not yet run, and the paper lists this as a limitation.

So this is not a finished standard or a proven system. It is an open, MIT-licensed specification for a memory container you can hold in your hand, plus stdlib reference tools to read and write it. If the industry is going to build on portable memory, the substrate should be a file anyone can open — and that file should be specified in the open. That is what we wrote.