Data & coverage

What the benchmark holds, what it cannot yet see, and — the part usually left out — the difference between the two.

The figures below are fetched when you open this page rather than baked in at build time. A coverage number that goes quietly stale is worse than one that fails visibly, because there is nothing on the page to tell a reader it has stopped being true.

The cohort, this week

Loading current figures…

The four states a case can be in

A case is one transfer: a player, a destination club, and a season. It moves between four states, and collapsing them into "scored" and "not scored" hides the only distinction that matters.

Scorable is the denominator, not the registry count. Coverage is scored cases over scorable ones. Dividing by the whole registry would punish a participant for failing to be scored on players who have not played, which is not a property of the participant.

What cannot be observed at all

A separate problem, and the one most easily hidden by a coverage figure.

A case resolves to a player through the entity registry, and an appearance resolves to one through a match-event source's own player id. A player who has never appeared in collected match data has no such id — he entered the registry from a transfer database — so his case can never be joined to a match row. He is not waiting to be observed. Without reconciliation he stays unobservable all season.

This was measured after two matchweeks of 2026/27: 201 of 809 cases carried no match-source id, and 85 of those players were already playing every week. A quarter of the cohort was silently unobservable and nothing on any page said so.

It is now reconciled weekly, and the reconciliation is deliberately cautious: a player is matched on name plus birth year within one, and only when that match is unique. It refuses ambiguity rather than guessing, because a wrong join scores a participant against a different player's football and nothing downstream would ever reveal it. A residue that never resolves is the correct outcome of that rule, not a failure of it.

Why the reconciliation reads season stats, not match rows

Match rows carry a name and nothing else identifying. Matching on a name alone is exactly how a case gets attached to the wrong player — and the error is invisible, because the resulting score looks like an ordinary score.

The season-level feed carries an age. That is what makes the birth-year check possible, and it is the whole reason the enrichment step collects season statistics it does not otherwise need.

Reference pools

The bands predictions are answered on, and the seasons they were cut from.

A band's width is its share of peer appearances, which is what makes the league base rate reachable from the request alone: a participant that simply predicts the band widths is predicting the base rate, and that is the baseline it has to beat.

What is published, and when

Scores are rebuilt in full from the whole season every week, never accumulated. Adding week nine has to be able to change what weeks one to eight measured — a player's realised distribution is recomputed from every appearance he has made — and a running total could not do that.

One consequence worth stating: a case reconciled on a Wednesday is scored the following Tuesday for everything the player has already done, not only for what he does next.

Where the numbers come from

Every figure on this page is served by the public API, unauthenticated, at GET /api/tasks/transfers/weekly-runs. Nothing here is a figure only we can see, and nothing on this page is typed in by hand.

The versions that produced them are in the version archive.