WoyCoreOnboard

Full capability at sea. Even with no signal.

Satellite links drop. Bandwidth is expensive. Ports change by the week. WoyCore is designed for that reality: a dedicated node on board runs the full functional scope, the vessel’s own knowledge and a local AI model, and keeps working for as long as the connection is gone.

The onboard node follows the shore platform – see the roadmap.

01Why it has to work offline

The sea is where the questions are.

The moment an engineer most needs an answer, a fault in the engine room, a procedure nobody has done for years, a stores check before arrival, is often the moment the vessel is furthest from a good connection. Cloud-only tools stop exactly there. Systems built around a constant connection log the crew out, lose their work or fall back to paper.

WoyCore treats the vessel as an autonomous place of work. The crew never has to wonder whether the system will be available.

  • NO CONNECTION REQUIRED

    The full functional scope runs on board with no time limit on disconnected operation.

  • NO FORCED LOG-OUT

    Sign-in is validated locally. Losing the link never ends a session.

  • NO LOST WORK

    Every change is kept in a local queue and synchronised when a connection returns.

02How the onboard node works

The vessel’s own instance of WoyCore.

The onboard node is an autonomous instance of the same WoyCore core that runs ashore. It holds what applies to that vessel and nothing else: the core regulatory and reference layer, the shared documentation of its class of sister ships, its own documentation and records, and the part of the company’s knowledge that applies on board.

  • LOCAL KNOWLEDGEThe vessel’s knowledge graph and its approved, current documents, with the same citations and applicability checks as ashore.
  • LOCAL AIA local AI model on a dedicated compute node generates answers on board. The heavy work of preparing the knowledge base is done ashore, so the onboard node mainly generates answers. Its hardware profile is fixed by bench and onboard tests.
  • LOCAL SIGN-INAccounts and permissions are synchronised from shore and validated on board.
  • CREW UPLOADS IN QUARANTINENotes and documents uploaded by the crew go into a separate, clearly labelled space. They never mix with the verified knowledge base until they are reviewed and approved.
  • MOBILE CLIENTChecklists and evidence capture on a phone or tablet at the equipment, stored encrypted on the device and uploaded to the node when in range.

03Synchronisation

Built for links that come and go.

Ship and shore exchange data in sessions, whenever a connection is available. The rules are deterministic and explicit, so nobody has to guess which version of a record is right.

Deployment: the shore office platform and the vessel onboard node exchange data through session sync; the public AI assistant runs as a separate, isolated cloud service.
Synchronisation rules
WhatHow
Work done, stores issues, receipts, readingsThe vessel is the authority. Shore never overwrites these records.
Reference data, knowledge base, circulars, form templatesShore is the authority, and sends approved versions to the vessel.
A real conflict on one recordA conflict record is created for the responsible person to resolve. “Last write wins” is never used.
Every changeLogged with its author, a local sequence number, the device time and the server time on arrival.
Session sizeSmall, incremental and resumable from the last confirmed point after an interruption.
Large files and knowledge updatesSent through a separate, lower-priority queue, so operational data always goes first.

04Signed knowledge updates

Only approved knowledge becomes a source the crew can rely on.

New manuals, revised procedures, circulars and service letters are processed and approved ashore, then delivered to the vessels they apply to as signed packages.

  • Prepared ashore. Documents are parsed, checked, linked to the graph and indexed on shore. The vessel receives knowledge ready to use.
  • Signed and verified. The node checks the signature and the version compatibility of every package before installing it. An unsigned or mismatched package is refused.
  • Incremental. Only what changed is sent. Documentation shared by sister ships is prepared once for the whole series and delivered as one shared layer.
  • Reversible. The previous version is kept, every installation is logged, and an update can be rolled back.
  • Fleet-friendly. Vessels do not need to update at the same time. Large AI model updates travel on physical media or over the shore connection in port, not over the satellite link.
  • Never silent. An approved revision cannot be replaced unnoticed; every change is recorded.

05Built for life on board

Designed around heat, vibration and unstable power.

