Blank Tape, Empty Codebook: An Autopsy of Silent Failure in Cricket's Data Pipeline

Two in the morning in Kolkata. The spreadsheet is open and eight of its nine rows are blank. This is the Stage-1 output — the stage that is supposed to hand me an article's title, source, one-sentence summary, information points, entities and time-sensitivity. Title: N/A. Source: N/A. Summary: empty. Information points: the entire section is bare. Entities: unidentified. In the ninth cell there is one word — cricket_world.

Three hours ago there was a piece that needed writing. Now there is a piece about why that first piece could not be written. Thirty years in this trade teach you that a scorecard does not lie, but neither is it the whole truth. Tonight the scorecard has no rows at all, and for the moment that is the whole truth.

An autopsy begins where the scorecard stops explaining. This one never started.

Context: what the pipeline does, and what its silence costs

Cricket copy now passes through three stages. First, raw text pulled off a page. Second, structure — where a machine decides which part is fact, which is claim, which is mere typography. Third, analysis. Stage-1 is that second stage. Its job is not to think. It is to sort.

The trouble is that the sorting machine does not make noise when it fails. It returns a clean, syntactically valid, entirely empty structure. No error code, no red light, no log line admitting that nothing was found. The person downstream reads that empty shell as processed data and keeps walking.

I have met this in cricket many times. Beside the commentary box sits a screen running the ball-by-ball feed. When the feed stalls for two overs, the screen does not go blank — it keeps displaying the last score. The viewer assumes all is well. That is the definition of a silent failure: the error is invisible, therefore it is never counted.

And counting matters, because a pipeline's output is no longer one article. It is dozens of downstream cuts — thumbnails, headlines, notifications, auto-summaries. One empty field at the top breeds a whole family below.

Core: three failure modes, and cricket's own vocabulary for nothing

In my experience the gap arrives in three shapes, and each looks different.

One: the raw text itself came back empty. The page rendered by script, the body sat behind a paywall, or the scraper reached only the headline page. In cricket's language, this is a scorecard that contains only the toss line. You cannot build a story from it, because a story needs deliveries.

Two: you were handed a list instead of an article. Frequently the pipeline picks up a fixture list or a homepage and mistakes it for a report. That is the same offence as writing a match report from a series schedule. I have seen it on the desk — a preview built from a fixture that does not contain one sentence about the team it is about.

Three, and the most dangerous: the model's output was truncated, the JSON parsed, and the system quietly degraded to an empty structure. Nothing breaks. The report says the run succeeded. It is rather like Duckworth-Lewis handing you a revised target without telling you how many overs it counted and how many wickets it assumed in hand. You get a number. You do not get confidence.

One observation belongs here, because it is the most useful thing in this whole episode: cricket is probably the only sport with a formal vocabulary for nothing having happened. A single scorecard can carry three distinct kinds of absence — did not bat, retired hurt, absent hurt. One batter never got in. One got in, got hurt, and came back off. One never reached the ground. Cricket refuses to fold those three into one box.

Our pipelines do not share that discipline. They treat 'no data' and 'zero' as the same value. In cricket those two were never the same. 13 June 2026, Trent Bridge: India against New Zealand at the World Cup was lost to rain. No result. Yet both sides took a point from it, and the table moved. More than one match that tournament ended without a result, and every time the standings shifted. Zero and unavailable — cricket never files them together.

The habit was set in 2026. India won the World Cup at the Wankhede on 2 April, and I was a night-shift sub-editor on a Kolkata sports desk, eight years into the job. Over the eleven weeks that followed I rewatched all 49 matches on archived feeds and hand-coded more than 24,000 deliveries into a single Excel workbook. I rewatched the tape until the spreadsheet confessed. The finding: India's run rate between overs 15 and 35 was 5.12 against a tournament rate of 5.41 — the middle of the innings was where they were slow, and that fact was nowhere in the story of the win. Yuvraj Singh's 362 runs and 15 wickets together produced the highest impact score of the tournament.

Every row in that workbook was touched by a human. Today's pipeline touches no row, and that is the whole difference. 23 July 2026, Lord's: England 228 for 7, India bowled out for 219, beaten by nine runs. India were 191 for 3 in the 43rd over; the last seven wickets fell for 28. The phase-collapse chart was built and double-checked within five hours of the final ball, while the desk was still stacking reaction quotes. I would not file without rewatching overs 44 to 47 a second time. That night settled it: the replay did not change; my coding sheet did.

One more thing belongs in print, and every data reporter should write it. An empty dataset is the only bias-free dataset in existence — no stars, no favourites, no broadcast weighting. It is also, for that exact reason, useless. Whenever I reach a conclusion I deliberately build a control group of low-coverage players — Ranji top-scorers, WPL squad players whose names never make a headline — and check whether the finding survives outside the spotlight. Tonight my dataset is so bias-free it contains no players at all.

Contrarian: my refusal is also an editorial decision

Now the case against my own side, because that is the rule of the trade.

The flattering version: the analyst refused to invent facts. The less flattering version: nine times out of ten the fix is human, not architectural — somebody forgot to paste the body text, or ran the wrong URL. Saying 'the pipeline is broken' is easy. Saying 'I did not check' is hard. I should have asked myself first whether I had measured the raw text length before blaming the model. I had not. So the primary hypothesis should have been that the fault was mine until proven otherwise.

Second, not publishing is not neutrality. The slot existed and it got filled — possibly with worse copy than mine. A pipeline I distrust will be replaced by one I distrust more, and this one will not keep quiet about an empty field; it will speak with full confidence. Blank paper is the more honest option, and honest is not sufficient.

Third, the empty result applies to my own back catalogue. The last time I drew a conclusion from an old ball-by-ball file, did I write down how many overs were simply missing from it? I did not. Sample size and excluded cases belong in the same paragraph as the finding, or the finding is itself a symptom of the disease I am trying to treat.

Takeaway: count the rows, not the conclusion

One rule comes out of this, and it is a rule of discipline rather than technology: every pipeline should print its row count alongside its output. A run that produces zero rows should set off an alarm, not a shrug.

The next time you read a data-driven cricket piece — be it a bowler's pitch map or a selection-impact model — ask two questions. What was the sample size, and which cases were excluded? If there is no answer, assume the third failure mode is sitting quietly inside it: everything looks clean, and the bottom row is blank.

How many cricket reports last month were built on a field that was empty, and nobody counted?