Incremental computation in maritime logistics

The strongest objection first

A fleet operator routes forty vessels across three oceans. Every routing decision depends on AIS tracks from tens of thousands of other ships, port congestion reports updated hourly, weather routing models recomputed twice a day, and bunker prices that move with every bunkering port's local market. The honest objection to a system that claims to hold belief over all of this, continuously, is arithmetic.

You cannot re-solve the global routing problem every time one ship's transponder pings. The state space is the whole fleet, the whole ocean, the whole schedule of canal slots and charter obligations. Recomputing that from scratch on every AIS update is not a matter of buying more servers. It does not scale, and pretending otherwise is where these systems fail — usually at the worst moment, when a canal authority changes a draught restriction mid-voyage and the plan that held yesterday is silently wrong today.

This is not a weak objection. It identifies the exact failure mode that makes continuous intake look unaffordable: a Large Universe Model, applied naively to maritime logistics, would mean rerunning the entire fleet optimisation against the entire history of tracks, weather and prices every time a single input changed. At update rates measured in seconds, across a fleet with interdependent charter-party constraints, that is not a system. It is a batch job that never finishes before the next one starts.

Where the objection is right

Take it seriously before answering it. Global fleet routing is, in its naive formulation, exactly the kind of computation that resists incrementality. A single new AIS report — another vessel entering the Malacca Strait, say — can in principle change the optimal routing for every ship whose path might cross it, because congestion forecasts are coupled across the whole strait, not local to one contact. If the optimisation is a joint solve over all vessels and all constraints, then a small change to one input can produce a large change in the solution's trace. Self-adjusting computation's own theory says the quiet part out loud: speedup is bounded by trace stability, and an unstable computation gets no benefit from being made incremental. If fleet-wide re-optimisation is genuinely unstable in this sense, incremental computation buys nothing, and the objection stands unmodified.

This matters because the characteristic failure named at the top is real and common: a routing decision holds against a canal restriction announced mid-voyage. The Panama Canal's draught restrictions during the 2023 drought changed booking slots and maximum draught week by week; a plan computed on Monday's water levels was wrong by Thursday. If the only way to notice is to re-run the whole voyage plan from the manifest onward, most operators will not do it often enough, and the plan will be found wrong by the ship, not by the system.

Where it breaks down

The mistake is treating "global fleet routing" as one computation rather than a dependency graph of many smaller ones. A canal draught restriction does not touch every vessel in the fleet. It touches vessels transiting that canal within the affected window, and it touches nothing else — not the bunker-price hedge on a vessel in the Baltic, not the berth window three ports downstream for a ship that never goes near that canal. If belief about each vessel's voyage plan is recorded as a node with explicit provenance — this ETA depends on this weather routing run, which depends on this wind field, which depends on this satellite pass — then a new canal restriction is an edit to one input. Only the subgraph downstream of that input needs to be marked dirty and recomputed: the affected vessels' transit windows, their downstream berth bookings, the bunker calls that were timed against the old ETA. Everything else — the price hedge on the Baltic ship, yesterday's already-confirmed port calls — is reused untouched.

This is exactly the distinction that operational weather assimilation already exploits, and maritime routing depends on that assimilation without needing to reinvent it. A system like NOAA's Rapid Refresh does not re-solve the atmosphere from the historical record every hour; it takes the previous forecast state as a prior and folds in the last few hours of radiosonde and satellite data, producing an updated state at a cost set by what changed, not by the accumulated archive. A shipping router consuming that feed inherits the same property for free, provided its own downstream computation — voyage ETA, bunker call timing, berth slot claims — is built the same way, as an update rather than a re-derivation.

The congestion example that looked unstable dissolves once the graph is drawn honestly. Malacca Strait congestion forecasts are locally coupled, not globally coupled: a new contact changes the near-term transit-time estimate for vessels in that strait's forecast window, and that estimate is a materialised view maintained the way a database maintains any aggregate under insertion — incrementally, touching only the rows in the affected time-and-space window. The vessels three days behind it, or on the other side of the world, are not in that view's dependency set. The apparent global coupling was an artefact of solving the problem as one large batch optimisation instead of many small maintained views with explicit locality.

What survives of the objection

Concede the real residue. Not every part of fleet planning is stable under small changes, and pretending otherwise would repeat the misreading the theory warns against. Charter-party rebalancing — deciding which vessel serves which contract when several ships become simultaneously available after a congestion event clears — is a combinatorial assignment problem, and reassignment can flip non-locally: one freed vessel can change the optimal allocation across a dozen contracts at once. That computation is genuinely unstable in the technical sense, and incrementalising it buys little. The honest answer is not to force it into the dependency graph but to run it as a batch job at its own cadence — nightly, or triggered by a threshold number of accumulated changes — while the ETA and berth-window maintenance that surrounds it runs continuously. A Large Universe Model of a fleet is not one incremental computation. It is a graph of many, stable ones maintained continuously and a few unstable ones re-solved in batch, deliberately, at intervals chosen for that instability.

The bookkeeping this requires is not free, and a second honest concession follows. Provenance annotations on every ETA, every congestion estimate, every price figure consume storage that grows with fleet history, and every downstream read has to check the dependency edge before trusting the cached value. For a small operator with six ships, maintaining this graph may cost more than occasionally recomputing plans from a fresh snapshot. Incrementality is a tuning decision made per relation, not a blanket policy: maintain the ETA view because it is read constantly and changes narrowly; recompute the charter allocation from scratch because maintaining it costs more than solving it.

The narrower claim

None of this reaches the actual failure mode named at the top, and that is the point. The canal restriction was not missed because fleet-wide recomputation was too slow. It was missed because the restriction was never wired into the dependency graph as an input at all — nobody's system treated the canal authority's notice as a node whose downstream edges included that voyage's ETA. Solving the arithmetic of incremental update does not solve access: whether the restriction notice reaches the system in machine-readable form, whether it is trusted over a stale AIS-derived draught estimate, whether the provenance chain from notice to voyage plan even exists to be walked. Those are the genuinely open problems in continuous maritime intake — access to authoritative sources, calibration of trust between a canal authority's bulletin and a third-party tracking feed, and the discipline of building every voyage plan as a maintained view rather than a one-off snapshot. Compute was never the reason the plan held against a restriction it should have caught. It is the reason such a system is buildable at all, once someone bothers to draw the dependency graph honestly and decide, relation by relation, what deserves to be maintained and what deserves to be re-solved.