Two people are writing documentation. Person A — in one project, person B — in another. Both describe the same entity, each from their own side, and neither suspects the other exists. There are no links between their documents — how could there be, they didn’t know what to link to. Yet semantically these are two pieces of one piece of knowledge.
Every team has this. Knowledge is connected by its own nature — it’s just that nobody drew those connections, and tools usually show only what was drawn by hand. In Meldoc we wanted to show the rest too. That’s how the graph with three layers of connections came to be.
From the obvious to the reason it all exists
The first layer is the most familiar one: hierarchy. One document is nested in another; a document has children. A parent–child relationship, visible to anyone who opens the project tree.
The second layer is explicit links. You write a document, you reference another one — a link appears between them. Anyone who has worked with Obsidian will recognize the picture immediately: its graph is built exactly like that, and up to this point we’re no different.
And then comes the part I’m actually writing this text for. The third layer is semantic proximity. Meldoc looks at individual blocks of text and notices: here and over there, this is about the same thing. Two documents mention one concept — and a connection lights up between them, like one more thread alongside the regular links. Nobody placed it. It simply exists, because the knowledge really is connected.
Back to person A and person B. Meldoc will connect their documents by itself — with a smart link, semantic cross-linking. Not because one of them remembered their colleague, but because both wrote about the same thing.
A little story about magic links
The third layer shows its full power when an agent works with the base through MCP (how that works — in MCP in Meldoc). You can ask the agent: find documents that are semantically close but not explicitly linked. It will find them. And then it either places the links, or does something more interesting — describes an entity that is mentioned in two places but documented nowhere.
My favorite example is magic links. Say they’re mentioned in one document, mentioned in another, and there is no document about what they actually are. A classic hole: everyone writes about the thing, nobody has explained it. You run an agent with the prompt “find entities that aren’t documented yet and document them” — it walks the semantic connections through MCP, stumbles on those two mentions, and writes the missing document. The hole is closed, and nobody had to manually re-read the whole base hunting for blind spots.
That, to me, is the point of graphs. Not the pretty cobweb on the screen — you can see the structure in the tree anyway. It’s that the graph exposes connections the team itself doesn’t know about: other people’s documents about your topic, concepts everyone mentions and nobody has described, knowledge scattered across corners. A practical ritual for closing such holes on a legacy project — in Don’t document legacy. Close the holes, and a one-off pass over duplicates and broken links — in “We should clean up the docs”.