An inference pool that works when the link to shore does not

An offshore asset is disconnected by design and by weather. The platform sits at the end of a link that is slow when it exists, costly when it is used, and absent when the sea or the schedule says so. On the decks, quadruped robots, crawlers, and fixed cameras from different suppliers read gauges, look for corrosion, and watch for gas. Each of them needs models larger than it can carry, and each supplier would send its imagery to its own cloud and wait for the answer to come back across that link. A pool on the asset serves all of them, holds what they find, and keeps working when the link does not.

What is on the deck

The fleet on an offshore asset is small in number and varied in kind. A quadruped walks the modules and reads the instruments along its route. A crawler works the inside of a tank or the length of a riser, where a person would need a permit and a standby crew. Fixed cameras on the process decks watch for the plume that means a leak. Behind them is the work that a permit governs: an inspection inside a confined space, a round through a live area, a check that must be done between two points in the operating schedule.

None of these machines carries the model it really wants. The quadruped's onboard model gets it from one waypoint to the next; the question of whether the valve it is looking at has changed since last week is a larger model's question. The crawler can see the weld; judging the pitting it sees is not something a crawler-sized computer does well.

Why the cloud and a GPU on every robot both fail here

The cloud fails first on the link. A supplier's model in a distant region answers a question in a time the robot does not have, over a link the operator pays for by the byte, and not at all when the link is down. Each supplier's cloud is also a separate path off the platform, and inspection imagery of the asset is the operator's record, not a supplier's training material.

A GPU on every robot fails on the deck. A robot built for a hazardous area has little room, weight, or power to spare for compute, and the heat has to go somewhere. Compute sized for each machine's hardest moment sits idle for most of every round. And a model adapted on one crawler's captures is lost to the quadruped and to the cameras, so the asset is learned separately by every supplier or not at all.

What the pool serves

The first thing the pool serves is the inspection fleet itself. Quadruped and crawler inspection, gas-leak vision, and permit-bound work are all served from one Czar Grid on the asset's own network. Substrate's Inference service answers each robot inside its time budget: the robot handles the step, the pool handles the question. Leak vision runs on the pool against every fixed camera at once, so a plume is one model's job rather than one camera's. Safety, stops, and motion limits stay on the robot as the vendor built them; the pool answers questions, it does not drive the machine.

Permit-bound work is where the pool is more than a model server. A permit is a bounded thing: this area, this window, these actions and no others. Agency Studio lets the operator write the inspection as a task with the same bounds, approve it under a named role before it runs, record every step, and replay the run afterward. A round through a live module becomes something the control room can read before and after, not an open-ended assistant.

The second thing the pool serves is the asset's own memory of itself. Inspection imagery and findings stay on the asset, on the pool, in a record the operator holds and reads. Memory and Retrieval let a finding be pulled by location, tag, or date, and this round's image set against the last one. Evaluation writes the model version beside every finding, so a judgment made in a storm can be reconstructed in the office. Adaptation runs overnight on the asset's own captures, so the models learn what corrosion looks like on this steel in this water. Where an operator wants a footage backlog worked through in bulk when the link is up, the Compute network is being built for that kind of overnight batch job; the real-time work never leaves the asset.

What stays on the asset and who holds the record

The pool can be air-gapped, or connected only to systems the operator already secures. Local Bridge permits the routes the operator declares, one by one: the maintenance system, the permit system, the shore office when the link is up. Nothing else has a path out. Watchman verifies the integrity of what is running, and signed updates arrive on media with a crew change or over the link when it exists. The record is the operator's, on the operator's hardware, readable in the operator's own review without a supplier's export.

How it is placed and bought

Czar nodes go in the asset's own rack, in the instrument or control room that already holds the network equipment, on the asset's own network. The subscription is for the configured Grid as one line, with hardware, platform license, and sustainment together, fixed for the term; more robots on the pool do not move it. Where a robot supplier ships the Grid under its own name with its fleet, that is Czar Chassis, and the asset still holds its own record.

An offshore operator has always run the asset as if shore might not be there. The pool is built to that assumption. The models, the record, and the tasks are on the platform with the people, and the link, when it comes back, is something to use rather than something to wait for.