An archive that documents this project

The demo is a real Ranke archive, and what it records is Ranke-Graph itself. Every release of every repository in the project enters it as a snapshot of the source, together with the logs of the build that produced it.

What the archive records

Each repository is an entity in the graph, and each of its releases is another. Cutting a release snapshots the repository at the commit that was tagged, and that snapshot attaches to the version it belongs to. The build attaches its logs to the same version.

A version therefore carries both halves of its own history: the source it was built from, and the record of the build that turned that source into a release. The archive grows by one version per release, and an earlier version keeps its snapshot and its logs as they were first recorded.

Release documentation

This is one use case for a Ranke archive, and among the smallest. The evidence behind a released version is usually scattered: the tag sits in git, the artefact on a release page, and the logs in a build server that discards them after 90 days. Each lives under a different retention policy, and what connects them is convention.

Collecting them onto one entity changes what you can ask. Which commit did this version build from, and what did its tests say on the day it shipped? The answer names the record it rests on, and the bytes are there to check it against.

Walk it in the explorer

Ranke-Explorer is the frontend RankeDB serves: it draws the graph and lets you move through it. Pick an entity, follow its edges to the claims that cite it, and open a claim to read the content recorded under it.

Visitors read the archive without an account, and read-only. What you see is this project's own archive rather than a fixture, so it grows every time a release is cut.