Most systems that give a language model long-term memory share one shape: take a corpus of prose, index it, and impose structure at query time. Dense RAG embeds every chunk and re-ranks by similarity. GraphRAG runs LLM passes over the whole corpus to extract entities and relations. Text-to-SQL presumes a schema someone modeled by hand. In each case the structure is reconstructed after the fact, by a process that did not witness the knowledge being formed. We have been drafting a preprint that argues for the opposite placement — structure the memory at write time — and this post is an honest account of the thesis and, just as importantly, of what we have and have not shown.
The thesis: structure-at-creation
The core claim is that the two costs of retrieval-time structure — an expensive construction step and a non-navigable, passage-shaped interface — are artifacts of structure-by-extraction. For knowledge an agent produces (decisions, findings, the reasoning behind them) there is no unstructured original to extract from unless you first discard the structure and then pay to guess it back. So the agent records knowledge as a typed graph the moment it is written.
The write format is LMD (LAPLAS Markdown), a Markdown-compatible notation we formalized as an EBNF grammar. A plain reader still sees headings and text; an LMD reader additionally recognizes typed nodes ([[* slug]]), adjectival property-fields (>>key: value), and edges — the load-bearing part. Edges split into two layers: flat, atemporal @subject facts, and a temporal @knowing reasoning DAG carrying six causal roles — derived-from, supports, raises, closes, supersedes, contradicts. That separation is what makes "why did we conclude X?" a graph traversal rather than a similarity search. The compiled artifact is a single SQLite file — one .laplaspack — holding entities, edges, thinks, commit provenance, and the canonical source text, so either form can always be rebuilt from the other. We authored an open, MIT-licensed spec for it (currently a v3 draft, authored by one person and published in the open); the reference reader, writer, and merge tools are Python stdlib only. The one tool that isn't is the seal — Ed25519 signing needs pip install cryptography, because the standard library has no Ed25519.
The result we can report — and exactly what it is
The sharpest prediction the framing makes is that some queries are not expressible as a ranking at all. "Which questions are still open in project P?" is relational state, not text: two questions in a project can be lexical twins separated only by a closes edge. No scoring function over surface text distinguishes them. On a synthetic corpus generated through the real authoring pipeline (60 projects, 620 entities, single seed, author-planted gold), the numbers are:
- open-question (relational state): a standard dense Vector RAG baseline scores
find@1 = 0.00; our own ranked retrieval also scores0.00across all three modes; the typedmatchoperator returns the exact set,F1 = 1.00. - causal "why" path: a ranker reaches 0.91 ancestor recall by textual proximity but only 0.23 ordered-path accuracy, while upstream traversal returns the planted chain (1.00).
Read that carefully. The find@1 = 0.00 holds for the external baseline and for our own retriever, which is the point: the failure is the paradigm, not a weak competitor we hobbled. And where a ranker is genuinely competent, we report it — entity recall 0.83 for the baseline, and fuzzy paraphrase recall 0.75, squarely the dense retriever's turf. The relational gap is not a claim that structure beats ranking on average. The preprint frames it as an expressivity result: a state-filtered or text-to-SQL retriever could in principle also answer the open-question query, and that comparison is deferred.
The caveat, stated plainly
This is the part that matters most, and it is why the post exists.
Thefind@1 = 0.00vsF1 = 1.00result is self-reported, on one relational-query corpus, against one external baseline. It is a single run on a synthetic (author-planted) corpus, not a multi-seed average and not a real-world dataset.
Concretely, the limitations we list in the draft itself:
- External baselines are incomplete. We ran one — B1, Vector RAG. GraphRAG (B2) and SQL-RAG (B3) are in progress, not run. The multi-hop comparison is therefore not yet decided, and the paper says so. A separation against Vector RAG is not a separation against every extraction pipeline.
- One corpus, synthetic, single seed. The lexical-twin questions are deliberately constructed to be the worst case for a ranker. That makes the result a clean existence demonstration and a poor basis for any average-case or cross-domain claim.
- It is a preprint draft, not peer-reviewed, and not yet on arXiv. The submission package is prepared; it has not been posted. Nothing here has been through external review.
- The construction-cost advantage is conditional. "No LLM extraction pass" holds in authoring settings, where the agent writes LMD directly. On a pre-existing unstructured corpus, LMD itself needs an extraction pass — the write-time projection cost is real, just paid upstream.
- Parts of the spec are ahead of the tools. Redaction / partial views (SPEC 3.8) ships only in the desktop client's export path; there is no reference
redacttool yet. Thelaplas://hub addressing is a draft. Class-3 semantic (undeclared-identity) merge is an open question — only the declared-identity merge is implemented inlaplaspack_merge.py.
One more framing caveat, because it is easy to overstate. This is one construction that answers a class of queries a ranker structurally cannot. It is not a proof that write-time structure is generally superior to retrieval-time structure. "Optimal" in the theory always means "under the stated assumptions" — a fixed query class, a fixed engine, a specific cost model — never unconditionally. Where a query falls outside that closed fragment (open-ended, generative, genuinely novel), a model-at-read-time path is still the right call, and the theory says as much.
What this is, and what it isn't yet
What it is: an open, MIT-licensed format for portable AI memory; a formalized write-time grammar; stdlib reference tools you can run offline; and a preprint draft with one honest, reproducible measurement showing that a relational-state query is not expressible as a ranking, answered exactly by a typed operator on the same corpus.
What it isn't yet: peer-reviewed, posted to arXiv, tested against GraphRAG or SQL-RAG, or validated on more than one synthetic corpus. It is not an industry standard, and it has no adopters we can point to — it is a v3 draft, authored by one person, published so that others can read it, poke at it, and build independent implementations. The next step is unglamorous and specific: run B2 and B3, add a multi-domain sweep, and let the separation stand or fall against a real baseline on a real corpus.