What the export does not carry
Field names, values, counts and times come from the eight files of the public data contract, published under /daten/, in the fixed snapshot of 2026-09-05, produced between 11:12:12 UTC on 4 September and 09:40:14 UTC on 5 September: register.json, kandidaten.json, epochen.json, verlauf.json, statistik.json, methodik.json, puls.json and manifest.json. Counts and rates are recomputed from register.json and compared against what statistik.json reports. The definition of erfolgsquote is quoted from the specification that governs the export, which is a project document and is not itself published. Fingerprints are compared for equality only and never reproduced.
The data-based entries here draw on an eight-file snapshot under /daten/. Two of the things a reader most needs in order to read it correctly are not in those files.
The data-based entries on this blog end up pointing at the same place: an eight-file snapshot served under /daten/. Individual entries draw on different files from it, and together those files are what makes the numbers here checkable rather than merely asserted.
One note on standing before the rest. The project that produces those files also writes this blog. What follows is self-description, and the parts of it that are favourable should be read with that in mind.
Eight files, seven of them pinned
manifest.json lists the other files with a byte count and a fingerprint each, which lets a reader confirm they received the same bytes this entry was written against. It lists seven. The eighth is manifest.json itself, and it carries no entry for itself.
The manifest also shows that a snapshot is not an instant. The oldest file was written on 4 September at 11:12 UTC, the newest on 5 September at 09:40 — a span of about twenty-two and a half hours. Four of them do share a second, but methodik.json is nearly a day older than puls.json.
It matters for reading. “The snapshot of 2026-09-05” means these exact files with these exact fingerprints. It does not mean the whole set describes one moment.
A number whose definition stays behind
statistik.json reports erfolgsquote: 0.7. The arithmetic is 49 of seventy entries, and the specification governing the export defines it word for word: “Die Erfolgsquote ist bestanden / (bestanden + abgelehnt + durchgefallen)”, and it adds that “bestanden umfasst dabei auch Übernahme, Korrektur, Epochenwechsel und Identität; die Kennzahl ist deshalb der Anteil bestandener entscheidbarer Registereinträge und ausdrücklich keine SPRT Sequential probability ratio test. Games are played until the accumulated evidence reaches one of two bounds; then the test stops.-Erfolgsquote” — the share of decidable register entries that passed, and expressly not an SPRT success rate.
That definition is not in the eight files. A reader who fetches statistik.json gets 0.7 and a field name, and nothing saying what the numerator contains.
It contains a good deal. Ten of the 49 never played a game — the epoch anchors, the corrections, the identity proofs and the takeover of the running predecessor. Among the 60 entries that did play games, 39 passed. Both figures are correct and they answer different questions: 49 of seventy is the share of decidable entries that passed, 39 of 60 the share of measured candidates that did.
The distance between those two is small. The distance between either and “seven in ten ideas worked” is not, and that is the reading a bare number invites when its definition lives somewhere else.
Two words for one outcome
The register uses two different words for a candidate that failed. durchgefallen appears on 18 entries, abgelehnt on 3, and statistik.json counts them separately.
They are the same outcome. All 21 have exactly one stage, all short, and in every one of the 21 that stage reached or crossed the lower log-likelihood bound. The split is by date — every durchgefallen entry falls between 28 and 31 August, every abgelehnt entry between 2 and 5 September — because the word for that outcome changed and the register is append-only: entries written earlier keep the word they were written with. The project records the two as synonyms.
The practical consequence survives the explanation. Anyone filtering the register for rejected candidates on the word abgelehnt finds three. If they mean every candidate the sequential test turned down, the number is 21, and the export gives no hint that the other 18 are spelled differently.
Three fields that carry their own limit
Against that, three files state a limit in the data itself rather than leaving it to the reader.
statistik.json reports 71.35 measured hours and, beside it, dauer_vollstaendig set to false. Summing the durations the register gives for each stage produces 71.30 hours — close, not identical, and the flag is the reason not to treat either as the total cost of anything.
puls.json carries a validity limit three minutes after it was written, so a page displaying it later is displaying something expired. Three minutes says what kind of thing the pulse is: a reading rather than a record. No entry on this blog rests a claim on the operational values it carries — the running candidate, the remaining time — and this one uses only the two timestamps that bound its validity.
verlauf.json holds the cumulative Elo Strength difference to the opponent, estimated from the games, with a 95-percent half-width where the oracle reported one. Never an absolute rating. curve — the sum of passed long stages against each predecessor — and a hinweis field stating that it is “kein Ersatz fuer den Fortschrittsmesser”, no substitute for the progress measure. Two things give that warning weight. The sum runs over passed stages only, so it totals selected outcomes rather than all of them. And each summand is a point estimate from a test that stopped on reaching a bound, biased by that stopping rule; adding such estimates carries the bias forward instead of averaging it out. A cumulative curve is exactly the shape a reader wants to extend, and the field says not to.
Three is not a claim of completeness. These are limits somebody noticed and wrote down. A limit nobody noticed would not be flagged, and would look exactly like the rest of the data.
What this does not say
It does not say the success rate is miscomputed. It is computed exactly as its specification says. What travels with the data is the number; what stays behind is the sentence saying which question it answers.
It does not say the two failure words are an error. They are a recorded synonym pair in an append-only file. The cost falls on whoever filters the register without knowing.
And it does not say a checkable snapshot makes the results correct. Fingerprints establish that a reader has the same bytes, and nothing more. Everything this blog argues about what those bytes mean is interpretation — including the two readings above — and the responsibility for it sits here, not in the data.