Silent Failure: The Empty Return of Cricket Analysis

It is twenty-two minutes past midnight. I am on my balcony in Dhaka, watching the same match recording for the fourth time — the seventeenth to the twentieth over of the second innings, the stretch where the match actually turned. On the laptop beside me, a spreadsheet column I had been filling for three weeks came back empty tonight. Not zero — empty. On a screen these two look identical, until you ask which one you are looking at. Zero means I counted and the result was nothing. Empty means I could not count at all. The scoreline tells you who won; the scoreline never tells you whether the data underneath it ever actually arrived. In my profession this distinction is the biggest one, and the least discussed. Cricket analysis today runs on two tiers. The first tier breaks raw material apart — who bowled which over, how much the ball deviated off the seam, which shot went to which field placement, who made which decision, when each wicket fell. The second tier joins those pieces into meaning — why that over was the hinge of the match, why that field change was the real cause, why that bowling switch failed. I work across both tiers myself. In 2026, with stadiums empty and the Bangladesh Premier League suspended, I was working part-time as a video analyst at Bashundhara Kings. That is when I understood that the strength of analysis lies not in its second tier but in its first — in whether the raw information actually came up cleanly. The second tier never knows more than the first. It is a simple rule, and the most frequently forgotten one. If the first tier returns empty, the second is helpless. It either goes silent, or it fills the gap with inference. The second option is dangerous, because inference looks exactly like analysis — clean tables, tidy headings, believable averages. But if every cell in the table is a guess, then it is not analysis; it is decoration. A cricket scorecard looks complete in the same way, yet if one column inside it was never truly counted, the whole picture becomes false. My first principle is this: when there is no information, write it plainly — "insufficient information, assessment impossible" — and never fill the gap with inference. I call this null handling. Cricket writing almost never practices it. We do the opposite. We watch seven balls and declare that a bowler has recovered his form; we watch two innings and declare that a batsman collapses under pressure. And we never write how many balls that claim actually rests on. Over the last six years I have built one habit: I watch every tape three times before I start writing. First pass for the eye, second for the scorebook, third for the diagram. Without those three passes I reach no conclusion. In the halted 2026 season I coded 312 set-piece sequences — empty stadiums, a suspended league, and still I counted, because an empty season also deserves a pulse. Of those 312, forty-one percent of goals came from second-phase corners. That is a numerical claim, not a feeling. The coach took two routines from that data, and in the next competition the club converted three from them. This is where I need to stop, because the problem I am describing is not a problem on the field; it is a problem of the data system. And its solution has arrived from outside cricket — from the core idea of the blockchain. Seen through a sports journalist's eyes, a blockchain is not a currency; it is a ledger — a ledger where every entry is timestamped, cannot be altered once written, and can be verified by anyone. That is precisely what cricket data needs. Who recorded which ball, when, and from which source — if that chain stays intact, an empty column and a genuine zero can never merge into one. I am thinking about this because cricket data has reached its most unstable point. Five different sources give five different numbers for the same match — four boundaries or five, seventeen dot balls or nineteen. Small discrepancies, but if you build a strike rate on top of them, you get a wrong strike rate. And if you then declare, on top of that wrong strike rate, that a batsman's intent has increased, you have made the same mistake twice. The solution is provenance — a birth certificate for information. Every number should carry: who recorded it, when, from which video frame, and which verification step it passed through. An immutable, blockchain-style log can provide that certificate. And it has real utility in cricket. DRS decisions are contested — did the ball pitch in line, where was impact, where was the stump line. If those three parameters lived in a timestamped, auditable log, the argument would shrink. Half of our quarrels about umpiring come from a lack of transparency, not from corruption. Let me be clear about one thing, because otherwise I will be misread. I do not see the blockchain as a device on a cricket field. I see it as a behaviour — preserving the evidence before making the claim. It is a kind of procedural honesty. And that honesty is required in my own work too. I publish my own error rate. After every tournament I check my earlier predictions against the outcome — how many held, how many did not. I built this habit in 2026, while writing a five-part series on Denmark's Euro run. After Christian Eriksen's cardiac arrest I tracked Kasper Hjulmand's rebuild for six weeks — from two group-stage defeats to the semifinal. I published the final part before the quarterfinal, with the prediction, not after the result. That series drew 210,000 reads. But the real gain was not the readership; the real gain was that I placed myself in a position where the power to catch my own error passed to others. This pre-commitment, this publishing of predictions beforehand, and this source transparency — all three belong to the same system. When there is no information, say so. When there is information, say where it came from. When you predict, say when you predicted. Do these three and an analysis becomes verifiable. Skip them and it merely looks credible — it is not verifiable. Now to the direction I see most often and fear most. When the first tier returns empty, a system that then reports "no risk found" is lying. The correct statement is "no information found, therefore risk could not be assessed." The difference between the two is vast, yet on a dashboard they look the same. A green light comes on. And once a green light is on, people stop asking questions. I say this from a specific experience. When I received an empty dataset, my first reaction was discomfort, then temptation — to fill the empty cells from my own memory. I know what that match was like. I saw it with my own eyes. So what is the harm in writing from memory? The harm is this: it would not be data, it would be my memory. And memory is selective. Memory keeps that one catch; it forgets the seven chances dropped before it. So I follow a three-count rule: a claim may use at most three denominators, no more. Count more and the reader is lost in a forest of numbers; count less and the claim does not stand. This rule is the brake on my denominator discipline. Because the addiction to counting is a genuine hazard — at some point you are counting so much that there is no time to write, and the reader is lost too. Following that rule, let me describe a match. A T20 second innings that required twelve an over in the death. The first three overs yielded eight. Then a bowling change. Sitting in the ground I thought the change had come too late. But the diagram showed the change had not come late — the delay was in the field setup. The new bowler arrived, but the long-on fielder was still standing where the old bowler's line and length did not match the new one's. So the new bowler's first two balls went fine, but from the third the batsman found his space. The hinge of the match was not the bowling change; it was the two-ball lag in the field setup. No scorecard records that lag, no highlight shows it. Yet in the death overs two balls are worth nearly four runs. This is the place where data and eye are needed together. The eye alone would say "too late." The data alone would say "the bowler did well." Together they say the real thing — the system moved slowly, not the individual. From here I want to draw a larger point that applies to the entire craft of cricket analysis. We do not usually suffer from a lack of data. We suffer from a lack of data credibility, and from confusing that with a lack of data. A single match contains information on a thousand balls. The problem is not the quantity; it is the chain. Who gave which piece, which is verified, which is inferred — without that question, even a vast dataset is dark. And this is where the blockchain's lesson is most relevant. The blockchain teaches me that the value of information lies not in its quantity but in its immutability. If a number can be changed by anyone, it cannot be the basis of analysis. The same holds in cricket. If one run becomes three different runs across three sources, averaging it produces not an average but a conjecture. Thinking this through, I have arrived at a position: every cricket source should carry its own audit trail. Who wrote it, when, from what observation, and whether that information was later changed. If a source quietly revises its earlier numbers again and again, it should not be trusted. This verification is hard, but without it analysis is a pyramid without a base. I know some will say this is overreach. Cricket is for enjoyment, not for ledgers. I do not accept that, because enjoyment and understanding are not opposites. To appreciate the beauty of a catch I do not need to know which frame it fell in. But to explain the beauty of an innings I do need to know where each of its numbers came from. Otherwise I am not explaining the beauty; I am explaining my own idea of it. Now to the place where my own method stands against me. I have spoken of the transparency of information. But transparency alone is not enough, because a verifiable piece of information can still be wrong. Who guarantees that the dataset in my hands was extracted correctly? If the extraction tier itself fails silently, the entire second-tier analysis stands on an empty foundation. And the frightening part is that analysis standing on an empty foundation looks just like analysis standing on a solid one. This is why my greatest fear is not inference; my greatest fear is silent failure — a failure that does not say it is wrong, only returns empty. A wrong result at least shouts. An empty one stays silent. And silent data is the most dangerous, because it wears the disguise of completeness. Here I want to catch a common error in my craft. We praise data but do not verify its source. We say "the data shows this team is ahead." No one asks who gathered that data. Yet a flawless table from a bad source is more dangerous than an honest inference, because an honest inference admits its limits; a flawless table does not. Saying this, I think of my own older writing. How many times I wrote a number without verifying it, only because I had seen it elsewhere. How many times I wrote a trend on a three-match sample, when my own rule demanded at least ten. This admission is a debt paid to my reader. If I do not publish my error rate, my claim to be right is worthless. Here I reach a hard truth that many cricket analysts avoid. We distrust eyewitness testimony because it is not modern. But between eyewitness testimony and unverified data, which is more dangerous? The answer is clear: unverified data. The eye at least admits it is subjective. A raw dataset claims to be objective, yet it was coded by someone's hand, seen by someone's eye, trimmed by someone's decision. Therefore my contrarian conclusion is this: the story of data neutrality is often a myth. Data is not neutral; data is made by someone. The question is by whom. An analyst who does not ask this does not use data; he believes in data. And belief and analysis are not the same. In this connection, my second great fear — the temptation of template-filling. Once a framework exists, pressure builds to fill its empty cells. No one wants a section left blank. So into the blank space slip probable names, probable numbers, probable decisions. The framework looks complete, but its content is invented. I call this the mild version of fabrication — not outright falsehood, but probability in place of verification. I accept this charge against myself. My original profession was video analysis, where every frame is counted. That habit has sometimes led me to push numbers into places where what was needed was an honest emptiness. For a coach, the most valuable information can be this sentence: "Here we still do not know." Because knowing the boundary of the unknown lets a coach build a way to measure it in the next match. I do not want to stop here, because the problem has a practical side. If we accept that silent failure is a real hazard, the solution must also be procedural, not moral. Morality says "be honest." Procedure says "close the path by which an empty cell leaves the system." A blockchain-style log does exactly this. It does not rely on honesty; it reduces the opportunity for dishonesty. Imagine a cricket data system where every entry carries a hash. Change an entry and the hash changes; change the hash and it is caught. Then no one can silently alter a number. Such a system is not fantasy in cricket; it is a necessity. Because our game is now a billion-dollar commodity in a global market, and every accounting in that market stands on information. A budget built on wrong information is a wrong budget. I know someone hearing this will say it has drifted away from cricket, that it is a talk about technology. I say the opposite. Every strategic decision in cricket is an information decision. Which bowler to keep for the death — an information decision. Whom to send in the powerplay — an information decision. When to bring on spin — an information decision. If these decisions stand on wrong information, the coach loses on the field and never knows why. Now back to that empty column that night. I did not fill it. I left it empty and wrote beside it why. The next morning I found the source, re-ran the extraction tier, and saw that the failure was not in my analysis but in my pipeline. The information existed; it had not reached my hands. Had I filled the column from memory, I would never have known my pipeline was broken. This is the biggest lesson for me: before filling an empty cell, ask why it is empty. Sometimes the cause is a genuine zero. Sometimes the cause is a broken pipe. The two are not the same, and treating them as the same sends the whole analysis in the wrong direction. Let me state plainly something I have not written before. The future of cricket analysis is not better data, but verifiable data. The difference is subtle but large. Better data means more numbers. Verifiable data means a certificate behind every number. The first increases quantity; the second increases trust. And in a game where one ball changes the fate of a match, trust matters more than quantity. I give my prediction in advance, not after the result. Within the next year or two, the verification of information sources in cricket will become a distinct subject — just as DRS once became one. Those who start keeping a certificate for every number now will accumulate the most valuable asset of the next era: trust. Those who keep arranging tables from unverified numbers will build beautiful pyramids, but on foundations of sand. My whiteboard teaches me this — the whiteboard does not give answers; it asks better questions in lines. And the best question today is this: which cell of your scorecard was actually counted, and which was arranged? You can ask it of yourself in the next match, before you find an empty column in your hands, as I did.