A support vessel heading towards the camera through grey water, with fog lying along the mountains behind her.

Offline-first, and what that actually means

Every maritime software vendor says offline-first. Almost all of them mean a read-only cache. This page describes the mechanism, in enough detail that a technical superintendent can decide whether to believe it.

What most systems mean

A cache is not offline

The common arrangement is that the app downloads a copy of what it thinks you will need, shows it to you when the link drops, and refuses every write until the link returns. That is useful for about an hour and useless for a voyage.

The tell is what happens when you try to close a job with no signal. If the button greys out, or the change sits in a queue that fails silently three hours later, you have a cache.

What this is

The device holds the data and the rules

The whole of the vessel’s working data lives on the device, in the browser’s durable storage, mirrored in memory so reads are instant. The domain rules — the permission evaluator, the permit state machine, the drill interval engine, the rest-hour checks, the maintenance constraints — are a pure package that runs on the device unchanged.

So a write is evaluated immediately, against the same rules the server would apply. If it is refused, it is refused there and then with a reason. If it is accepted, it is accepted — it is not provisional, and it will not be quietly reversed when the link comes back.

Writes queue in a durable outbox

The queue survives the browser being closed, the tablet being turned off and the device running out of battery. It is not an in-memory array that a refresh discards.

Identifiers are generated on the device

UUIDv7, so a row created at sea has its final identity from the moment it is created and nothing has to be renumbered on arrival.

Every operation is idempotent

A batch re-sent because a satellite link dropped mid-transmission is recognised as a duplicate and applied once. We check it by sending two devices’ entire queues again, word for word.

Conflicts

Two devices, one row, no signal

The bridge PC and a tablet in the engine room both edit the same component, days apart, neither of them connected. Both eventually arrive. Something has to decide.

Each device keeps a hybrid logical clock — a timestamp that also counts, so two devices whose system clocks disagree still produce an ordering both of them will agree on afterwards. The merge is per column, not per row: if the bridge changed the location and the tablet changed the name, both changes survive. If they both changed the name, the newer clock wins and the older one is recorded as skipped rather than lost silently.

The property that matters is that the order of arrival does not affect the result. Whichever device reconnects first, both rows end up identical. We check it by making the same three edits in both orders and comparing the rows.

The limit

The devices on board meet ashore

There is no server on board. Every phone, tablet and PC synchronises with the server ashore, so while the vessel has no link the devices on board do not see each other’s work: a job closed on the engine-room tablet appears on the bridge PC once both have reached the shore again.

For most records that does not matter — a rest-hour day, a checklist or an oil record book entry belongs to one person on one device. For a permit it does, because a permit gathers the signatures of several people. Without a link it is raised and signed on one device that goes round them, as a clipboard would, each person signing as themselves. Its check against other work in the same space covers the permits that device knows about, and while the link is down the permit board and the check both say so, with the time of the last exchange.

With Starlink or VSAT on most vessels the periods without a link are short, and a box on board that somebody has to look after is a cost we would rather not hand a shipowner who does not need it.

The audit trail

Per vessel, hash-chained, and readable in the product

Every write the server accepts is recorded with who did it, on which device, at what time, and the SHA-256 of the previous entry. The chain is per vessel, so one vessel’s history can be handed to an inspector without handing over the fleet’s.

It is readable inside the product, by anyone with the permission, rather than being a table only the vendor can query.

The shell

A phone in a machinery space

The application is a progressive web app. It installs to a home screen, runs full-screen, and its shell — the code, the fonts, the icons — is cached so it starts with no network at all. The fonts are embedded in the stylesheet rather than fetched, because a font request that hangs is a screen that does not render.

The device-specific parts — storage, secure storage, network state, printing, camera — sit behind a small set of ports, so the rest of the application does not know or care what it is running in. It installs from the browser; it is not in the App Store or Google Play.

Put one vessel on it for two months

No card and no implementation project. A company adds its own vessel and its own people on its own afternoon — and if it is not for you, you stop, with your data exported first.