Your tool will die. Your knowledge doesn't have to.
You have spent months — maybe years — building a knowledge system. Notes linked to notes. Tags applied with care. A structure that mirrors how you think. Then the company behind your tool gets acquired. Or pivots. Or raises prices 300%. Or just stops updating.
This is not a hypothetical. It is a pattern that has repeated across every generation of knowledge tools, and it will repeat again.
Google Notebook launched in 2006, gained a loyal user base in education and research, and was shut down in 2012. Google Reader — the RSS hub through which millions organized their information diet — was killed in 2013. The website Killed by Google catalogues over 290 discontinued products and services. Evernote, once the default note-taking platform for a generation of knowledge workers, has degraded so severely that its own forums are filled with users trying to escape — discovering that the export function limits them to 50 notes at a time, crashes on large libraries, and strips links and formatting in the process.
Every one of these tools was, at the time of adoption, "the future of knowledge management." Every one of them either died or became something its users no longer recognized.
The question this lesson answers is: how do you build a knowledge graph that survives the death of any single tool?
The graph is not the tool
A knowledge graph consists of two things: nodes (your ideas, expressed as content) and edges (the connections between them). Everything else — the sidebar, the search bar, the graph visualization, the mobile app, the sync engine — is interface. It is the window you look through, not the landscape you are looking at.
This distinction matters because most people conflate their knowledge with the tool that displays it. They say "my Notion workspace" or "my Obsidian vault" as if the tool and the knowledge are the same thing. They are not. Your knowledge is the content of the notes and the structure of the connections. The tool is a viewer.
When you confuse the viewer with the thing being viewed, you make an architectural error: you allow the tool to own the format of your knowledge. You let Notion store your ideas in proprietary database blocks. You let Roam encode your links in a format only Roam can read. You let Evernote wrap your text in XML schemas that require Evernote-specific parsers to decode.
The moment you do this, your knowledge graph is no longer yours. It is a tenant in someone else's infrastructure. And tenants get evicted.
Luhmann's proof: sixty-seven years and counting
The most famous personal knowledge graph in history was built on paper.
Niklas Luhmann, the German sociologist, began his Zettelkasten in the early 1950s. Over the next four decades, he wrote approximately 90,000 index cards — each containing a single idea, written by hand, linked to other cards through a branching alphanumeric numbering system. Card 21/3a1p5c4fB linked to card 21/3a1p5c4fA, which linked to card 21/3a1p5. The links were explicit. The format was plain text — ink on paper.
Luhmann died in 1998. His Zettelkasten did not die with him.
The University of Bielefeld purchased the collection from his estate, catalogued every card, and in 2019 published the entire system online as a digital archive. Researchers can now browse Luhmann's graph — follow his links, read his arguments, trace how ideas evolved over decades — using a web interface that did not exist when any of those cards were written.
The tool changed completely. Paper became pixels. Card drawers became database queries. The browsing interface went from fingers-in-a-box to click-on-a-link. But the graph — the nodes and the edges, the ideas and their connections — survived intact. Because the format was durable. Handwritten text on paper is readable by any literate human with no software dependencies. The linking system was explicit and self-documenting: you could reconstruct the entire graph from the cards alone.
This is the existence proof. A personal knowledge graph, built in durable formats with explicit connections, outlived its creator, outlived the era in which it was made, and remained navigable across a complete change of medium.
Why tools die but formats persist
Not all formats are equally durable. The spectrum runs from maximally portable to maximally trapped:
| Format | Can you read it in 2060? | Tool dependency | | ----------------------------------- | -------------------------------------------------------- | --------------- | | Plain text (.txt) | Yes — any editor, any OS | None | | Markdown (.md) | Yes — readable as plain text, renderable with any parser | Near-zero | | HTML | Yes — any browser, and browsers will exist | Very low | | JSON/YAML | Yes — human-readable, parseable by any language | Low | | SQLite database | Probably — open standard, widely supported | Low-medium | | Proprietary XML (Evernote .enex) | Maybe — requires a compatible parser | Medium-high | | Proprietary database (Notion, Roam) | Only if the company provides export | High | | SaaS-only with no export | No | Total |
Steph Ango, the CEO of Obsidian, articulated this gradient as the "file over app" philosophy: "If you want to create digital artifacts that last, they must be files you can control, in formats that are easy to retrieve and read." His core observation is blunt: "All software is ephemeral." Every app you use will eventually be discontinued, acquired, or transformed beyond recognition. The files you create have a chance to outlast all of them — but only if they are stored in formats that do not require any specific software to be read.
Ango's analogy is instructive: the hieroglyphs chiseled into Egyptian temples are still readable thousands of years later. The ideas they convey outlasted the chisels, the quarries, the entire civilization that produced them. The format — marks carved into stone — is durable. The tools used to create and read them are long gone.
Plain text is the digital equivalent of stone. A .txt file created on a Macintosh in 1984 is still readable on any computer today — forty years later, across dozens of operating system generations. Markdown extends plain text with lightweight structure (headings, lists, links) while remaining readable without any rendering engine. You can open a Markdown file in Notepad and understand it perfectly.
The portability test
Here is how to evaluate whether your knowledge graph is portable:
Test 1: The plain text test. Export your entire knowledge base. Open the exported files in a plain text editor — not the app that created them. Can you read the content? If the export produces binary blobs, proprietary XML, or database dumps that require specialized software to parse, your knowledge is locked in.
Test 2: The link survival test. In the exported files, can you identify and follow the connections between notes? If links are stored as internal database IDs (like Notion's block references or Roam's page GUIDs), they become meaningless the moment you leave the tool. If links are stored as human-readable references — filenames, titles, relative paths — they survive export.
Test 3: The reconstruction test. Give your exported files to someone who has never used your tool. Can they reconstruct the graph — understand which ideas connect to which, and why — using only the files and a text editor? If yes, your graph is portable. If they need to install your specific app and import the files back into it, your graph is a hostage.
Test 4: The decade test. Imagine the company behind your tool shuts down tomorrow. Ten years from now, with only the exported files on a USB drive, can you rebuild your knowledge system in whatever tool exists in 2036? The answer depends entirely on the format.
How to build a graph that outlasts its tools
The principles are concrete:
Store content in plain text or Markdown. These formats have zero software dependencies. A Markdown file written today will be readable on any computer built in the next fifty years — because it is just text, and text is the most fundamental digital format. Every note in your graph should be a standalone file that makes sense when opened in any editor.
Make links explicit and human-readable. Use wikilinks ([[note-title]]), relative file paths, or any linking convention that a human can read and follow without software assistance. Avoid links that depend on internal database IDs, API endpoints, or proprietary reference schemes. A link like [[knowledge-graph-portability]] survives any tool migration. A link like block:a7f3e2d1-4b5c-6789 does not.
Store metadata in open formats. If your notes carry metadata — tags, creation dates, categories, relationship types — encode it in YAML frontmatter, JSON sidecar files, or any structured text format that adheres to open standards. This keeps your metadata human-readable and machine-parseable without requiring a proprietary database.
Keep files in a local filesystem. Cloud-only tools give you access, not ownership. If the only copy of your knowledge exists on someone else's server and can only be accessed through their interface, you own nothing. Local files, synced to the cloud as a backup, give you both access and control.
Version your graph. Put your knowledge files in a version control system like Git. Every change is tracked. Every version is recoverable. Your graph gains a history — not just what you know now, but what you knew at every point in the past. This is a layer of durability that no proprietary tool provides.
Linked data: the web's answer to portability
Tim Berners-Lee articulated the principles of portable, durable knowledge structures in his 2006 design note on Linked Data. His four rules are directly applicable to personal knowledge graphs:
-
Use identifiers to name things. Every node in your graph should have a stable, unique identifier — a filename, a slug, a URI. Not an auto-generated database ID that changes with every export.
-
Use standard protocols. Store your content using formats (Markdown, HTML, JSON) and protocols (HTTP, filesystem paths) that any tool can read.
-
Provide useful information at each identifier. When you follow a link to a node, you should find meaningful content — not a redirect to a proprietary viewer.
-
Link to other identifiers. Every node should connect to other nodes using the same stable identifiers, creating a web that is self-describing and tool-independent.
These principles, designed for the open web, apply equally to your personal knowledge graph. A graph built on stable identifiers, open formats, and explicit links is a graph that any future tool can consume — because it follows the same structural principles that make the web itself navigable.
The real cost of lock-in
People resist this argument because migration feels hypothetical. "I'll worry about it when the time comes." But the cost of lock-in is not just the eventual migration — it is the ongoing constraint on how you can use your knowledge.
A locked-in graph cannot be:
- Queried by other tools. You cannot run your notes through a custom script, a local AI, or a search engine that isn't your note-taking app.
- Combined with other data. Your reading highlights, journal entries, project notes, and reference materials live in different proprietary silos that cannot see each other.
- Shared selectively. You cannot give a collaborator access to a branch of your graph without giving them access to the entire tool and its account.
- Processed by future technology. Every new capability — AI summarization, semantic search, graph analysis — requires your data to be in an accessible format. Locked-in data sits behind a wall that each new tool must negotiate separately.
Portable knowledge, by contrast, is composable knowledge. When your graph lives in open formats on your filesystem, you can pipe it through any tool that reads text files. Today that might be a local LLM. Tomorrow it might be something that does not yet exist. The format outlasts the tool because the format does not assume any particular tool.
The deeper principle
This lesson is not really about file formats. It is about a relationship between you and your knowledge.
When your knowledge lives in a proprietary tool, you are a user. The company decides what features you get, what export options exist, what your data looks like. When your knowledge lives in open formats that you control, you are the owner. You decide how to browse it, process it, share it, and evolve it.
Luhmann's Zettelkasten endured because the knowledge was encoded in a format — handwritten cards with explicit numeric links — that any person could read, that any system could ingest, and that no single tool controlled. He did not build his graph for a filing cabinet. He built it in a format that happened to be storable in a filing cabinet, and equally storable in a digital archive sixty years later.
Build your graph the same way. Not for Obsidian, not for Notion, not for whatever tool launches next year. Build it in plain text, with explicit links, in files you own. The graph will outlive them all.
Because the next frontier is not just browsing your graph yourself. It is feeding your graph to an intelligence that can reason over it. And that intelligence — as the next lesson explores — does not care what tool you used. It cares whether your knowledge is structured, linked, and accessible. Portability is not just preservation. It is the precondition for what comes next.