The problem the planner already has
A supply planner does not lack data. A modern network planning desk has shipping line APIs, port community system feeds, ERP purchase orders, supplier EDI 856 advance ship notices, tariff schedules, and a customs broker's filing cabinet reduced to a portal. The complaint from planners is never "we don't see enough." It is that the plan was built on Tuesday and the world moved on Wednesday, and nothing told the plan it had moved.
This is the same problem control engineers hit in the 1960s, in a different plant. Electric utilities and pipeline operators, running processes spread across hundreds of miles, discovered that telephone-based reporting was too slow to act on. A substation fault reported twenty minutes late is a substation that stayed unstable for twenty minutes. The fix was Supervisory Control and Data Acquisition: field devices reporting continuously to remote terminal units, remote terminal units reporting continuously to a supervisory host, a plant polled every few hundred milliseconds forever, because a process that stops being observed becomes a process nobody can control. Modicon's programmable logic controller, 1969, made the field logic reprogrammable. Honeywell's TDC 2000, 1975, put that logic on a shared data highway across the whole site. Nobody built this because continuous monitoring was elegant. They built it because a refinery sampled once a shift and modelled from memory cannot be kept inside safe limits, and neither can a network sampled once a week and planned from memory.
What a supply chain plan actually runs on
Strip a network plan down and it is a set of assumptions given numeric form: this lane clears customs in four days, this supplier's factory is operating at declared capacity, this port has slack berth capacity in the relevant window, this tariff line still carries the rate it carried when the sourcing decision was made. Each assumption was true when written. None of them carries a timestamp the plan actually checks against.
The characteristic failure is not a missing sensor. It is a filing nobody read. A tariff notice publishes a reclassification of a component three weeks before a shipment lands, and the plan, built on the old duty rate, clears customs at a landed cost that erases the margin on the order. A port authority telemetry feed shows berth congestion climbing for eleven days before a vessel is diverted, and the plan, which took port capacity as a constant at the planning stage, has no term for "capacity as of now." A supplier files an amended production disclosure — a line stoppage, a force majeure notice, a change of subcontractor — and the plan, which encoded supplier capacity as a fixed row in a spreadsheet six weeks old, keeps routing orders to a factory that is no longer running them.
In every case the information existed. It was published, filed, transmitted, streamed. The plan simply was not built to keep listening. It was built the way a Large Language Model is built: a corpus fixed at some cutoff, internally coherent, and silently wrong the moment the world it described moves.
The three positions, applied to a shipment
A frozen network plan is the planning equivalent of the plant history exported to a file — an honest record as of a date, useful for a post-mortem on why the quarter went wrong, structurally incapable of telling you what the port looks like this morning. Call this the Large Language Model position: static, coherent, retrospective.
A live control tower dashboard, tracking one shipment or one lane in real time — vessel position, container status, the next milestone — is the operator's console. Genuine sensing, genuine presence, bounded to the shipment on screen and to the length of the disruption being managed. This is the Large World Model position: rich within its scene, blind outside it. It tells you where this container is. It does not tell you that the tariff line governing its contents changed yesterday, because that filing is not part of the scene.
What the planner actually needs is the third position: every stream still running — shipping manifests, port telemetry, supplier filings, tariff notices, customs rulings, weather advisories bearing on transit time — joined into one belief about the state of the network, with each figure carrying where it came from, when it was true, and how much to trust it. Not a bigger dashboard. A belief that revises itself when a transmitter — in this case, a filing — contradicts what the plan assumed.
| intake | characteristic blind spot | |
|---|---|---|
| Large Language Model | corpus fixed at a cutoff | everything after the cutoff |
| Large World Model | live feed on the current shipment or lane | everything outside the current scene |
| Large Universe Model | every manifest, filing, telemetry stream, held as revisable | none by construction; failure moves to trust and priority |
Why this is not a new idea dressed up
Supply chain visibility platforms describe themselves as new. The structure is not. The bulk power grid has run state estimation since the 1970s: phasor measurement units sampling voltage and current dozens of times a second, reconciled by a weighted-least-squares estimator into one coherent grid state, with bad-data detection discarding readings that fail residual tests. The Trans-Alaska Pipeline detects leaks by continuous mass balance over 800 miles, because a discrepancy of a fraction of a per cent between metered-in and metered-out is the only early signal of a rupture under snow. Neither system waited for artificial intelligence to justify continuous, provenanced, multi-stream intake. Control demanded it decades earlier, in domains where stopping observation meant losing the plant.
Supply chains are arriving at the same architecture for the same reason: the plant is now the network, and the network does not hold still either. A tariff notice is a transmitter. A supplier filing is a transmitter. A port authority's berth utilisation feed is a transmitter. The planner who treats these as sources to be read at intervals, rather than streams to be held live, is running the pre-1970s control room: instruments exist, but nobody is polling them continuously, so the plant drifts unnoticed between inspections.
The two objections that actually bite here
A refinery has a finite tag list and known physics. A supply chain is open-ended — new suppliers, new lanes, new regulatory regimes appear without warning. Borrowing SCADA's credibility for an unbounded problem smuggles in a closure the domain doesn't have.
This is the right objection and it does not fully hold. Industrial tag lists were not finite by design either — they grew from hundreds to hundreds of thousands of points precisely because an engineered boundary kept failing to contain the causes of upsets, and plants annexed exogenous streams, ambient temperature, grid frequency, feedstock assay, to close the gap. Supply chain intake is following the identical direction. Ten years ago a network plan drew on ERP and carrier EDI. It now pulls tariff databases, port authority open data, weather routing feeds and supplier ESG disclosures, because each addition closed a category of failure the narrower tag list kept missing. The boundary is not fixed and never was, in either domain. What transfers from SCADA's history is the direction of the leak, not a promise that the tag list will ever be complete.
More feeds is not the fix. Control rooms drown in alarms — Milford Haven's operators received 275 alarms in eleven minutes before the explosion — and a planning desk with fifteen live feeds and no prioritisation will do the equivalent: bury the one tariff notice that matters under a flood of routine ones.
Correct, and it is the sharper failure mode for a planning desk specifically, because filings and telemetry arrive at very different rates and most of them are noise relative to any one shipment. The industrial answer was never to reduce sensing. It was alarm rationalisation and state-based alarming — deciding, from more context, what deserves attention now. The supply chain equivalent is a belief layer that weighs a tariff notice against the shipments it actually touches, decays a stale port congestion reading after the relevant vessel has cleared, and surfaces the supplier filing that contradicts a live purchase order while suppressing the thousand filings that don't. That is processing maturity built on top of intake. It answers a flood problem by improving judgement, not by turning transmitters off.
Where the ladder actually stops
None of this makes the planning problem solved. Knowing which of forty live tariff feeds actually bears on next Tuesday's shipment, weighting a rumour of port congestion against a confirmed berth schedule, deciding how long a supplier disclosure stays credible before it decays — all of that sits above intake and remains genuinely hard, in supply chains as in a control room. But the intake question itself has an answer, and industrial history gave it decades before anyone asked a model to plan a shipment: hold every stream live, tag it, timestamp it, let it be wrong and revised rather than fixed and trusted. That is the Large Universe Model position. It is not a bigger version of the console or a longer corpus. It is the recognition that a network which does not hold still cannot be planned from memory, and there is no fourth rung above listening to everything, continuously, and believing none of it absolutely.