The problem a fleet operator actually has
A fleet operator routing forty ships across three oceans is not reading a report. They are watching four things arrive at four different speeds: AIS tracks pinging every few seconds to minutes depending on satellite coverage, port congestion feeds updated by terminal operators on their own schedule, weather routing models re-run every six hours against new satellite passes, and bunker prices ticking on exchange time. None of these streams stops. None of them agrees on what "now" means. The operator's job is to join them into a single answer — should this vessel divert — and commit to it before all the relevant evidence exists, because the ship is still moving while the decision is being made.
This is the condition the lineage was built to describe. A Large Language Model never meets it: its corpus was frozen at collection, and every fact in it is equally present because nothing in it is still arriving. A Large World Model meets a tame version: sensor fusion aligns camera and lidar frames within tens of milliseconds, the scene is bounded by the episode, and the window closes almost as soon as it opens. A Large Universe Model meets the real version — many streams, incompatible latencies, no stopping point — and the fleet operator's console is a small, consequential instance of exactly that.
The failure that names the argument
Here is the characteristic failure. A vessel is routed through a canal corridor based on a plan computed at 06:00: current AIS positions, a six-hour-old weather model, congestion figures from the terminal's morning report. At 11:40 the canal authority announces a draft restriction, effective immediately, due to a grounding upstream. The routing engine's last committed plan still shows the canal transit as clear. Nothing in the system is wrong in the sense of a bug. The join was correct for the window it was given. The window simply closed before the restriction existed, and nobody told the plan it had become stale.
The ship either burns four extra days going around the Cape, or it arrives at the canal to be turned back, having spent fuel and time on a route that a piece of evidence — sitting fifty minutes in the future relative to the plan — had already invalidated. The operator did not fail to gather information. The system failed to specify what happens when information arrives after a commitment has been made public. That is a windowing failure, not an intake failure, and the distinction matters for what fixing it requires.
Two defensible positions
There is a strong case that this whole apparatus is over-engineering dressed as philosophy.
Windowing is what you do when memory is expensive. Give the routing engine enough storage to retain every AIS ping, every congestion report, every price tick ever produced, and let it join across the full history for every decision. The canal restriction problem disappears because the plan is simply re-run continuously against everything known, with no artificial cutoff imposed to save disk space. This is a hardware budget question, not an epistemic one.
This is not a weak objection. Storage is cheap now in a way it was not when stream processing was invented to solve nightly-batch billing problems for web logs. A fleet's full AIS and weather history for a year is a rounding error against a modern data centre. If the constraint that forced windowing in 2005 has largely dissolved, why keep the concept?
Because retention removes one constraint and leaves the other standing. Even with infinite storage, the operator must decide when to speak. At 06:00, the ship needs a plan; that plan cannot be built from evidence that arrives at 11:40, no matter how much disk is behind the system. Something has to be said at 06:00, or the routing engine is mute and the ship sits idle. Unbounded retention turns the window from a memory bound into a pure decision bound — when to emit, when to commit, when to allow a later record to overrule an earlier one. That is not a weaker version of the windowing problem. It is the windowing problem with its engineering excuse removed, leaving the actual question exposed: who owns the moment of commitment, and on what terms will it be revisited.
The counter-position, stated fairly
There is a second, sharper objection, and it does not go away with more compute.
Stream joins work because the records carry an agreed key: order_id matches order_id. A satellite AIS ping and a canal authority's draft notice have no such key. Deciding that today's congestion report and this particular vessel's ETA concern the same event — the same berth, the same tide window — is the hard problem. Windowing is silent about it; it only handles alignment once matching has already been solved.
This is correct, and it is the real limit of the analogy, not a rhetorical one to be waved past. Matching an AIS track to the correct vessel across a satellite handoff, or matching a bunker price quoted in one port's local convention to a fuel contract denominated in another, is entity resolution — a harder and logically prior problem to temporal alignment. Streaming literature mostly assumes clean keys and gets to skip this. Maritime data does not have that luxury: vessel identifiers get duplicated across AIS transponders, port names get spelled four ways across terminal systems, and a "restriction" announced by a canal authority may or may not be the same restriction referenced in yesterday's advisory.
What survives the objection is narrower than the original claim, but it survives. Once a match has been made with some stated confidence — this AIS track is this vessel, this advisory concerns this canal segment — the temporal question is still open and is not reducible to the matching question. In practice the two compound: a late-arriving record can turn out to be both temporally stale and wrongly matched, and disentangling which caused a bad decision requires knowing not just when a fact arrived but what it was joined against and why. That is an argument for provenance, not against windowing. The fleet operator needs to know, when a plan is retracted, whether it broke because a new fact arrived or because an old fact was matched to the wrong vessel.
What the lineage narrows to
Bitemporal databases solved a version of this decades before stream processing existed as a discipline — Snodgrass's work on valid time versus transaction time predates Akidau's watermarks by twenty years, and any shipping line running an ERP with an audit trail already distinguishes "when the restriction took effect" from "when we found out about it." That lineage is real and should be conceded, not buried under new vocabulary.
The difference is what the machinery is applied to. A bitemporal ledger applies temporal bookkeeping to records the organisation designed a schema for in advance: known fields, known sources, known cadence. A system trying to hold beliefs about a live fleet is applying the same machinery to whatever arrives — a canal authority's press release, a re-analysed weather model, a terminal's informal congestion estimate posted to a public feed — much of which was never anticipated by any schema. Same clock discipline, radically wider intake. The claim made for the third position in the lineage is about the breadth of what it must ingest and revise, not about the novelty of tracking valid time versus transaction time, which is old.
Where this leaves the operator
The Large Universe Model, as an argued category rather than a shipping system, is defined less by the number of streams it takes in than by its policy for closing questions it cannot yet finish answering. For the fleet operator this means the routing engine's output should carry, alongside the recommended course, a watermark — the latest event time it has accounted for — and an explicit allowed-lateness: a stated threshold beyond which a canal authority's advisory will trigger an automatic re-plan rather than a quiet footnote. Get that threshold wrong and you either re-route on every rumour or hold a stale plan past the point of usefulness, which is what happened at 11:40. The fix is not more data. It is an owned, visible answer to the question of how long a plan is allowed to stand before new evidence is obliged to break it.