Connection-independent work
Previously fetched records remain available through SQLite on mobile and IndexedDB on the web; new results are stored locally without waiting for connectivity.
Do not treat offline work as an afterthought.
Daily maintenance, checklists and operational records continue when vessel connectivity slows or disappears. If the system depends on online forms, crews fall back to paper and later duplicate data entry.
Faromo addresses this problem with a layered flow—SQLite on mobile, IndexedDB on the web and a tenant-scoped server event history—not a single “offline” switch. A local save, queued transfer and server result are different states, each with its own control point.
“Saved” and “received ashore” are not the same state.
IMO frames ship–shore digital systems around operational resilience and the availability and integrity of data. Faromo turns that context into product architecture that distinguishes local, queued and server-applied states. This mapping is not a regulatory approval.[1][2]
Separate transfer state
Pending and failed writes remain visible. Mobile photos upload first, and the updated queue payload prevents the same file from being sent again on retry.
Controlled transition to shared state
The server applies writes within the authenticated company scope; cursor, event state and record-specific replay outcomes are retained for diagnostics and monitoring.
Client and synchronization layer matrix
Faromo’s offline behavior varies by client and write path. This matrix describes what each layer stores, when it sends and where its control boundary sits, based on current product behavior.
| Layer | Local record | Transfer trigger | Failure behavior | Control boundary |
|---|---|---|---|---|
NATIVE APP | SQLite cache and an on-device write queue | Reconnect, app foreground or a manual user sync | Retries with increasing delays; the record remains pending or failed. | Coverage is enabled screen by screen and action by action. Duplicate handling for REST replay must be verified per endpoint. |
WEB PWA | IndexedDB query cache and REST write queue | Going online, a 12-second interval or manual sync | The record remains failed after a terminal client error or five attempts. | Authentication and sync endpoints are never queued; local cache and write queue are cleared on logout. |
SYNC EVENT LOG | Append-only server event record and monotonic cursor | Push/pull calls and a per-minute replay worker | The replayed, skipped, conflict or rejected outcome remains in event history. | clientEventId deduplication belongs to the sync event endpoint; it does not automatically cover every general REST write. |
CROSS-DEVICE PULL | Registered device, last cursor and last successful pull time | A 15-second interval, window focus or reconnect | The cursor is retained; the next successful pull refetches affected record groups. | Entity-type and vessel filters apply only to registered devices and supported event types. |
Offline support is not one yes-or-no capability for the entire product. Every critical action must be verified together with read cache, write queue, attachments, retries, conflicts and duplicate-record behavior.
What should be verified before enabling offline work on a vessel?
IMO’s resilience, business-continuity and recovery context informs product selection; actual acceptance testing must use the screens and actions the vessel will operate. This list is a technical and operational control gate for the pilot vessel.[1][2]
- Scope List the actions used offline: Define each role, screen, record to be viewed, create/update action and vessel context.
- Local data Test the preloaded dataset: Verify which records are on the device, their freshness indicator and behavior when opened without connectivity.
- Session Protect the shared-device boundary: Verify that cache and pending writes clear on logout and that the next user cannot access data from the previous session.
- Retry Distinguish failure types: Test that pending/failed states and user messaging change correctly for network, server and validation errors.
- Idempotency Test duplicate delivery per endpoint: When the server accepts a write but the response is lost, verify whether POST, PUT and PATCH replay creates a new record or the same outcome.
- Conflict Verify record-specific policy: When the same record changes in two places, inspect the selected, merged, skipped or rejected outcome and its event history.
- Attachment Test attachment retry: Verify that the local file uploads first, the queue record updates and retry does not upload the same file again.
- Recovery Run an end-to-end connectivity drill: Test airplane mode, reconnect, pending writes, cursor progress, stale-device warning and shore visibility in a real pilot scenario.
Do not accept “works offline” as a blanket claim. Complete pilot acceptance against the critical scenarios and record types the vessel will actually use.
Scope and core capabilities
Local task access
Assigned work and required references remain available without connectivity.
Offline capture
Record results, notes, readings and operational data securely on the device.
Sync queue
See pending records with order, status and error reason.
Retry control
Interrupted transfers resume in a controlled way when connectivity returns.
Record-specific conflict policy
Retain different replay decisions for maintenance, certificates, incidents and append-only log records in event history.
Shore status
Monitor a registered device’s last sync, cursor progress and stale-device state.
Workflow
- Prepare data onboard: Tasks and references become available locally.
- Work offline: The crew completes daily work without interruption.
- Manage the queue: Completed records enter the transfer queue.
- Sync ashore: When connectivity returns, records are validated into the shared state.
Operational outcomes
- Reduce the need to fall back to paper during outages.
- Reduce errors caused by entering the same record twice.
- Keep transfer status visible between vessel and shore.
- Continue daily work without waiting for a weak connection.
Product evidence
SQLite, IndexedDB and tenant-scoped event history
Native and web clients separate local records from transfer state; device data clears on logout and the server applies writes within the authenticated company scope.
Frequently asked questions
Which modules can work offline?
Coverage is verified by client and action. The native app implements local queues for work orders, noon reports, rest hours, drills, incidents, CAPAs, checklists, logbooks, permits to work and related operational flows; the pilot scope should still be confirmed before purchase.
What happens if the same record changes in two places?
There is no single generic merge rule. The server applies record-specific policy; replayed, skipped, conflict or rejected outcomes remain in event history for diagnostics.
Is data lost if synchronization fails?
A failed write remains pending or failed in the local queue and can be retried. Pilot acceptance must still test device loss, logout, attachments and lost-server-response scenarios separately.
Can shore see the vessel’s last sync?
Yes. Authorized users can monitor a registered device’s last successful pull, last cursor and stale-device state. The count of locally pending records is shown on the device itself.
Primary sources
- Guidelines on Maritime Cyber Risk Management (MSC-FAL.1/Circ.3/Rev.3) — International Maritime Organization
- Maritime cyber risk management — International Maritime Organization
- International Safety Management (ISM) Code — International Maritime Organization