On a ship, hardware rarely fails because it is too slow. It fails because of the environment: heat and oil mist in the engine room, salt and humidity elsewhere, vibration, generator switchovers and brief power losses. WoyCore’s onboard requirements start from those conditions.

  • Installation in the ship’s office or the central control station, in a ventilated cabinet powered from the essential switchboard through an uninterruptible power supply. Never in the engine room without a conditioned cabinet.
  • Connected to the vessel’s IT network only.
  • Placement that does not interfere with radio equipment.
  • No crew maintenance: one system image for the whole fleet, a watchdog and automatic recovery.
  • Visible from shore: node status, software and knowledge versions and the update log are available to the office whenever there is a connection.
  • A spare node kept ashore, ready to send to the next port of call.
  • Measured before standardised: the hardware profile is fixed only after bench tests and tests on board, including heat and power interruptions.

06Security by design

Secure from the first line of code.

A hard line between IT and operational technology

The WoyCore node lives in the vessel’s administrative IT zone. It has no connection to engine automation, alarm and monitoring systems, navigation or power management, and it never sends a command to any of them. When OT telemetry from the engine room is added at a later stage, it will arrive read-only, through a one-way gateway, designed so that there is no command path from the IT side to shipboard control systems.

IT and OT zones on board: the shore platform connects over a satellite link to the WoyCore onboard node in the vessel’s administrative IT zone. Engine automation and alarm and monitoring sit in a separate OT zone. At a later stage, data can pass from the OT zone to the IT zone only, read-only, through a one-way gateway. There is no command path from the IT zone to the OT zone.

Controls that apply everywhere

  • Personal accounts only. Shared crew or office logins are not allowed. Multi-factor authentication for administrators, shore users and remote access.
  • Least privilege, including for AI. Agents never have more access than the person they work for.
  • Access control applied inside the search itself, so a document a user may not see never reaches the AI model.
  • Each company has its own instance, and its knowledge base is kept in separate stores, never in a shared index separated only by a filter. The public WoyCore AI Assistant is a separate installation with no path to company data.
  • An isolation test suite that deliberately tries to reach another company’s, another vessel’s or a restricted category’s data runs on every relevant change. A single failure blocks the release.
  • Encryption in transit and at rest. Secrets never appear in documents, e-mails, logs or AI prompts.
  • An immutable audit log of sign-ins, questions, sources used, AI actions, values before and after, confirmations and exports. Corrections are added as new entries, never as edits.
  • Signed updates, a software bill of materials for every release, and secured backups with regular restore tests.
  • Monitoring of unusual sign-ins, bulk exports, integrity violations and failed updates, with a defined response procedure.

07Ready for your cyber audit

The cyber risk evidence pack, built in.

IMO resolution MSC.428(98) requires cyber risks to be addressed in the Safety Management System, and the company has to demonstrate it at its Document of Compliance audit. Today that evidence is usually collected by hand. WoyCore assembles it from records the platform already keeps:

Cyber risk evidence pack
Area of the guidelinesWhat WoyCore provides
IdentifyRegister of computerised systems and integrations, with versions, location and criticality
ProtectAccess rights matrix, identification policy, records of multi-factor authentication
DetectRecords of unusual access, bulk exports and integrity violations
RespondCyber incident log with classification and actions taken
RecoverBackup records, verified restore tests, recovery point and recovery time objectives

Available with the shore platform.

08Design targets

Design targets for maritime cyber and safety requirements.

WoyCore is designed with the following requirements and guidance as its targets. They are design targets, not certificates or approvals. Where a certificate or a class document is relevant, it is pursued at the stage that needs it.

  • IMO MSC.428(98) and MSC-FAL.1/Circ.3/Rev.3

    cyber risk management in the Safety Management System

  • IACS UR E22

    computer-based systems on board

  • IACS UR E26

    cyber resilience of ships

  • IACS UR E27

    cyber resilience of onboard systems and equipment

  • ISM Code

    responsibility, risk management and continual improvement

  • GDPR

    processing of crew members’ personal data

Take WoyCore to sea.

The onboard node follows the shore platform. Tell us about your vessels and how they are connected.