The view from a ship’s bridge window: bright sea, mountains on the horizon and a searchlight on the bulwark.

Operations and record books · Module 06

Shipboard handovers and forms

One form engine behind every signed piece of paper on board, with the wording frozen at the moment of signature.

ISM Code, clause 11

Handovers: what is open on board right now, and the chief engineer’s completed handover, on a laptop — screen in the NoRemarks app

What it is for

The requirement, and the problem

A handover is the highest-consequence document on a ship that nobody treats as one. Two people with the same title, four weeks apart, and everything the outgoing one knows has to survive the gangway. Done as a Word file it survives as far as the first person who forgets to attach it.

The handover here is a form like every other form in the product, which is exactly the point: it is versioned, it is signed, it is searchable, it is attached to the position rather than to a mailbox, and the rules about who may read whose are part of the domain.

How it works

Three steps, on board and ashore

  1. 1

    Start the handover

    Watch, department and job handovers, toolbox talks and daily forms all run on one versioned form engine.

  2. 2

    Fill in and sign on the spot

    Both people sign where they stand, on one device, and the form keeps the wording that was in force when they did.

  3. 3

    Read by the right people

    Who may read whose handover follows the organisation, not a shared folder anybody can open.

Example with demo data

What it looks like

A working picture of the module with demo data from the Ocean Pioneer — the same ship you find in the demo.

Try the demo — no account, in your browser, with the PIN 1234.

  • Handovers — by position, with the previous one one click away
  • The form builder, shared with checklists and permits
  • Signatures — drawn, or stored and applied with a PIN
Bridge watch handoverSigned by both
04–0808–12
  • Course 215°, speed 11.4 kn, autopilot
  • Traffic: two fishing vessels to port, 3 nm
  • Weather: SW 12 m/s, falling
  • Master’s night orders read
Anders Vik · CO Kristian Lie · 2O

In detail

What the module does

A signed form keeps its wording

The template is versioned and the instance points at the version. Changing the form next month does not change what was signed last month.

A flagged answer has to be explained

Answer outside the acceptable range and the form requires a sentence. It is one rule in one engine, so it holds on a permit, a toolbox talk, a daily report and a job checklist alike.

Handover access is a domain rule

Who may read a chief engineer’s handover is decided by permission and position, not by who happened to be copied.

Drawn and PIN signatures

A signature can be drawn on the device or applied from a stored signature with a PIN. Both are bound to the user and the device that produced them.

Attachments that cost nothing to retry

A photo is reduced on the device before it is sent, and its object key is derived from the row and the hash of its bytes — so a failed upload retried over a satellite link does not upload twice.

The same engine everywhere

Permits, toolbox talks, handovers, daily reports, job checklists and the checklists module all run here. One engine, one set of rules, one place a bug gets fixed.

The decision

Forms are not a feature, they are the substrate

Every ship management system ends up with forms. The ones that add a new form type by writing a new screen end up with six half-working engines and a rule that is right in four of them.

This product decided early that there is one engine and everything is built on it. It is why the checklists module was six weeks of work rather than six months, and why the next module will be too.

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.