Three Numbers That Stop Before the Analysis Begins: Cricket's Data Integrity Wall

I opened the packet at the Sydney desk around eleven at night. Inside were ball-by-ball logs for 84 matches, scorecard summaries, a player-ID mapping sheet, and a short methodology note. Before starting Stage-2 analysis, I followed my old habit of reconciling totals first — the ledger before the story. Three rows did not reconcile. The first row had the same bowler sitting under two different IDs. The second counted an abandoned match as completed. The third had the third session of a day-night match filed in the wrong date bucket, because the packet stored time in the venue's local clock, not UTC. Three flags went up. The gate closed. In cricket, Stage-1 is collection and Stage-2 is dimensional analysis. A verification gate is needed in between, because every Stage-2 model treats the definitions of Stage-1 as true. A scorecard is a ledger, not a lottery — but ledgers can be written wrong, and a model built on a wrong ledger may look beautiful and still only be beautiful, not true. The Kazan files gave this gate its origin in 2026. After France beat Argentina 4-3, I built a post-match model: France's PPDA 7.1 against Argentina's 12.4; xG 2.8 to 1.9; Kylian Mbappe's top speed 36.2 km/h; distance covered 112.4 km to 108.7 km. A one-page match-truth sheet went to the producers and was used live. That day I learned numbers can standardise a narrative — but only if the numbers count the same object. Since then every piece I write opens with a fixed metric box. The box has one condition: the identity of the inputs must be stable. Where both team names are wrong, measuring PPDA is meaningless. In 2026 the empty stadium taught me that absence has a pattern too. As transfer market administrator at Sydney FC, I ran a model across 84 matches: without crowds, home advantage fell from 0.45 xG to 0.12 xG. That model rested on match status — which fixture was completed, which abandoned. Had abandoned matches been counted as complete, the 0.12 figure would have shifted silently, and nobody would have noticed. I should name my vantage clearly here, because I live between two cricket cultures. I grew up in Bangladesh, where the scorecard is treated almost as scripture; I work in Australia, where the scorecard is a file whose every line is open to question. This piece is the Australian habit of questioning applied to the Bangladeshi object of reverence. First flag: identity. In a database a name is a string, but a player is a person. Shakib Al Hasan has moved through several spellings — Shakib Al Hasan, Saqibul Hasan; Mushfiqur Rahim's name has variants on record; Steve Smith appears in many places as SPD Smith; Pat Cummins has been filed in abbreviated form. Joining IDs by string match splits career aggregates in two, distorts averages and strike rates, and both halves look credible on their own. The reliable method is one: map by date of birth, team and debut date, not by name. Second flag: the definition of a match. The packet carries a two-state status — played or not played. Reality has four states: completed, abandoned, no-result, tied. Assuming a match is complete because a scorecard exists is the cleanest error of all, because abandoned matches leave partial scorecards behind. This error moves the denominator of win percentage, the toss-impact calculation and the home-advantage model. Third flag: time. A day-night match's sessions cross midnight, and if the packet stores time locally, third-session wickets land in the next date bucket. Decisions like more wickets fall in the evening then tilt the wrong way. The fix is simple: keep UTC and venue offset in separate columns, and bucket by innings rather than by calendar date. I trust the timestamp before the rumour, because a timestamp does not try to lie — it only shows the wrong clock. Beyond these three flags I reconcile an identity in every packet: batter runs plus extras equal the total; the wicket count equals the dismissal-type count; balls in an over match balls faced by the batter. The quietest error sits in bowler economy — 7.4 on the scorecard, 8.1 from the ball-by-ball sum. If byes and leg-byes are not separated, the bowler takes the blame. The fourth check is DLS par-score recomputation in result matches. If a rain-affected par score is imported from a source without verification, one wrong par score can invert the entire explanation of who won. Every flag gets a line in the gate: who caught it, when, against which public record, and what was decided. Every delivery leaves a footprint; my job is to measure it, and to date the footprint. Behind every data error sits a person. A split ID means a bowler's career average is shown wrong; counting an abandoned match as complete lowers a captain's win percentage; a wrong date bucket means a spinner's evening statistics drive a wrong call. When a dashboard's elegant chart covers that damage, the number stops being a question and becomes decoration. Here the counter-intuitive point has to be made. These three flags are not data-entry errors. The packet and the public record did not mean the same thing by a match, a player, or a day. It is a disagreement of definitions, not of digits. The real danger of Stage-2 is precisely this: wrong digits get caught, wrong definitions do not — and mismatched definitions sitting inside a beautiful model turn the whole analysis into the answer to a different question. The habit of confusing correlation with causation grows from the same root. There is another trap: a flag makes it look as if the source has been careless. Not always. If a source changes its definition mid-cycle, the flag rate rises while nobody has done anything wrong. So the gate needs tiers. Identity and match status are blocking checks, because they move denominators. The time bucket can take a provisional pass, with the flag carried into the model's footnote. In 2026 I learned to enforce a 48-hour decision deadline on every target — if verification overruns the deadline, the club does not wait an extra week. In the next cycle I will read the flag rate as a leading indicator. When the flag rate jumps in one dimension, the question is not who made a typo but who changed a definition. The packet that clears the gate flawlessly is not the good packet; the good packet is the one whose flags are written down, dated, and visible in the model's footnotes. If a fourth flag goes up in the next packet, will you delete it — or write it under the total?