A slave memory and a joke about naming
Maurice Wilkes gave the cache its structure before anyone had a reason to distrust it. His 1965 paper on slave memories proposed a small fast store sitting between processor and main memory, holding the lines most likely to be reused. The IBM System/360 Model 85 built the idea into silicon in 1968. The engineering problem that followed was not how to fill the cache — filling is easy, you just copy — but how to know when the copy had gone bad. Once several processors held their own copy of the same line, a write by one left the others silently wrong. The fixes that emerged through the 1980s, the MESI family of coherence protocols, exist entirely to answer one question: who else is holding a copy of this, and have we told them it changed?
Phil Karlton, working at Netscape in the 1990s, turned the asymmetry into the line everyone quotes and few finish: there are only two hard problems in computing, naming things and cache invalidation. The joke works because both problems look trivial and are not. Writing a value is a local act. Retracting it, everywhere it has been copied, is a coordination problem, and coordination problems scale with the number of copies and the speed at which the world underneath them moves.
Every caching system since has picked between the same two disciplines. Expiry: attach a lifetime to the copy and throw it away when the clock runs out, whether or not it is still correct. Invalidation: have the source notify every holder the instant the value changes. Expiry is cheap, requires no relationship between source and copy, and is wrong exactly as often as the clock is mismatched to reality. Invalidation is precise and requires the source to know, at all times, who is holding what.
The capacity plan that outlived its traffic mix
A telecommunications network is, structurally, a very large collection of caches. A capacity plan is a cache of a traffic pattern. A spectrum allocation is a cache of a filing. A churn forecast is a cache of subscriber intent. All of them are built from streams that keep moving after the cache is filled: traffic telemetry off the radio access network, fault alarms from the operations centre, spectrum filings lodged with the regulator, churn signals surfaced from billing and support. The planner's job is to read those streams, build a model of load, and provision cell sites, backhaul and core capacity against it.
The characteristic failure is well known to anyone who has done the job. A capacity plan is built on a traffic mix — say, 60 per cent video streaming, 25 per cent messaging, 15 per cent everything else, measured over the previous two quarters. Provisioning is sized to that mix: enough backhaul for the video, enough signalling capacity for the messaging, headroom sized to historical peak-to-average ratios. Then a widely used application ships a release that changes its default behaviour — background video calling turned on by default, a social app switching from photo to short-form video, a messaging client adding always-on presence pings. The traffic mix shifts in weeks. Telemetry from the affected cells shows rising utilisation, but the capacity plan itself, the document and the provisioning it drove, does not know it has been invalidated. It carries no expiry date short enough to catch a mix shift that fast, and nothing in its construction notifies the planner that the assumption it rests on has broken. The plan looks current because nobody told it otherwise. It is current the way a printed map is current: accurate about a world that has since moved.
What actually catches the shift, in practice, is a human noticing an alarm pattern — congestion alerts clustering on cell sites that were comfortably under threshold last quarter — and tracing it back, by hand, to the release notes of an app nobody at the operator controls. That trace is invalidation performed manually, after the fact, by a planner doing the coordination work that the system itself was never built to do.
Two disciplines, one network
The telecom stack already contains both disciplines, applied inconsistently. Fault management uses something close to invalidation: an alarm clears when the underlying condition clears, and the network management system is notified directly, because the equipment vendors built explicit channels for it. Spectrum filings use expiry: a licence has a term, a review date, a renewal cycle, because nobody expects the regulator to push a live notification the instant conditions on the ground change. Capacity planning sits uncomfortably between the two. It is treated administratively like an expiry system — replanned quarterly, or annually, on a fixed cycle — while the thing it depends on, live traffic composition, changes on the timescale of an app store release, which has no fixed cycle at all.
The mismatch is the actual cause of the characteristic failure. It is not that telemetry was unavailable — the data existed, granular and near-real-time, in the same operations centre that raised the congestion alarms. It is that nothing connected the capacity plan to that telemetry as a dependency. The plan did not know which observations it rested on, so nothing could tell the plan, specifically, which of its assumptions the new telemetry contradicted. The alarm fired. The plan sat unrevised until the next scheduled cycle, because revision required a person to notice, trace and rebuild the connection that the system itself had never recorded.
What the three generations actually differ on
This is the shape the Large Language Model, Large World Model and Large Universe Model distinction is describing, at a different scale. A Large Language Model is a cache with a training cutoff and no notification channel back to the corpus it compressed: correct at the cutoff, silently drifting after, with nothing inside it marking which parts have gone stale. That is the capacity plan built once a year and never told about the app release. A Large World Model reads its scene directly and treats each new frame as automatic invalidation of the last — but only for what is currently in view. That is closer to the fault-alarm channel: precise, live, and blind to anything outside the sensor's current field, which in planning terms is everything not on the dashboard the planner happens to have open.
| Generation | What it holds | How it learns something is wrong |
|---|---|---|
| Large Language Model | a corpus frozen at a cutoff | it doesn't; drift is silent |
| Large World Model | a bounded present scene | the next frame overwrites the last |
| Large Universe Model | continuous streams, with provenance | contradiction propagates along recorded dependency edges |
A Large Universe Model is the position where the capacity plan itself carries the dependency: this provisioning figure rests on this traffic-mix observation, from this stream, as of this timestamp; when the telemetry stream reports a value that contradicts it, the plan is flagged for revision automatically, not rediscovered by a planner tracing congestion alarms back to a release note three weeks late. That is what provenance buys operationally in this domain: not omniscience, but a network planner's after-the-fact detective work turned into a standing property of the plan.
The objections that matter here
Tracking dependency edges for every provisioning figure against every stream that could invalidate it is a bookkeeping cost no operator will absorb. Better to replan more often and skip the graph.
More frequent replanning shortens the expiry window. It does not create a channel that tells you, this week, which specific provisioning figures are now wrong and why. A network replanned monthly still cannot answer, on the Tuesday an app ships a release, which cell clusters' assumptions just broke. The realistic answer is hybrid, and telecom already runs hybrids of exactly this kind: fault alarms invalidated eagerly because the equipment supports it, spectrum status invalidated on a fixed term because nobody needs it faster, and capacity assumptions somewhere in between, invalidated eagerly only for the handful of metrics — utilisation, latency, drop rate — that actually drive provisioning decisions, and left on a slower cycle for the rest. Provenance does not require universal eagerness. It requires that the edges exist at all, so eagerness can be spent where it is worth spending.
Provenance tells you where a belief came from, not whether the source was right. Telemetry can be miscalibrated, an alarm can be a sensor fault, a churn signal can be an artefact of a billing migration rather than real subscriber intent. A well-provenanced plan can still be confidently wrong.
That is the harder objection and it is correct. A dependency edge does not vouch for the stream at its other end. But an unprovenanced capacity plan that turns out wrong cannot even be diagnosed — nobody can say which assumption failed, because nothing recorded what the plan rested on. A provenanced plan that turns out wrong is wrong in a traceable way: the faulty sensor, the migrated billing field, the mislabelled release, can be found and fixed, and the next plan corrected specifically rather than rebuilt wholesale. Provenance does not make the belief true. It makes the falsehood findable.
Where this leaves the planner
The lineage is not a claim that planning becomes automatic. It is a claim about where the ceiling on this particular axis sits. A frozen plan, replanned on a calendar, is the telecom equivalent of a training cutoff. A live dashboard of the current scene is the equivalent of scene-bound perception — accurate about what is on screen, silent about everything else. The remaining move is structural: keep the streams open, attach provenance to every figure a plan depends on, and let contradiction propagate backwards through the plan automatically. Once that exists, there is no further discipline to invent. There is only doing it with better sensors, cleaner streams, and more honest handling of the sources that turn out to have lied.