The Expected-Runs Ledger: Where the Model Fails in Bangladesh's Home T20 Cricket

Introduction: The Unease of a Scoreboard

I watched that match at the Sher-e-Bangla Stadium twice — once live, once on replay. Bangladesh were bowled out for 142. The opposition chased 145 with six balls to spare. The scoreboard says an easy defeat. But when I ran the match ball-by-ball through the expected-runs (xR) sheet I had built myself, an uncomfortable number surfaced: on that pitch, in that batting context, Bangladesh's expected runs were 138. We performed four runs better than the scoreboard suggested — and still lost.

That is the centre of today's piece. Over the past few years, most of the hot takes I have read about Bangladesh's home T20 cricket — on social media, on talk shows, even in some respected columns — are scoreboard-driven. Some claim the home pace attack has 'returned'; some claim spin-dependence is 'over'; some make big workload claims off a single spell. Today I want to test those claims the way I would audit a ledger — provenance first, sample size second, model assumptions last.

Let me be clear: this is not a prediction, and there is no single-match 'truth' here. This is an audit trail. The lesson I learned auditing every shot of the 2026 World Cup xG is what I am now translating into cricket's expected-runs and expected-wickets metrics.

Context: Why Home Data Must Be Read Separately

One thing must be settled first. Bangladesh's home cricket data cannot be compared directly with data from anywhere else. There are three reasons, and all three are material — drop them and the entire calculation goes wrong.

First, the pitch. Dhaka and Chattogram wickets are typically slow, and spinners get extra purchase gripping the ball. Strike rates sit below the global average — fewer runs per over, more wickets. If an expected-runs model is calibrated on 'neutral' pitches, it will systematically understate batsmen in Bangladesh.

Second, fielding restrictions and outfield speed. Some home outfields are small, but with lower ball speed boundaries arrive on 'well-timed' shots rather than brute force. So a boundary-based metric looks one way from the outside and behaves differently on the ground.

Third — and most neglected — crowd and scheduling. In 2026 I worked on Bundesliga behind-closed-doors matches, comparing 306 pre-COVID matches with 92 post-restart ones. Home win rate fell from 43.3% to 33.3%, and home expected goals per game from 1.54 to 1.31. But I warned then that 92 matches are not enough to rewrite home-advantage theory. That lesson applies even more strongly to cricket, where variables multiply: ball condition, dew, light meters, even crowd-fill patterns.

So my first question on any home-cricket analysis is: which variables did you include, which did you drop, and why?

Core Analysis: Three Failure Modes of the Expected-Runs Model

In 2026 I built a manual xG sheet for the Bangladesh Premier League, which I later used at the 2026 World Cup. Porting that structure to cricket reveals three places where the model stumbles repeatedly. I call these failure modes, because they are not random error — they are systematic.

Failure mode one: expected runs is context-blind.

Say a batsman scores 28 off 30, and the model says his xR was 35 — meaning he 'underperformed'. But if he scored those 28 during the toughest phase, when the ball was swinging and three fielders were in the ring, the model's context is wrong. If expected runs are not pitch-specific and phase-specific, the number is just an average, and judging an individual innings by an average is a methodological error.

Failure mode two: delivery quality is ignored.

The biggest gap in cricket's expected-runs model is that delivery quality and field setting are not encoded. Football's xG captures shot location and assist type, but in cricket, if a ball lands in the rough and the batsman punches it through mid-wicket for four, the model usually reads only the shot zone, not the ball quality. The result: in low-scoring subcontinental conditions, skilled batsmen are undervalued.

Failure mode three: weak linkage between expected wickets (xW) and expected runs.

In an innings, wickets usually push the run rate up, because a new batsman arrives and fields come in. But on a spin-friendly Dhaka pitch the opposite happens — wickets bring tail-enders who drag the rate down. If xR and xW are run separately, the innings narrative comes out wrong. These two models should be run together, in a joint distribution — at least in home cricket.

The Ledger of Numbers: What Is Actually Seen

Now let me summarise what is in my home-ground workbook. Remember, these are my own match-by-match tracks, and the sample is small — so these are signals, not proof.

In Bangladesh's home T20 innings, the run rate in the first powerplay (overs 1–6) usually sits below 7, and in the middle overs (7–15) it drops further. But in the last five overs (16–20) the rate jumps — fielding restrictions and risk-taking. The question: is this pattern 'Bangladesh batting weakness' or 'the pitch's natural character'?

When I tracked opposition innings the same way, I found the same pattern — slow powerplay, fast death overs. So the pattern is not team-driven, it is pitch-driven. Miss that distinction and an analyst reaches the wrong conclusion — he blames the batsman for the pitch.

Add another number. When I computed ball-by-ball run value for home matches — the expected runs after each ball — the gap between expected and actual runs was largest in the first 10 overs. Batsmen were doing 'better than the model' early because the model expected too much of them.

Spin versus Pace: An Oversimplified Debate

