The planner's dilemma
A network planner builds capacity forecasts on committed budgets and eighteen-month procurement cycles. The forecast has to be a number: so many terabits on this ring by this quarter, so many new carriers at this base station, so much backhaul provisioned before the contractors are demobilised. That number is a posterior dressed as a decision. Underneath it sits a prior — last year's traffic mix, extrapolated — and the question this page asks is what, if anything, updates that prior before the concrete is poured.
Two positions answer the question differently, and both are defensible. Neither is comfortable.
Position one: the model is only as good as its last calibration
The traditional planning discipline treats the network as a system you characterise periodically and then trust. Traffic engineering rules — Erlang tables for circuit-switched capacity, their packet-era descendants for statistical multiplexing — were built from busy-hour measurements taken at intervals measured in months. Between measurements, the model runs on its prior. This is not laziness. Recalibrating a metro transport network's dimensioning model against live telemetry every hour is expensive, and volatile inputs make for volatile capital plans, which finance departments will not fund.
On this view, a Large Language Model's condition is not a defect to escape but a feature to manage. You build the best prior you can from the richest historical dataset available — call detail records, backhaul utilisation logs, spectrum filings going back years — and you hold it fixed for a planning cycle because holding it fixed is what makes it usable. A prior that shifts under you daily cannot be turned into a five-year radio access build. Stability has a cost, borne in forecast error, and the discipline of network planning has always priced that cost explicitly through headroom margins, typically 30 to 40 percent over projected peak.
Position two: the traffic mix does not wait for your cycle
Against this sits a harder-edged operational fact. Traffic mix is not a slowly drifting quantity. It jumps. A single app release — a messaging platform switching its default media codec, a short-video service pushing a new autoplay behaviour, a firmware update changing how handsets negotiate carrier aggregation — can move the ratio of upstream to downstream traffic on a cell cluster by double digits within a release cycle measured in days, not the eighteen months a capacity plan assumes.
This is the characteristic failure named for this domain: a capacity plan built on a traffic mix that shifted with one app release. The plan was not wrong when written. Its likelihood term simply stopped arriving. The planner sized backhaul for a downlink-heavy assumption; a client update pushes short-form video with heavier per-session interactivity and higher uplink demand for real-time upload; sectors that had comfortable margin start alarming on uplink congestion within weeks, while the downlink capacity so carefully provisioned sits half-used. The prior was excellent. It stopped being a posterior over the present the moment training data — last quarter's traffic captures — was frozen into the plan.
What each generation actually offers a planner
| generation | what it holds | what fails in this domain |
|---|---|---|
| Large Language Model | a compressed history of traffic patterns, filings, fault reports, up to a cutoff | confidently answers a question about current congestion using a mix that no longer exists |
| Large World Model | live telemetry for the duration of an incident or a maintenance window | correctly diagnoses today's congestion, then forgets it when the session ends and the next planner starts from the old prior again |
| Large Universe Model | traffic telemetry, fault alarms, spectrum filings and churn signals as continuous, provenance-tagged streams, each posterior carried forward | argued category — not something a planner can currently buy, only a description of what closing this gap would require |
The middle row deserves more credit than it usually gets. Network operations centres already run live dashboards that ingest streaming telemetry and update fault probability in real time — this is a genuine likelihood term, sensed and current. Its limit is scope, not honesty: it updates while the incident is open, and the update rarely survives as revised capital planning input once the ticket closes. The dashboard knows uplink congestion spiked at 14:02. It has no mechanism for making that observation the new prior for next quarter's dimensioning model, tagged with the app release that caused it, discounted appropriately as churn signals later reveal whether the shift was permanent or a promotional spike.
That is the specific thing a continuously running intake would add: not better sensors, but retained provenance across the boundary between an incident and a plan. The traffic anomaly, the spectrum filing that later explains a competitor's backhaul lease, the churn signal that shows subscribers migrating to a rival because of exactly this congestion — held as revisable beliefs that decay if unconfirmed, rather than either forgotten at session's end or baked permanently into next year's static forecast.
The two objections that bite hardest here
The first: continuous intake does not repair a model built on the wrong variables. If a capacity model was never parameterised to notice codec-level shifts in upstream demand — if its feature set is bytes per subscriber per hour, and nothing finer — then streaming that same coarse metric forever just converges confidently on the wrong granularity faster. This is correct, and it is the deeper problem beneath the app-release failure. No amount of telemetry volume substitutes for a model that can represent "media codec change" as a causal variable at all. But notice what the objection concedes: this is a modelling failure, orthogonal to intake. A frozen model with the same coarse feature set suffers identically, and worse, because nothing in a static model ever produces the residual — the gap between predicted and observed uplink load — that would tell anyone the feature set was too coarse to begin with. Continuous intake does not fix misspecification. It is the precondition for noticing it, quarter by quarter, sector by sector, rather than discovering it eighteen months later when the fibre is already trenched.
The second objection is sharper for this domain specifically. Not all telemetry deserves equal trust. A faulted alarm feed, a misconfigured probe reporting phantom congestion, a churn signal correlated with a billing system outage rather than genuine dissatisfaction — treating every arriving stream as an independent likelihood term multiplied straight into the posterior is a route to a plan that chases noise. Operators have living memory of exactly this: alarm storms during a single core router failure that cascade into hundreds of correlated downstream alerts, each one technically a new observation, none of them independent evidence. A capacity model that updates naively on volume rather than on weighted, provenance-tagged reliability will overreact to a five-minute storm and underreact to a genuine slow drift in codec-driven upstream demand, because the drift never announces itself as loudly as the storm does.
The answer is not to stop observing. It is hierarchical: alarm feeds are weighted by a reliability estimate that is itself continuously revised — a probe with a known fault history contributes less, one confirmed against independent ground truth contributes more — and correlated faults are modelled as correlated, tagged as a single root event rather than counted a hundred times. This is exactly the discipline that keeps a Bayesian filter from diverging under recursive updating in any domain, and it is demanding to build. It is also strictly better than the alternative on offer, which is to freeze the model and let the next app release do to the plan what the last one did.
Where this leaves the planner
Neither position wins outright. The case for periodic, deliberately stabilised recalibration is not a failure of nerve — it reflects a real cost structure in telecommunications capital planning that continuous intake does not abolish, only informs. The case for closing the loop between live telemetry and the standing capacity model is not a demand for more dashboards — it is a demand that the posterior from last month's congestion event survive as this quarter's prior, with its provenance intact so it can be down-weighted the moment churn data shows the spike was transient.
The narrower claim, then: intake cannot be improved beyond continuous, provenance-tagged streaming — that exhausts the axis. Whether any given telecommunications operator can afford to build the hierarchy of trust that makes such streaming safe, rather than merely fast, remains a question of engineering discipline and budget, not of epistemology.