Deploying computer vision models offline, where the network does not reach

The survey vessel leaves port on a Monday and is out of range of anything but a satellite link by Tuesday, and the satellite link is for the bridge. For the next three weeks the four cameras on the aft deck record to a box in the instrument room. The model that watches them for a person inside the winch zone has to run on something in that room, because there is nowhere else for it to run.

The plant on shore has the opposite problem with the same shape. The network is fine. The policy says no footage leaves the building, and the policy is right.

Both end up with the same architecture: a runner beside the recorder.

The runner sits beside the recorder and watches every camera locally

The recorder is already there, in the instrument room or the comms cabinet, taking every camera's stream. The runner is a small compute box on the same network segment, and it does what the cloud would do: one consumer per stream, every camera watched in parallel, sampled about every two seconds, the model running on each sampled frame. No frame goes anywhere the recorder's own traffic did not already go.

The model gets there as an exported artifact, PT, ONNX or TorchScript, chosen by describing the device it will run on: a Jetson in the cabinet, a small GPU server in the rack. The deployment doc covers the export and what you own once it is on your hardware, which is everything the loop produced, the dataset included.

My own view is that a small box beside the recorder beats the plant's biggest server every time, because the server is in a different room, on a different network, owned by a different team, and the box is where the cameras already are.

Alerts fire on site first

An alert is a rule written as a sentence, with a severity and a cooldown, approved before it goes live: a person inside the winch zone on the aft deck while the winch is under load, critical, no cooldown. On the vessel that rule fires on the runner, and what it produces goes to the bridge's own alarm panel by webhook, with the frame, in the time it takes to sample and infer.

When a link exists the same alert also goes to Slack or email, because the shore office wants to know too. When it does not, the local delivery is the whole alert, and it is enough. The person who can stop the winch is on the vessel.

At the plant the rule is a different sentence and the same mechanism. The runner delivers to the plant's own systems on the plant's own network, and the shore office is a webhook that may or may not be reachable this hour.

Only doubted frames leave, and only when there is a link

The runner does not send footage. What it sets aside is the small set of frames the model was unsure of: a person half behind the winch drum, a hi-vis colour the training frames never had, a deck awash at dusk. Those wait in a queue on the runner with the box drawn, and when the vessel comes into range, or into port on the Friday of week 3, the queue goes to a person for a verdict.

The plant's queue leaves through whatever narrow path the policy allows, which is usually a person on the plant network reviewing the frames there and only the verdicts crossing the boundary. The security page describes that arrangement: what the loop keeps is the review queue, the flagged frames and the verdicts, and the streams stay where they were recorded.

Three weeks of doubted frames from a vessel is a few hundred frames. It is also the best training set the aft deck will ever produce, because every one of them is a case the model could not settle.

A new version arrives the same way the frames left

The verdicts on those frames are corrections, and when the corrections cross the project's threshold a new version trains, compared with the old one on the same frames. The new version goes back to the runner on the next link, or on the same USB stick that brought the first one. The runner swaps to it with no downtime and keeps the old version alongside, with a record of what each was trained on.

LexData takes the deck model through its whole life. You type what to look for, Lexi puts a box on every frame, and a person checks each label before anything trains on it. The model then watches the cameras the vessel already has, on a runner beside the recorder. Frames it is unsure of come back to a person, the corrections retrain it, and the new version replaces the old one with no downtime. The accuracy you launched with is the accuracy you keep, on a vessel that was out of range for most of it.

The vessel's IT lead keeps the current model on a stick in the bridge drawer, labeled with the version and the date, beside the charts.

The runner has to report its own health because nobody else can

A model in the cloud has a team watching the service. A runner in an instrument room has whoever walks past it. So the runner keeps its own account: which streams are connected, how many frames it sampled in the last hour, how many alerts it sent and to where, and how big the doubted queue has grown. That account is a page on the vessel's network, and a line in the daily report the bridge already sends.

A stream that dropped on Wednesday and was not noticed until port is the failure to design against. The cheapest guard is a rule on the runner itself: a camera with no frames sampled for an hour, high, to the bridge panel.

Once the doubted frames reach a person, the correction rate on them is the model's health. Three weeks of frames with a flat rate is a model that held. A rate that climbed through the trip, on one camera, is a camera that moved or a deck that changed, and the crew usually knows which.

The air gap is a decision about where the boundary sits

The vessel has no choice about its boundary. The plant does, and the platform runs the same loop on either side of it: in our cloud, on the plant's servers whether we manage them or the plant does, or on the runner beside the recorder. What changes is which frames cross and which do not, and who signs in to review them. SSO and role based access decide the second. The first is a line the plant draws, and the runner is what lets it draw the line at the recorder.