How Memory.Wiki actually works.

1. A document is born

You capture a useful chunk of an AI conversation — say, a ChatGPT explanation of React hooks. You click the Chrome extension. Three seconds later you have a permanent URL: memory.wiki/abc123.

What happened under the hood:

1. The extension walked the visible DOM of the chat page and converted it to clean markdown — code blocks, lists, headings preserved; chrome and ads stripped.
2. It POSTed that markdown to the API. The server minted a permanent ID, returned an edit token (for later updates), and stored a YAML frontmatter block alongside the body.
3. The doc became version 1. Every subsequent edit creates a new version; the URL never changes, the latest version is what readers see.
4. A doc_ontology job was enqueued in the background. An LLM read the body, extracted the concepts the doc talks about, and wrote typed edges between them. That's the doc-level knowledge graph (see the next section).

1b. The document's own knowledge graph

A document is not just markdown — it's also a small graph. As soon as you save, a background extractor pulls out the concepts the doc actually discusses (5 to 15, depending on length) and the typed edges between them. Same edge vocabulary the bundle layer uses (supports / elaborates / contradicts / exemplifies / contains / defines / depends_on), just scoped to one doc.

These edges are stored in concept_relations with the doc id as evidence. When the same concept turns up in another doc, the graph stitches itself across docs at the hub level automatically — no [[wikilinks]] for the human to type.

What an AI sees when it fetches memory.wiki/abc123 via the raw endpoint:

That's the whole contract for a Document URL: clean markdown body, a frontmatter block telling the AI which scope it just received, a tags list, and a structured grounding signal — the doc's own concept graph — appended below the body. No SDK, no auth, no rate limits. Pass ?compact to drop the appendix and trim whitespace if you only want the prose.

2. From doc to bundle

One doc is useful. Twelve docs on the same topic become something more — a curated reading list with cross-document insights. That's a bundle: memory.wiki/b/bnd789.

You build a bundle two ways. You hand-pick docs in the editor, or you ask the AI to assemble one (“bundle everything I have on React rendering”). Either way, the bundle gets its own permanent URL.

When a bundle is first analyzed, an LLM run extracts: a one-line description, three to five themes that cut across the docs, cross-document insights and contradictions, concept relations, and key takeaways. The analysis is cached in the bundle’s digest, not regenerated on every fetch.

A bundle URL ships its analysis inline so the receiving AI inherits the prior AI’s work for free:

The compact bundle digest is 5 to 9× cheaper in tokens than inlining every member doc, while still letting the receiving AI walk to any specific doc on demand. That tradeoff is the whole reason the bundle layer exists.

3. The hub

Your hub is the namespace that holds every doc and bundle you've published. Mine is memory.wiki/@hyunsang. Yours is memory.wiki/@<you>.

The hub URL doesn't fetch a single document — it returns a manifest that lets the AI discover what's in your knowledge layer. Following the llms.txt standard:

The manifest is built automatically as you publish — no manual curation. The hub also auto-publishes an index.md (human-readable), a SCHEMA.md (machine-readable structure), and a log.md (chronological history). A hub-wide concept index spans every doc, surfacing where the same idea shows up across your knowledge.

Pasting the hub URL into Claude or ChatGPT once is enough — the AI fetches the manifest, then walks to specific docs on demand. The full corpus never has to fit in one context window.

4. When something updates

You edit a doc — the URL stays the same. A new version is snapshotted. Readers always see the latest, but you can diff between versions or restore any prior one.

Net effect: every URL is always live. Nothing 404s. Stale state is visible, not hidden. You don’t maintain a CI pipeline for your notes.

5. What the AI sees when you paste

The whole architecture only matters if the receiving AI can read it cleanly. Here’s what happens when you paste a Memory.Wiki URL into Claude or ChatGPT:

Claude (or ChatGPT, or Gemini, or Cursor) hits the raw endpoint — /raw/hub/<you> — and receives plain markdown with a frontmatter block. Frontmatter tells the AI: this is a hub manifest, not a single doc. The AI follows links from the manifest to specific docs as it needs them.

The receiver doesn’t need an SDK, an API key, or a plugin. It needs only the ability to fetch URLs — a capability every modern AI tool ships.

Token economy: pass ?compact on any raw URL to strip whitespace and noisy quote blocks (typical 30 to 50% reduction). Pass ?full=1 on a bundle to inline every member doc. ?graph=0 on a bundle drops the analysis section. Knobs combine.

6. Does it actually work?

The URL contract is a claim. To verify it independently, we run an open cross-AI evaluation — every major AI, both a hub the model could plausibly have seen during training and a hub it definitely hasn’t.

Headline: 100% faithfulness on paste mode against the unseen hub. 98% on browse mode (AI fetches the URL itself) — the 2% gap is fetch failure, not contract failure. Adversarial refusal also at 100% — when asked something outside the URL's scope, the AI refuses rather than fabricates.

Full methodology, judge prompt, round-by-round results, replication recipe → read the benchmark page.

7. What we deliberately did not build

Three things you might expect that are intentionally absent:

• No [[wikilinks]]. Traditional wikis make humans type the graph. Memory.Wiki extracts a concept index automatically — the AI does the linking, you write.
• No SDK. The interface is the URL. Anything that can fetch a URL is a client.
• No proprietary blocks. Markdown is the entire format. If Memory.Wiki disappears tomorrow, your docs are still markdown files you can open in any editor.

That's the system. The full open spec documents every endpoint and query knob if you want to implement against it.