Why LAPLAS

AI memory, as shipped today, fails in four specific ways. Recall is opaque: a 1536-dimensional float vector cannot be read, so "what does it remember about me" can only be probed with queries, never inspected. The representation is not yours: it lives in a vendor's store, fused into one assistant, with no local file and no version history. It carries no causal structure: cosine similarity captures that two notes are related, not that decision B contradicts decision A, or that blocker X was closed by commit Y. And there is no correction loop: the LLM extraction step is lossy and drift-prone, every memory is treated as equally trustworthy, and editing is a mediated UPDATE/DELETE with no diff and no audit. LAPLAS fixes all four at the substrate level rather than patching them at the retrieval layer.

Design principles

Five properties, chosen first and then built down to:

• 01Readable. The source of truth is human-readable Markdown you can open in any editor — not an embedding you reverse-engineer.
• 02Ownable. One memory space is one git repository on your disk. No account is required to read it.
• 03Correctable. A human hand-edit always outranks an AI-written stream, deterministically, by construction.
• 04Portable. A whole mind exports to a single SQLite file that round-trips losslessly back into a working graph.
• 05Verifiable. Every export is sealed with an Ed25519 signature anyone can check offline, with no server in the loop.

The rest of this report is how the architecture earns each one — and a candid section on the places it does not earn them yet.

Git as the database

The central decision: one memory space is one git repository, and every memory write is a commit. When the engine records a thought, it stages the changed files, writes a tree, and creates a commit through pygit2. The commit message body is the LMD that was written; nothing is stored in a side channel.

Choosing git as the substrate means a long list of hard problems are already solved — for free, by forty years of version-control engineering rather than by us:

• ·History & time-travel. The engine can re-render the entire graph as it existed N commits ago by walking the git tree object — read-only, no checkout required.
• ·Authorship & blame. Each commit carries author name, email, time, and parents; per-entity provenance is reconstructed by re-parsing commit bodies.
• ·Diff & branch. What changed, when, and in what order is a native property, not a feature we maintain.
• ·Sync. Remote push/pull shells out to your installed git, deliberately reusing your existing SSH/HTTPS credentials — no token in a URL, no bespoke auth.

The format on top of git is LMD — LAPLAS Markdown. It is ordinary Markdown with three additions: [[double brackets]] mark an entity, >>field: value attaches a structured fact to the most recent entity, and a causal role turns a note into a graph edge.

# switched the pack format to sqlite

[[laplaspack]] >>format: single sqlite file
[[laplaspack]] >>seal: ed25519
[[laplaspack]] >>status: shipping

That is the whole capture surface. You write notes; the brackets and roles are enough for the engine to assemble a graph underneath — entities connected by why, not only by keyword.

Two layers: facts and thinking

A mind holds two kinds of content, and LAPLAS keeps them physically separate. The subject layer is what's true — people, projects, tools, documents and their fields. The knowing layer is the cognitive work — questions, hypotheses, decisions, insights, blockers, patterns. Every entity type is routed to one layer or the other at parse time.

The split is structural, not cosmetic. When the graph is indexed, the six causal roles are routed into a separate parent/child store — the reasoning DAG — while every other edge goes into a flat neighbour store, the subject graph. The six roles are fixed:

derived-from   B came out of A
supports       evidence A strengthens claim B
raises         work A surfaces open question B
closes         result A resolves question B
supersedes     decision B replaces decision A
contradicts    A and B cannot both hold   (symmetric)

Because direction is encoded per role, "the why of X" is a concrete graph traversal — walk the parents of X, cycle-guarded — not a label slapped on a note. This is the strongest honest claim against the embedding stores: a contradicts edge here is author-declared at write time, so it cannot hallucinate the way an inferred similarity edge can — nothing inferred it. A vector store can tell you two decisions are related; it cannot tell you one overruled the other unless a model guessed so.

A graph beats a vector blob for reasoning because the answer to "why" is a path, and a path is something you can read.

Getting capture right

A memory the AI writes is only as good as what it chooses to write, so most of the engineering lives in the capture gate, not retrieval. Four mechanisms.

Recency fold. Each >>field is stamped with its block's timestamp. When the same field is set twice, the value with the latest timestamp wins; ties fall back to document order.

Override layer — the human hand wins. Documents are ranked: a canonical seed below AI thought-streams below an explicit override file. The override file is merged last, so it wins. Concretely: a human hand-edit always outranks an AI inbox stream. This is the literal correction loop the embedding stores lack — not an LLM-mediated UPDATE, but a deterministic precedence rule.

ATTACH enforcement & resolve-first. A new piece of thinking with no endeavour and no canonical attach role is hard-rejected at commit time — a floating thought that connects to nothing is refused, not silently filed. Before writing a person or concept, a resolve step returns [exact] / [similar] / [new], with Hangul-to-roman transliteration so 안예준 and Yejun collide rather than forking into two nodes. A close match without an explicit confirm_new is rejected.

