Data snapshots

How to read the id

An id like r42.71638 has two parts: r42 is the highest completed run that contributed to it, 71638 is the number of results the snapshot holds. Both change when the data changes, and neither can change without the other being republished.

The run number alone would not be enough. We do not remeasure every vendor every night: a run covers part of the catalogue, so the results in one snapshot come from several runs. The count is what moves when a partial run lands.

What a snapshot guarantees

• Every figure on one page comes from one snapshot. A page reads the database once, inside a single read transaction. A measurement run finishing halfway through cannot move the denominator between the top of a page and the bottom of it.
• The API says the same thing. Every response carries snapshot, snapshot_run, snapshot_results and snapshot_measured_through.
• It is not a promise that two pages agree. If you open one page, wait for the nightly run and open another, the ids differ and so may the figures. That is what the id is for.

Why this exists

On 4 September 2026 a review found the same figure twice on one page with two different values: 1,321 of 4,764 near the top and 1,323 of 4,768 further down. Nothing was wrong with the arithmetic. The page read the database in several separate queries, and the measurement run – which runs in its own container – wrote between two of them. A page that contradicts itself is worse than a page that is a day old.

The score has a version too

The transparency score is Transparency Score v1: a share of the summed weights of 12 criteria. Adding a criterion would change every score we have ever published, including the one in a procurement file from last week, without the vendor doing anything. New criteria are therefore measured and shown as facts, and a version 2 will start as a clearly named second figure rather than by quietly redefining the first. The full method.

• The criteria as JSON
• All measured detail
• How we measure and weight