emem, the verifiable memory protocol for the physical world

Encode where the data lives. Decode with any AI.

emem is shared, verifiable memory for machines and AI. The proof travels; the files stay where they are.

Try it, no key · Quickstart · A worked example · Verify a token · Agent guide · Docs

Trust without moving the file

Today, to trust a piece of data you usually have to hold it. A satellite downlinks the whole capture, a lab emails the spreadsheet, a company uploads its documents to whichever AI is reading them, and every copy is one more place the data can leak or quietly change.

emem splits the job in two.

• Encoding happens at the source, and stays private. A file server, a lab, a camera or a payload computer hashes what it holds into units and signs a small record under its own key. The bytes do not have to leave. What leaves is a commitment to them: a content id, a Merkle root, a signature.
• emem is the decoding half. Any model, in Claude, in ChatGPT or in your own code, resolves a short token back to that exact record, checks who signed it, and proves that one unit belongs to the whole, without trusting the sender, and without trusting emem.

A token lets a reader resolve the published record and check content they are given against it. It does not reveal what you kept: a tree token over a private file exposes the units you chose to publish and nothing else.

What crosses, and what stays

What each check proves is stated with it. A custody record says bytes arrived, not that the sensor was calibrated. A tree proves a unit was in the file you signed, not that the file is true. A code_cid says which code you claim produced a value; running arbitrary private code in a sandbox is not built.

Quickstart

No account and no API key to read.

1. Connect an MCP host (Claude Code here; every other host):

claude mcp add --transport http emem https://emem.dev/mcp

2. Prove one part of a file without the rest of it. This repository's LICENSE is published as a signed tree of six 2 KB units, so you can try the file path with nothing to set up. From a clone:

curl -s "https://emem.dev/memories/by_attester/k572x7go/readme-example/license-tree.md" > index.md

curl -s "https://emem.dev/v1/tree/xrnco3igl6j2j4kehg4z33ggk4?row=3" > row.json python3 plugins/emem/skills/emem-tokenise-files/scripts/tree_proof.py check row.json index.md LICENSE

The index names every unit's hash and the root; the row carries unit 3 and its audit path. The check confirms bytes 6144 to 8191 are in the file the key k572x7go signed, by hashing those bytes and walking three steps to the root. For your own file, tree_proof.py build report.md cuts it into units and prints the index offline; sign and publish it under your own key (the skill walks through it). The file never leaves your machine.

3. Read a signed measurement and check it offline (curl, jq, Python):

curl -fsS https://emem.dev/v1/recall -H 'content-type: application/json' \

-d '{"place":"Cairo","bands":["copdem30m.elevation_mean"]}' > fact.json jq '.facts[0] | {cell, value, unit, memory_token}' fact.json

jq '{token: .facts[0].memory_token}' fact.json \ | curl -fsS https://emem.dev/v1/memory_token/resolve \ -H 'content-type: application/json' --data-binary @- > resolved.json

# pip install "ememdev[signing]"

import json from ememdev.verify import verify_receipt_offline

verdict = verify_receipt_offline(json.load(open("resolved.json"))["receipt"]) print(verdict.ok, verdict.why) # True, checked in this process with no network call

The check uses the public key the receipt carries. To know it was emem that signed, pin emem's key from /.well-known/emem.json, or check the token at emem.dev/verify.

Or just ask, from the shell, Python or TypeScript

curl -s -X POST https://emem.dev/v1/ask -H 'content-type: application/json' \

-d '{"q":"what is the NDVI near Mount Fuji?"}' | jq '{answer, receipt: .receipt.fact_cids}'

# pip install "ememdev[signing]"

from ememdev import Client from ememdev.verify import verify_receipt_offline

with Client() as em: out = em.ask("what is the NDVI near Mount Fuji?") print(out["answer"], verify_receipt_offline(out["receipt"]).ok)

// npm i @vortxai/emem

import { Client } from "@vortxai/emem";

const out = await new Client().ask({ q: "what is the NDVI near Mount Fuji?" }); console.log(out.answer, out.receipt.fact_cids);

There is no rule for turning a tool name into a REST path, so do not guess one: emem_memory_search answers at POST /v1/memory/search and emem_verify_receipt at POST /v1/verify_receipt. The authority is /openapi.json; over MCP, call the tool by name.

For agents. Connect to https://emem.dev/mcp. It advertises the 18 tools of the core loop in one page, about 75 KB of context, not the whole catalog: loading all 116 descriptors costs about 329 KB. For the lightest first contact, emem_tools returns the loop and a menu in about 13 KB, and tools/call dispatches every tool by name, with or without its emem_ prefix. To hand records on, prefer a bundle: emem_memory_bundle names up to 256 facts in 38 characters.

Memory that changes without losing its history

One field, worked end to end on the live node on 2026-10-10. Every token below resolves, and you can check each step yourself.

1. Name the thing once. The field gets an identity that stays put while everything measured about it changes:

emem:entity:2kmmk5bflnt5v2g7fh5y5ezqhe     "Wheat field west of Ludhiana", a farm_plot at cell defi.zb560.kUtU.sozo

2. Two observations, each its own record. NDVI read from Sentinel-2 on two dates. Each reading has its own content id, so a later reading never overwrites an earlier one:

2026-03-12   NDVI 0.893   emem:fact:defi.zb560.kUtU.sozo:4okfcg4nyi7fo4ftfj57yzjdghc7av7jfjd3fp2urk7vajztgxpa

2026-06-27 NDVI 0.158 emem:fact:defi.zb560.kUtU.sozo:hbliam74soj7pmqy7ig67hyyqn7lz6fe7baagv743fzi75p2drpq

3. A result derived from them, and recomputed. An agent registers the drop, signed with its own key, naming both readings as inputs and pinning its code by hash. Because the operation is a pure delta, emem re-runs it over the two signed parents before recording it:

emem:fact:defi.zb560.kUtU.sozo:n77qfh6isswzwel5i5v7mvl6fmptsf647pklplh6rrdufglz775q

value -0.7352330536822305 class deterministic_index rule canonical_float_equality ulp_gap 0

4. A correction that keeps the original. The agent first wrote that the field was harvested on 27 June. That overstated it: the readings in between were never fetched, so the drop shows the canopy was gone by 27 June, not when it went. The agent wrote a corrected note and superseded the first. Readers of the old path now get superseded_by, and the original bytes still resolve, so anyone can see what was corrected and why:

/memories/by_attester/k572x7go/readme-example/farm-v1.md   superseded_by rhngbrlvt3ihzbm3bdxjkdjrmy

reason "The NDVI drop shows the canopy was gone by 27 June; it does not date the harvest."

5. Another agent checks all of it, trusting nobody:

curl -s -X POST https://emem.dev/v1/memory_token/resolve -H 'content-type: application/json' \

-d '{"token":"emem:fact:defi.zb560.kUtU.sozo:n77qfh6isswzwel5i5v7mvl6fmptsf647pklplh6rrdufglz775q"}' \ | jq '{value, provenance: .provenance.class, inputs: .fact.derivation.args.inputs, recomputed: .fact.derivation.args.recomputation.verified}'

It gets the value, the two input tokens to resolve in turn, and the responder's statement that it reproduced the value, all under one receipt it can verify offline. Identity, time, provenance, computation and correction, in one place.

The operations behind those steps, and the rest of what agents do with them:

| Read what is known, at a place or across an area | emem_recall, emem_recall_polygon and emem_grid fetch and sign o