A universal archive, held as one knowledge graph.

What this is

Your data lives in a dozen places and a dozen formats: mailboxes, repositories, photo libraries, chat histories, documents, logs. Applications are discontinued and formats fall out of use, and a backup keeps the bytes without keeping what they meant or where they came from.

A Ranke-Graph takes all of it into one graph. Everything enters as a claim — a file, a commit, a message, a photograph — recorded whole, attributed to whoever added it, at a stated time, with edges to whatever it came from. Nothing is overwritten and nothing is deleted, so the archive only ever grows.

Those edges are what separate it from other knowledge graphs. A language model trained on documents cannot tell you which document a statement came from, or whether anyone ever wrote it. Other graphs can record that history, a claim's provenance, but treat it as an optional note that may be thinned out or left off. Here it is the structure itself: a claim cannot exist without citing what it was built from, and following those citations always ends at an original source. Whatever an agent answers, you can walk back to the record it rests on.

It is a content type rather than a database engine. The graph is the data, and any store can hold it: a filesystem, Postgres, Neo4j, Redis, S3, or several at once. RankeDB, the server this project ships, serves it and decides who may read and write what — but nothing about the graph depends on RankeDB being there.

What you can do with it

The archive is universal by construction, since a claim holds whatever bytes you give it. What grows is the set of adapters, and they are deliberately cheap to write, because the interface they talk to is small. Git was the first brick.

What it gives you

• Unified Files, commits, messages and photographs in one graph, linked rather than filed apart.
• Verifiable Every record can be checked against the bytes it names, by anyone holding it.
• Traceable Elsewhere provenance is an annotation you may add. Here a claim cannot exist without citing what it came from, and every path ends at a source.
• Simple A storage backend needs three functions, and an adapter is a small client that maps a source into claims. The design is kept small so that both stay easy to write.
• Agent-friendly Built to be traversed by AI agents as readily as by people.
• Storage-agnostic The graph is content, not a database. A filesystem, Postgres, Neo4j, Redis or S3 can each hold it, and a stack of them can hold it at once.

Where to go next