When a procedure changes, who needs retraining?
Revise a procedure and every completion against the old version becomes a question. How training records stay attached to what was taught.
Topic
Platform updates, architecture notes, and what we are shipping next for life at sea.
5 articles · Updated Feb 2026
Most workforce software assumes a network. At sea that assumption fails routinely, and it fails in the least convenient way: not with an error, but with a user who has already done the work and now cannot record it. Designing for that is the constraint that shapes most of what we build.
So the platform is offline-first rather than offline-tolerant. Work completed on a vessel is captured locally and reconciled with shore when connectivity returns, which means the record reflects when the work happened rather than when the ship found bandwidth. The same constraint drives how we handle sync conflicts, deployments to vessels, and how much a single environment can hold.
The second constraint is that no two operators are the same. The platform is multi-tenant with each line isolated from the next, which means a change has to be safe across very different configurations: fleets that run every module and fleets that run three, vessels with a satellite link and vessels without, crews of a few hundred and crews of tens of thousands. That shapes how we ship as much as what we ship.
Multi-tenancy also changes what shipping safely means. A release is validated not against one configuration but against the range of them, and the interesting failures are rarely in the feature itself. They are in the interaction between a feature and a fleet that uses the platform differently from every other fleet. Much of the engineering effort therefore sits in the parts nobody demonstrates: migrations that run against very unequal datasets, defaults that have to be sensible for an operator who never opens that module, and deployment to vessels that will not be reachable on the day a release goes out.
One thread runs through most of it: a record has to keep meaning something after the thing it describes has changed. A training completion is only useful if it names the version of the material that was taught. A signature is only evidence if it is bound to the exact document that was signed. Systems that store the fact and discard the context read the same on the day they are written and fail years later, which is precisely when somebody needs them.
This topic covers architecture notes and platform updates: how sync works across a fleet, what shipboard deployment involves, and where the platform is heading.
Revise a procedure and every completion against the old version becomes a question. How training records stay attached to what was taught.
A captured signature is worth little on its own. What has to be recorded alongside it so the document still means something years later.
A crew record holds identity documents, medical fitness and next of kin, and it moves between ship, shore and port. How that data is kept contained.
Full functionality onboard in low-connectivity environments, with reliable sync to shore.
The conflict-resolution model that lets ship and shore edit the same records safely.