The rail under the loading comparison has carried "99M+ splats captured" since the start of the month. It was measured properly on the seventh of August, with the arithmetic written into a comment above it so anyone could check the sum. Three weeks later it was wrong by about a third, and nothing had failed, because a number in a paragraph has no test.
That first failure is the boring one and the most common. The place count sitting six inches away on the same rail had been computed from the arena registry since the day it was written, so it moved on its own every time a capture went live. The splat total was a literal. Same sentence, one half checkable and one half not, and the uncheckable half is the one that aged.
So I made it computed, and got it wrong. The rule I wrote was: count the largest reconstruction the registry points at, meaning the inspect file where a capture declares one and the top rung of its detail ladder where it does not. That is a reasonable rule. It gave 131 million.
It was wrong because a rung is not a capture. Two places ship a single small rung today, not because that is all there is but because nobody has cut the rest yet. Gstaad went in at 904 thousand against a real 29.6 million. Lisbon at 437 thousand against 14.1. The rule was answering how much of a place ships, when the question was how big the place is.
Fixed that, got 173 million, still wrong. For the bundles too old to state their own ladder I had fallen back to reading the header of the obviously named file, the one called place-name dot compressed dot ply. For two places that file is not the finest version at all, it is a middle rung somebody exported once and left there. Tübingen went in at 3.3 million against 26.2. Aachen at 3.7 against 14.8. Thirty-four million missing across two places because a filename looked authoritative.
Each version looked settled when I wrote it. What they had in common was a judgement in the middle: which file, which rung, which name. A number that needs somebody to choose its input is a number somebody can choose wrong, and I chose wrong twice.
The third version has no choice in it. Every capture is stored as an octree, split into chunks, and every chunk carries a small file saying how many splats it holds. The chunks whose names begin with a zero are level zero, the finest level, which is the capture. Adding those up is not a measurement and not an interpretation. It is the bundle stating what is in it. All 430 of those chunk files are in the repository, so the test recomputes every place from them on every run. The answer is 207,707,731.
One number in there is deliberately not the biggest one on offer. Each bundle also states a total across all its levels, and for La Sarraz that total is 65.9 million against 33.1 at level zero. The levels below zero are the same square described more cheaply, so summing them counts one place eight times over. It would have roughly doubled every figure on the page, and it would have been a lie of exactly the kind this whole exercise was about.
The five original captures still add up to 99,520,763, which is the figure the page carried before any of this started. That is a test now. It is the only part of the first version that survived, and it is what tells me the method was right for those five all along, and that everything wrong was in which file I chose to read.