Data & coverage — Game Value, team board

What the Arena publishes, when it is collected, and what happens to a result that does not add up. The rules for delivering against this data are in the delivery contract; this page is about the data itself.

What is in scope

The 2026/27 season, five competitions, with one score across all of them:

Five leagues rather than one, because a metric that orders one league well and another badly has told you something — and one score rather than five, because the per-competition spread reaches 0.109 and is not stable between seasons. Five columns would invite a reading none of them supports.

A participant chooses which competitions to enter, and within one it delivers everything. The competitions are named exactly as the fixture list spells them, which is what the ?competition= filter accepts.

What the Arena publishes

Two public, unauthenticated reads. Both carry the Arena's own identifiers and nothing else: no provider identifier appears anywhere in this benchmark, in either direction.

The fixture list

The published schedule for the whole season across the five competitions, most of it still to be played: each fixture with its round, kick-off in Europe/Paris, both team ids, its status, and the deadline its round is due at, known before the match is played.

match_id is the Arena's own: fam_<season>_<competition>_<n>, spelled out rather than abbreviated because it ends up in every payload a participant handles — fam_2627_premierleague_0042 needs no key, where fam_2627_epl_0042 invites a guess. It is stable from publication to scoring, through any reschedule.

The team registry

Every team with a fixture this season: team_id, club name, country and competition. Team ids are opaque and stable (FAT00066).

Club names are published so a fixture row is readable, and are not accepted in a delivery. A name match is a guess, and a guess attaches a value to the wrong club silently — which is the kind of error that survives review because nothing about it looks wrong.

When it is collected

Daily rather than weekly, so a postponement or a rescheduled kick-off appears in the fixture list as it happens rather than at the end of the week. A job that reads the list every run therefore always plans against the current calendar — which is why ?since= exists.

Statuses, and what changes them

A postponed match that comes back more than five days from the rest of its round stops sharing that round's deadline and becomes a round of its own, with its own deadline and its own delivery budget. Everything else about it is unchanged, including its identifier.

How a result is validated

A result is not taken on trust because it was published. Every finished match is checked by tallying its goal events against its official score, and the result carries the outcome of that check:

incomplete_events is tested before disagreement, deliberately: when a feed cuts off at the 60th minute, the missing goals are the cause and the disagreement is only the symptom. Reporting the symptom would send a reviewer looking for a scoring error that does not exist.

Anything other than ok is flagged for a person, not resolved automatically and not silently dropped.

What a ruling does

A flagged result waits for one of two rulings, and the row stays either way, with the note that explains it:

• score_stands — checked, and the official score is right. The flag belonged to the feed, not to the result. It stays scored exactly as it was.
• awarded — the competition decided the result off the pitch. From then on it is neither an outcome nor part of either team's rate, and it does not count toward a team's known matches.

The second is the important one. A 3–0 awarded after a forfeit says nothing about how either side plays, so scoring a metric against it would be scoring it against an administrative decision. Values already delivered for it are kept in the record; the fixture simply stops being scored.

The official score always stands as the score. The event tally is a check on whether the published result is trustworthy, never a second opinion that can overrule it. A flag asks a person to look; it never rewrites a scoreline.

Because every scoring run rebuilds the season from scratch, a ruling made today reaches every week that follows it — and the weeks already published stay as they were, because snapshots are appended and never recomputed.

What is published, and what is not

Published, to everyone:

• the fixture list, the team registry, and every deadline;
• the board: each published participant's newest week;
• every published week of every published participant;
• for each of them, the five pair counts per horizon, for the participant and for the goals baseline on the same fixtures — enough to recompute every figure.

Not published:

• any participant that has not been confirmed for publication, including the Arena's own model until it has been scored — and its page answers the same 404 as an id that does not exist, so nobody can learn who has entered by walking ids;
• any participant's delivered values. What a vendor priced a match at is its own; what is published is what its ordering achieved;
• contact addresses, which exist so the Arena can write to a participant and are never on a board;
• any identifier belonging to the supplier of the underlying match data.

Where the numbers come from

Match results and the calendar come from commercial football data feeds, collected daily and validated as above before anything is scored against them. The supplier is not named on these pages, and no published identifier reveals one. A participant integrates entirely on Arena ids, so nothing about your integration depends on which supplier sits behind them — and nothing about the benchmark advantages a participant who happens to buy from the same one.

What to read next

• Scoring — how a validated result becomes a score.
• Delivery contract — how to deliver against this data.
• Onboarding — the whole path, in order.