Our Population Table Says 3,678 Registries Got Smaller. Registries Do Not Get Smaller.

A graded population is a ratchet. Slabs get made and counted; they do not get un-made. So when a table that is supposed to track population records a card going from 82,296 slabs to 8,933, the table is not describing the world. It is describing itself. We went looking for how much of our own population data has this property before writing anything on top of it, and the answer was enough to stop.

The obvious way to measure population growth is to take the earliest day in the table and the latest day and subtract. That is wrong here and it fails loudly enough to catch: the earliest day holds three rows. The table is a rotating refresh, so each card is re-read every so often rather than every day, and two days carry 19,881 and 17,822 rows while the rest range from three rows to about four thousand. Comparing a global first day to a global last day compares different cards to each other.

The correct unit is the card. Take each line's own earliest and latest reading, and record how far apart they actually are. Doing that leaves 22,863 lines with two readings at least a week apart, with a median observation window of seven days and a maximum of forty-nine. That is already a much weaker dataset than "forty-nine days of population history" suggests, and it is the honest description of it.

Even per card, the numbers do not behave. Venusaur from Base Set reads 311 total slabs on four separate days across one week, ticks to 312, then 314, and then reads 46,802. A registry does not add 46,488 slabs to a thirty-year-old card overnight. What happened is that the line was matched to a different PSA registry entry: a narrow one, then the aggregate one. The gem count moves with it, from 7 to 588, which is the tell.

The same shape appears on Mewtwo, which reads 403 for six straight days, ticks to 405, DROPS to 359, recovers to 363, and then reads 31,155. A line that falls and then multiplies by eighty-six is not a population, it is an identifier problem. And it runs both ways: 3,678 lines record a decrease, including one that reads 82,296 and later 8,933, and another that goes from 49,783 to 1. Those are the same event seen from the other side, a line moving from a broad registry entry to a narrow one.

Our own published work on registry growth already guards against this. It excludes every line that more than doubled inside the window, and every line whose inflow arrived in one step of 1,000 or more slabs making up 80% or more of the total, which together removed 67 lines carrying 397,348 slabs of phantom growth. That is why its headline is a believable 2.7% a month rather than an impossible one, and it says so in the text. That filter is blunt and it is the right kind of blunt: a real card genuinely doubling its population in a month is rare enough that throwing those cases out costs less than letting a re-map through.

Nothing about "Base Set Venusaur's population grew 150-fold this month" looks broken. It is a real number computed correctly from two real rows. It would have made a striking article. The only thing that catches it is knowing that the underlying quantity cannot behave that way, which is a fact about the world rather than about the data, and no test we could write would have known it.

Read from our own population snapshot table on September 21, 2026: 60,517 rows across 24,224 distinct card lines, with a recorded day, total population, PSA 10 count and gem rate on each. Per-card windows use each line's earliest and latest reading and require them to be at least seven days apart, which leaves 22,863 of the 22,875 lines with two or more readings. Decreases are counted between a line's first and last reading. The Venusaur figures are that card's complete recorded history in the table, not a selection from it. No growth rate is quoted in this piece, deliberately, because the point is that this table cannot support one without a filter. Nothing here is investment advice.