The parse receipt. Every commit echoes exactly what was recorded — the sha, the space, the entity, field and edge counts, and each role-to-target edge — computed from the structured arguments, so it is exact rather than best-effort. The AI sees what it actually wrote.

And the number we refuse to hide. We built an eval harness, graded our own capture on a five-dimension rubric where all five must hold — type, attach, label, worth, fields — and measured a precision of:

38.9%

Seven of eighteen cases passed. The dominant failures were exactly the two the ATTACH gate and the type guidance above were built to fix. This is a baseline on one vault graded by one judge, not a headline score: 90% is the gate we set before we let this scale, and below 80% after three months is the kill criterion. We are not claiming a number we have not earned. The full story is its own track: we measured ourselves at 38.9%.

Provenance you can verify

Your identity is a local Ed25519 keypair; the public key is your LAPLAS ID. Every exported pack is sealed automatically: the engine computes a content digest over the sorted LMD shards — independent of the SQLite byte layout — and signs it. Verification recomputes the digest and checks the signature with pure cryptographic math. No network, no account, no phone-home. A tampered pack comes back loudly invalid.

$ laplas verify mind.laplaspack
  digest      ok
  signature   ok
  sealed by   ◈ 9f3a…c41e

One honest limit, flagged in our own internal docs: Ed25519 proves who sealed a mind, not when it was thought. Commit time comes from the system clock, and git honours a forged author date — so months of thinking can be fabricated in five minutes. "Time-density as a tamper-proof credential" is therefore aspirational; the cryptographic claim we can stand behind today is authorship, not chronology. The format that carries the seal is its own track: the .laplaspack format, in plain words.

Portability as a protocol

A whole mind exports to a single .laplaspack — one SQLite file holding the entities, the edges (tagged subject or knowing), the original LMD source of every note, and the seal. SQLite is a deliberately boring choice: one of the most durable, most widely readable formats ever shipped. The round-trip is an asserted invariant — parse, pack, hydrate yields the same graph you started with.

A pack mounts back as a working space: each LMD shard is written out into a fresh git repository, so recall and resolve see a mounted mind exactly like a native vault, with no new machinery. Over MCP, an AI can list spaces and checkout another mind for the session. Portability here is a property of the data — the repo travels — not a vendor-granted export button you wait for permission to press.

How it compares

"AI memory" names three things that don't actually compete head-to-head: embedding/graph stores (mem0, Zep, Letta) optimised for recall; platform-native memory (Claude, ChatGPT) optimised for convenience; and PKM tools (Obsidian, Logseq) optimised for human-readable local ownership. LAPLAS sits at an intersection none of them hold. The honest claim is not that it wins any single column — it is that it holds all seven at once.

✓ native · partial / inferred / SDK = qualified · ✗ no. The two columns nobody else holds natively: git-versioned audit history, and an author-declared causal layer.

What they do better, stated plainly: the embedding stores win decisively on recall breadth — fuzzy, vaguely-worded semantic queries surface relevant memories our keyword-and-structure retrieval would miss — and they have published benchmarks and production latency we cannot match yet. Platform-native memory wins on zero-setup convenience: no MCP config, no git, hundreds of millions of users. Obsidian and Logseq win on manual-note UX and maturity. We are a different artifact, not a better one on those axes.

What we can't do yet

This section is the point. If the rest of the report is believable, it is because this one exists.

• ·Capture precision is below the gate. 38.9% on one vault, one judge. No post-improvement re-grade, no diverse-user grading, no automated LLM-judge yet. 90% is a target, not an achievement.
• ·Time is not tamper-proof. Ed25519 proves authorship; commit dates are forgeable. No RFC3161 or transparency-log anchoring exists.
• ·Fuzzy recall is weaker. True BM25 full-text search runs only over packed minds today; the hot vault's find falls back to in-memory term-counting. Indexed search is roadmap.
• ·No published conformance suite. The engine has unit and differential parser tests, not a frozen spec with a conformance check — and we currently run more than one engine copy, which we owe it to ourselves to consolidate.
• ·No open reader ecosystem. No npx laplaspack verify, no third-party web viewer; verification is in-app only. The pack's commit-spine table is schema-ready but the live exporter does not yet populate it.
• ·Early. This is a young, single-developer codebase, pre-launch. Treat every shipped claim above as v0, and every roadmap item as intent.

An engineer who reads this far should be able to trust the columns we marked ✓, precisely because we did not mark the others.

The thesis

Memory you can read, diff, fork, and reason over causally — owned as a git repository, written by AI through a typed protocol, sealed so anyone can verify who made it. Not better recall. A different substrate.

Meet LAPLAS. Read the format spec. And see the gate we hold ourselves to.