The planner's counterfactual
A radio access network planner sizes a metro cluster eighteen months ahead. The forecast rests on a traffic mix estimated from the previous two quarters: voice, messaging, video streaming, background sync, weighted by time of day. Capacity is provisioned to keep physical resource block utilisation under 80 per cent at the busy hour. Six months after commissioning, a messaging application pushes a codec update. Average session payload roughly doubles overnight for users of that app. Utilisation crosses 80 per cent within weeks; congestion alarms fire in the cluster's densest sectors; customers churn.
The planner is asked the question that follows every failure of this kind: what would utilisation have looked like had the release not shipped, or had the capacity plan flexed to absorb it? That is a counterfactual. It cannot be checked against the world, because the world in which the release did not ship, or in which capacity was added on schedule, never occurred. Answering it well or badly has consequences — for the post-incident review, for the next capacity model, for whether the planner is blamed for a forecast that could not have anticipated a decision made inside someone else's release pipeline.
Two positions, both defensible
There are two ways to think about what the planner needs, and they pull in different directions.
The first position says: counterfactuals are answered by models, not by watching the world. Give the planner a validated traffic model with correctly estimated parameters — arrival rates, session duration distributions, codec-to-byte mappings — and the counterfactual is a re-run, not an observation. This is how telecom capacity planning has worked for decades: quarterly traffic studies, feed a queuing or simulation model, project forward. The model does not need to be live. It needs to be right.
The second position says: the traffic model is only as good as the state it was fitted to, and that state has already moved by the time the counterfactual is asked. The planner is not asking about traffic in the quarter the model was built from. He is asking what utilisation would be now, under a hypothetical that differs from now. Abduction — recovering the actual state at the moment in question — requires a state that is current, not a state that was current when the study ran. A model fitted on Q1 telemetry and queried in Q3 is abducing from the wrong world.
Neither position is wrong. They are answers to different questions, and the domain keeps generating both kinds.
What the Pearl recipe actually demands here
Judea Pearl's structural account gives the dispute a shape. Counterfactual evaluation runs in three steps: abduction, fixing the background state from what is actually known; intervention, altering one variable in the causal model; prediction, integrating forward from the altered state. Each step has an intake requirement specific to this domain.
Abduction needs the actual traffic mix, sector by sector, at a resolution finer than the quarterly study — telemetry sampled every fifteen minutes across radio bearers gives that, but only if the planner's model ingests it continuously rather than as a seasonal snapshot. Intervention needs a causal structure linking application-layer events to bearer-level load that has not silently drifted — codec changes, app version splits, and handset mix all move that mapping, and spectrum filings and fault alarms carry information about capacity ceilings that the traffic model alone does not encode. Prediction needs the model to be run from a state that matches now, not from the state that happened to be measured when someone last commissioned a study.
A frozen quarterly snapshot — the Large Language Model position, translated into this domain's terms — can narrate what usually happens when traffic mixes shift, because it has seen many such shifts described in past reports, but it has no access to this cluster's actual state at the moment the codec update landed. A model bounded to a single observed episode — commissioning day telemetry, one busy-hour trace — can abduce properly within that window and answer the counterfactual soundly for that window, but the answer expires when the window closes; ask it about a shift that happened four months later and it has nothing to abduce from. The position that holds traffic telemetry, fault alarms, spectrum filings and churn signals continuously, with timestamps and provenance, and revises its estimate of the causal mapping as each stream updates, is the only one that can reconstruct the actual state at the moment of the codec release and integrate forward to the present utilisation figure. That is the requirement the domain imposes, independent of what any particular deployed system actually does.
First objection: the model, not the world
Traffic engineering has run on periodic studies for forty years. A well-specified queuing model with correctly measured parameters answers "what if this codec update had not shipped" perfectly well from last quarter's data. Continuous telemetry is convenience, not necessity.
This is right for a whole class of question. If the counterfactual concerns a past, closed episode — what utilisation would have been in March had the update shipped in January instead of March — the model needed is the one fitted to March conditions, and it can be entirely offline. Post-incident reviews routinely do exactly this, re-running a frozen model against an altered input, and the answer is not weakened by the model's age, because the question and the model both live in the same historical moment.
The requirement bites when the consequent is evaluated against the present or the future: what is our position now, what would happen if we added the deferred capacity next quarter given how the mix has since moved again. There abduction must reach a state that postdates the model's fitting, and the causal mapping — bytes per session by codec, sessions by device class — must not have drifted since estimation without that drift being caught. A capacity model estimated in Q1 and queried in Q3 without refresh is not wrong about Q1. It is being asked a Q3 question with Q1 abduction, and that mismatch is precisely the mechanism behind the original failure. Offline models answer historical counterfactuals well. Live counterfactuals need live intake, and most of the questions that matter to a planner — what should we do now — are live.
Second objection: streams give correlation, not cause
Fifteen-minute telemetry at scale gives volume, not causal structure. No amount of passively watching PRB utilisation rise after a codec update identifies whether the update caused the rise, or whether both were driven by a third factor — a marketing campaign, a competitor's outage diverting roaming traffic, a seasonal event. Continuous observation multiplies data, not evidence.
The identification problem is real, and no telemetry rate dissolves it. Passive correlation between app release timing and load increase is consistent with confounds that a planner cannot fully rule out from observation alone.
What continuous intake changes is the supply of usable natural experiments. A staggered app rollout — codec update reaching device population in tranches across three weeks, as most large platforms do for exactly this reason — is a near-randomised intervention if it is caught with pre-period telemetry for the untreated tranche and post-period telemetry for the treated one. A frozen quarterly study catches perhaps one such rollout by accident. A continuously ingested stream catches it as it happens, with a genuine control group sitting in the same fifteen-minute telemetry window. Fault alarm correlations with spectrum filing timelines — a competitor releasing new band capacity, shifting roaming load — are similarly only usable as quasi-experiments if the baseline before the shift was actually recorded. Continuous intake does not manufacture causal identification from nothing. It preserves the identifying events that would otherwise pass unrecorded, and it is these staggered, partial, accidental interventions — not the passive volume of the stream — that do the causal work.
Where this settles
The resolution is narrower than either position wants. Offline, well-parameterised models remain the right tool for closed historical counterfactuals, and telecom capacity planning will keep using quarterly studies for exactly that class of question without loss. The requirement for continuous, provenance-carrying intake across traffic telemetry, fault alarms, spectrum filings and churn signals bites specifically at the two places where the domain currently fails: abducing a state that matches the present rather than the last study date, and catching staggered rollouts and discontinuities as quasi-experiments while they occur rather than reconstructing them badly afterward.
Neither concession rescues the strong claim that watching everything lets you see the road not taken. It does not, and no stream rate changes that. It narrows, considerably, the range of telecom counterfactuals for which a planner is stuck guessing rather than computing.