Modules · 06
Handovers and forms
One form engine behind every signed piece of paper on board, with the wording frozen at the moment of signature.
What it is for
The requirement
ISM Code 11 — document controlValid documents shall be available at all relevant locations, and obsolete documents shall be promptly removed. A form that quietly changed its wording after it was signed satisfies neither half of that.
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.
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.
Screens
What it adds to the app
- 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
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.