Now to the hot take that irritates me most: 'the home pace attack has returned.' I dislike this claim because it usually conflates two things — 'pace succeeded' and 'pace did better than spin.'

Home pace success depends heavily on the new ball. If it swings or seams in the first 4–5 overs, pacers take wickets. But as the innings ages, the pitch slows and spinners gain influence. So 'pace has returned' really means 'pace works with the new ball' — true almost everywhere. Nothing new here.

What is actually new and unspoken: the dew factor and its link to workload.

One pattern keeps returning in my workbook. In evening matches, when dew sets in, spinners lose grip and the ball skids onto the bat for pacers. Captains may lean on pacers in the closing overs. If those pacers play back-to-back series, their workload rises — and here comes my favourite subject: workload risk.

Workload Risk: The Ledger Nobody Keeps

As a Transfer Market Administrator, my experience says clubs and boards disclose only the injuries that suit their stock. Medical confidentiality means fans and media are blind. So I keep my own workbook: which pacer played how many consecutive matches, how many overs, without how many days' rest.

One number stuck with me: in a home series, if a frontline pacer bowls 14–16 overs across four matches with fewer than three days' rest between, his acceleration decline — the rate at which he can hit top pace — drops noticeably in the next series. This is not a guaranteed injury forecast; it is a risk signal. But nobody on a talk show keeps this ledger.

Here I am careful: my sample is small and my speed-measuring tools are limited. So I do not claim — I only ask: if a dew-dependent match plan increases the load on pacers, is it sustainable?

The Contrarian Angle: Correlation Is Not Causation

Now to the section where my ISTJ instinct shouts loudest.

Over recent years I have seen analyses claiming 'teams that score more in the powerplay win more matches.' The number may be true, but the explanation is usually wrong. Correlation is not causation. Good teams score more and also win more — because they are good. There is no direct causal link between 'more powerplay runs' and 'winning'.

There is a subtler trap. At home, captains often win the toss and bowl first, because dew makes chasing hard. So 'teams batting first win less' — read that number and you might conclude 'batting first is bad.' But it is really the joint effect of toss, dew and pitch. If you look only at 'bat first versus bat second' and drop the dew variable, you land on a false conclusion — and sell it as data-driven.

Add survivorship bias. We analyse matches that are televised or have easily available data. Low-coverage matches drop out. So our sample is selected, not random.

In 2026 I worked on Italy's Euro press and learned that you cannot be sure about a new meta until you have watched seven straight matches. In cricket it is harder, because format, pitch and schedule all differ. So before making big claims about Bangladesh's home cricket, my question is: how big is your sample, and how was it selected?

Data Provenance: Why the Ledger Matters

Working as a Transfer Market Administrator, I see repeatedly that a fee is never just a number. Behind it are contract, date, incentives, sell-on clauses. Data is the same. Behind an xR number or a speed figure are: who measured, when, with what tool.

That is why I think the idea of a verifiable, immutable ledger matters in cricket. If a pacer's workload record — his overs per match and rest days — lived in an immutable ledger, a club could not simply erase it. This is not hype; it is a natural consequence of data provenance. Just as football's transfer ledger remembers fees and dates, cricket's workload ledger should remember bowling loads.

But I am careful here too. Technology alone is not a solution. If data is recorded wrongly, an immutable ledger only makes the error permanent. Technology does not protect you from bad data; it only protects you from data being erased.

A Small-Budget Pipeline: How to Start

I am a budget-conscious analyst. I have no black-box tool, and no budget to use one. So here is what I say — to start analysing home cricket you need three things, none expensive.

One: a spreadsheet. Four columns per ball — over, bowler type (pace/spin), shot zone, runs. That alone lets you see pitch-driven patterns.

Two: a fixed minimum threshold. I say at least 15 innings. Below that, numbers are just noise.

Three: a context column. For every match, note — dry or wet pitch, dew or not, day or evening game. That column makes your model context-aware.

What You Cannot Say — And That Is the Most Useful Part

At the end of every data analysis I keep a mandatory paragraph stating what the numbers do not prove.

For this piece: my home tracking is a small sample and relies on a single observer's (my) recording. I did not measure bowlers' release speeds or ball revolutions — those cannot be hand-measured. The workload-risk signal I see is not an injury forecast; it is only a basis for asking a question. And most importantly — however good an expected-runs model is, it is a probability, not fate.

Not a Conclusion, But a Signal for the Next Round

So what will I watch next series?

I will watch whether the gap between expected and actual runs in the first 10 overs narrows. If it does, the model is slowly learning the pitch's reality, or batsmen are adapting.

I will watch which bowler type captains choose once dew sets in, and how many consecutive matches those bowlers play. That is where workload meets tactics.

And I will watch whether the easy story 'batting first loses' returns, and whether anyone mentions the dew variable when telling it. If they do not, I will know the analysis is not a ledger — only print.

I leave you with one question. In home cricket we have read scoreboards for years — but how often have we actually read the ball-by-ball ledger? Perhaps the answer is: almost never.