The bottleneck as a theorem, not a metaphor
In 1999, Naftali Tishby, Fernando Pereira and William Bialek gave a precise answer to an old, vague question. Given an input X and a target Y, what is the smallest summary T of X that preserves the most information about Y? They formalised it as an optimisation: minimise I(X;T), the information T carries about the raw input, while maximising I(T;Y), the information T carries about what actually matters, trading the two against each other with a Lagrange multiplier. The solution is a compression that throws away everything about X that is irrelevant to Y and keeps everything that is relevant. That is the whole idea. It is not a metaphor for compression in general; it is a specific, provable optimum, and the optimum is defined entirely relative to Y. Change Y and the same summary stops being optimal. It becomes an arbitrary lossy encoding of the input, no better than a random discard.
This matters because it converts "we compressed the data" from a design choice into a claim with a hidden variable attached. Every compression has a Y whether or not anyone wrote it down. The question worth asking of any system that summarises, filters or archives is not whether it lost information — it did — but which Y it was fitted to, and what happens when a different Y arrives.
What the lineage inherits from it
The lineage from Large Language Model to Large World Model to Large Universe Model is a sequence of answers to that same question, each with a different, larger Y.
The Large Language Model compresses a frozen text corpus against the target of next-token prediction. What survives the compression is whatever statistical structure in text helps predict the next token. That happens to be a great deal, because language describes almost everything, but it is not everything: timing, sensor readings, what happened after the corpus was collected — none of that was encoded to begin with, so none of it can be recovered later. It was never compressed away. It was simply never let in.
The Large World Model widens intake to sensed experience — video, proprioception, contact — but closes the bottleneck again at the boundary of the scene. Its Y is acting well now: predicting object permanence, contact dynamics, affordances within an episode. That is a harder and more general target than next-token prediction, and the compression fitted to it is optimal for it. But anything outside the frame, or before the episode began, is discarded exactly as thoroughly as the Large Language Model discarded non-textual reality.
The Large Universe Model is the position defined by refusing to close the bottleneck at intake at all. Streams stay open. Observations keep provenance — where they came from, when, under what conditions. The task-specific compression, the actual fitting of T to a Y, is deferred until a query arrives and Y is known. There is no fourth position beyond "everything, still arriving, tagged with where it came from." What happens after that is engineering — indexing, retention policy, query planning — not a new epistemic move.
Three generations, three targets
| Generation | Y (target) | What it discards |
|---|---|---|
| Large Language Model | next-token prediction over a frozen corpus | anything the corpus never encoded: timing, sensor state, post-cutoff events |
| Large World Model | acting well within the present scene | long-horizon structure, anything off-frame or before the episode |
| Large Universe Model | deferred, fitted at query time to whichever Y arrives | nothing at intake; compression happens later, against a known target |
The table looks like progress by addition, and it is, but the honest description is progress by delayed commitment. Each earlier generation commits to a Y before it knows what will be asked of it later. The Large Universe Model's only trick is refusing to make that commitment until the question exists.
The test case: a staff engineer and a dependency
Software engineering teams run an unusually rich set of concurrent streams: commit history, continuous-integration results, incident feeds, dependency advisories. Each stream is already, individually, an information bottleneck fitted to a local Y. CI is fitted to "does the build pass and do the tests hold." Commit messages are fitted to "what changed and why, briefly." Incident dashboards are fitted to "is something on fire right now." Each of these compressions is optimal for its own narrow target and each discards, by design, everything not relevant to it.
The failure mode this produces is specific and recurring: a transitive dependency — a package three layers down in the tree, pulled in by something the team chose deliberately — turns out to carry a known vulnerability, and it ships for weeks before anyone notices, because no stream currently running was fitted to that Y. CI was fitted to test correctness, not to advisory correlation, so a passing build tells you nothing about a CVE published against a sub-dependency. The commit stream was fitted to describing intent, not to enumerating the full closure of what got pulled in. The incident feed was fitted to detecting active failure, and a dependency sitting quietly with an unpatched flaw generates no incident at all. Each stream is doing exactly what it was built to do. The vulnerability is invisible not because any one system failed but because no system had that particular Y as its target, and audits — the process that does have that Y — run on a cadence, typically weekly or monthly, not continuously.
The staff engineer who eventually finds it, usually while investigating something else or responding to a public advisory, is not discovering a bug. They are discovering the residual: the part of the intake that every running compression had already discarded because none of them were built to keep it. This is where the lineage claim becomes testable rather than merely asserted. A team running the equivalent of a Large Language Model posture — a periodic, frozen snapshot of the dependency graph, reviewed at intervals and otherwise trusted — cannot recover a vulnerability disclosed in week two of a four-week audit cycle; the information did not exist in their system at all between snapshots. A team running the equivalent of a Large World Model posture — live CI, live incident response, a tight and well-instrumented "current scene" — still misses it, because the scene under active attention is the build and the running service, not the full transitive closure of what got compiled into it. What would actually catch the case is a posture that keeps the dependency graph, the advisory feed and the commit stream as continuously running, provenance-tagged intake, so that when a new CVE is published — a new Y arriving from outside the system entirely — the compression against it can be fitted immediately: which services, which versions, which commits, cross-referenced without waiting for the next scheduled audit. That posture is the Large Universe Model's argument applied to a dependency tree instead of a sensorium.
Objection: this just relocates the bottleneck
Keeping every stream running with provenance is not the same as avoiding compression. Storage, ingestion bandwidth and query latency all force a bottleneck somewhere. You have not escaped Tishby's theorem; you have hidden the discard from yourself and called it progress.
This is correct, and it does not weaken the claim, because the claim was never that continuous intake avoids compression. Advisory feeds themselves are compressed — the National Vulnerability Database publishes a severity score, not a full exploit-chain analysis, and that scoring is itself a bottleneck fitted to a target: prioritising remediation effort. The relevant distinction is not whether compression happens but where and against what. A dependency-scanning pipeline that hashes package versions and diffs them against an advisory list is doing generic, task-agnostic reduction: it degrades resolution uniformly and its error profile is knowable, the way a fixed sample rate degrades every signal it touches equally. A team that instead reviews dependencies only during a scheduled quarterly audit has fitted a compression specifically to the target "catch what we remembered to look for," and that compression fails asymmetrically and silently — exactly the four-week gap the vulnerability lived in. Relocating the bottleneck to the read side, where the query "which of our services use this package" can be answered against a live, indexed graph, is not evading the theorem. It is choosing the version of the discard whose failure mode is bounded and known rather than unbounded and discovered by accident.
Objection: drift here is usually mild
Most weeks, nothing exotic happens. The dependency graph is stable, advisories are rare relative to commits, and a team that reviews quarterly catches the overwhelming majority of anything that matters. Treating every stream as if the next CVE could land anywhere at any moment is a tax on a problem that is statistically small.
This is true in aggregate and false at the tail, which is precisely where the cost concentrates. Most weeks a quarterly-cadence audit is indistinguishable from continuous monitoring, because most weeks nothing changes. The failure is not frequent; it is expensive and structurally invisible until it is exploited, which is the same shape as the rofecoxib trials that captured cardiac events only as incidental adverse-event log entries rather than as the pre-registered endpoint. A staff engineer's actual working conditions are dominated by the ordinary case, and building continuous, provenance-tagged intake for dependency advisories is overhead against that ordinary case. The argument for it is not that drift is common. It is that when drift does happen — a new critical CVE against something eleven layers deep — the cost of having no running stream fitted to that Y is measured in weeks of exposure, and the cost of having one is measured in a background job. The asymmetry, not the frequency, is what justifies keeping the stream open.