Memory Atlas — see what a YantrikDB store actually holds

The Memory Atlas is a static page that renders an export of a YantrikDB store: every memory that has not been forgotten (tombstoned), the entities the engine linked it to, the claims it holds, the revision history of corrected memories, and the tasks with their recorded status, open or not. It loads one data.json from its own directory, fetches nothing else, no external assets and no model calls, and needs no engine to view.

Open the sample atlas → — a fictional persona’s memory over six months (see below). Drag to orbit, scroll to zoom, choose a scope, search the full memory text, click a memory to open its inspector and follow its connections.

How to read it

• One sphere per store and namespace. The sample is a single store with three namespaces (work, personal, learning), which is the shipped configuration: one memory holding many namespaces, scoped at recall time.
• Dots are memories. Their positions are a deterministic layout for legibility — not an embedding projection and not a measure of similarity.
• Lines are stored entity links. Two memories are joined when the engine linked both to the same stored entity, for entities that appear in 2–30 memories of that store (very common entities would blanket the picture). Solid lines stay inside a namespace; dashed lines cross namespaces within the same store. Separate stores never get lines between them — same-named entities in different stores are not assumed to be the same thing.
• Claims are not drawn as lines. They appear in the inspector, labelled as stated (written by the agent through attach_claims) or extracted (found by the engine’s extractor), with their validity window when one is recorded. A claim whose source memory was corrected after the claim was made is flagged source revised after this claim — the atlas never invents a validity end date.
• Corrections keep their history. A memory changed through correct() shows its prior text, the reason given, and when it was applied.
• Small stores are drawn in full. Up to about 300 memories, every dot and every eligible line is drawn at rest; larger stores draw a sample per scope. Selecting a memory draws its connections, up to 120 lines; the inspector lists the rest in pages.

The sample store

Ari Vasquez is fictional: a machine-learning engineer at a fictional company, with colleagues, a client company, a partner, a sister, tools and places that recur across the three namespaces over six months of backdated memories. The store was built with the current engine through the ordinary write APIs — record_text with metadata and timestamps, attach_claims for nineteen writer-stated facts, correct for three facts that changed (a manager’s team, a launch date, a home address), record_procedural and task_add. Nothing in it is a real person or organisation.

What the engine made of it: 89 memories, 66 entities, 342 memory–entity links (about four per memory), 28 claims (19 stated, 9 extracted), 3 revisions, 5 tasks. Click Dana Okafor in the work scope to see a correction with its prior text, the claims flagged as source-revised, and a neighbour in the personal scope reached through a shared entity.

Export your own store

From yantrikdb 0.23.0 the exporter and the page ship inside the wheel, and one command exports a store and serves the result:

pip install -U yantrikdb
yantrikdb atlas /path/to/memory.db --label "My agent, 2026-09"
# writes /path/to/memory.db.atlas/ and serves it on http://127.0.0.1:<port>

yantrikdb atlas exports exactly one store, never the other files in its directory, and refuses to write into the store’s own directory. --out DIR picks the export directory, --port N fixes the port, --open opens the browser, --no-serve only writes the files. The server answers only the three export artifacts, on 127.0.0.1, with no directory listing. The export runs in a child process that never loads the engine, embeddings or any model; it hashes the .db before and after reading and refuses if the hash changed while it read. Encrypted stores are refused, because the exporter reads raw rows and cannot decrypt them. The same exporter backs the atlas tool in the MCP server (yantrikdb-mcp 0.24.0), which exports and serves the server’s own store on request.

The multi-store script still lives in the repository at examples/memory_atlas/ (now a shim over the packaged exporter): --stores takes a directory of one or more .db files, each becoming its own set of spheres, read one file at a time rather than as one atomic snapshot across them.

The export is a snapshot; re-run it to refresh. It is your data: the page is static, so serve it locally or put it behind your own access control before sharing. Do not export a store that is being written to at that moment; the exporter refuses if a file’s hash changes while it reads, and re-running after the writer settles is the fix.

What it does not show

The atlas is an inventory of what is stored and how it is linked. It is not a retrieval trace — which memories a particular recall would return depends on the query, the lanes enabled and the token budget — and it is not a quality score for the store. Entity extraction noise, when present, is visible rather than hidden; that is the point of looking.