The Chief Engineer Handover Checklist Most Yachts Don't Have

Why a paper handover checklist fails on a superyacht

A chief engineer is rotating off. The relief arrives. In the best case they have a week aboard together. In practice the outgoing engineer often departs before that week is out. A Seahub industry survey found that 66% of engineering handovers last one week or less, and that there is no industry-standard format for the task — each engineer approaches it from personal experience and individual diligence [1].

The same survey noted that outgoing engineers sometimes minimised or failed to disclose vessel problems, with common phrases including "never had a problem with it" and "was serviced last week" [1]. So the transfer depends on the character of the person leaving, not on the systems the vessel runs.

A paper checklist does not fix this. The Manta Maritime Chief Engineer's Handover Checklist, published in 2014, remains one of the few structured templates the industry has [3]. It is a genuinely useful document — but it is a checkbox form. It captures that a box was ticked, not the context behind it: which fault is still open, what was tried, why a maintenance task was deferred, which supplier actually delivers to the vessel's regular ports. A box ticked "machinery — satisfactory" carries none of that. The knowledge a paper form cannot hold is exactly the knowledge that walks off the gangway.

What a proper chief engineer handover checklist must cover: seven domains

A handover that survives a rotation has to carry seven connected domains. The order is deliberate — each later domain depends on the earlier ones being honest.

1. Equipment inventory and condition. Not a list of what is aboard, but the current operational state of each critical system: what is fully functional, what is degraded, what has been modified from original specification and why.
2. Outstanding defects and open work orders. Every known fault, its diagnosis status, what has been tried, what worked and what did not — the history behind the defect, not its bare existence.
3. Maintenance system status. What is current, what is overdue, and what was deferred deliberately. Deferred maintenance without documented reasoning is indistinguishable from neglected maintenance.
4. Parts on order and supplier contacts. What has been ordered, from whom, expected delivery, and the fallback source if the primary supplier fails. The supplier relationships an incoming engineer would otherwise spend months rebuilding.
5. Certificates and the compliance timeline. Which certificates expire before the next yard period, which flag-state or class surveys are approaching, and whether the supporting documentation is current. Certificates tracked to expiry, with renewal dates and the source PDF attached.
6. Safety-critical procedures specific to the vessel. Emergency shutdown sequences, bilge and fire-zone configuration, and any procedure that deviates from the manufacturer default because of how this vessel was built.
7. Operational notes. The undocumented knowledge — which behaviours are normal for this vessel, which alarm thresholds were adjusted and why, which equipment needs watching beyond its maintenance interval. This is the domain a verbal walk-around attempts to cover in an afternoon and almost always fails to transfer.

Engine room handover checklist: applying the seven domains

The seven domains are abstract until you walk them through the machinery space. This is the part a generic checklist skips, and the part the relief engineer needs most in their first week alone on watch.

Generators. Running hours against the service schedule, any load combination that produces an alarm or a temperature the previous chief learned to avoid, and the part that was substituted at the last service because the OEM item was on a six-week lead time.

Watermakers. The flushing sequence that keeps the membrane from cavitating, the actual output against rated capacity, and whether the high-pressure pump has a known quirk on start-up.

Bilge and fire configuration. Which bilge wells are alarmed and which are checked by hand, the fire-suppression zone mapping, and any isolation that differs from the as-built drawings after a refit.

Alarm thresholds. Every alarm set-point that has been adjusted from the manufacturer default, with the reason. An unexplained adjusted threshold is a trap for the next engineer — it reads as normal until the day it matters.

None of this lives in the planned-maintenance system. It lives in the outgoing engineer's experience, and unless it is written down against the specific equipment, it leaves when they do.

Why the ISM Code does not solve the handover problem

The International Safety Management Code addresses crew transitions. Section 6 requires that new personnel be given proper familiarisation with their duties; Section 10 requires the company to keep the ship maintained in conformity with the rules and to record inspections, non-conformities, and corrective actions [4]. These are necessary. They are not sufficient for knowledge transfer.

The ISM Code requires that maintenance records exist. It does not require that they be connected across domains. A fault log does not link to the work order it generated; a work order does not link to the parts ordered; a parts order does not link to the warranty claim it supports. Each record sits in its own silo, findable only if you already know what you are looking for and where it was filed. The REG Yacht Code, which superseded the MCA's LY3 for Red Ensign vessels, similarly defines documentation standards without prescribing a structured handover format [5].

The gap between "records exist" and "knowledge transfers" is where the cost lands. When the engineer who did the work is gone and the records are scattered, a warranty claim that should be straightforward becomes indefensible — and a single denied claim on a main engine or generator can reach well into six figures [2]. The owner absorbs the loss not because the maintenance was skipped, but because the evidence left with the engineer. The records were there. The connections between them were not.

What the captured handover draft contains

This is where a software checklist diverges from a paper one. The difference is not a prettier form. It is when the entries get made.

The most reliable handover is the one that was never a separate task. Every record an engineer closes — a fault, a work order, a note — offers a single tap to add it to the handover draft. The draft accumulates as the engineer works, so months of context build up as a by-product of normal work rather than being reconstructed from memory in the week before crew change. The discipline is deliberately plain: it is captured as you work, then reviewed and signed — the system proposes the entries, and the engineer decides what goes in.

When the rotation comes, the draft is reviewed, not written from scratch. The outgoing engineer signs. The incoming engineer acknowledges, in writing, that they have read and understood the operational state of the vessel. Both signatures are timestamped, and the handover is locked after dual signature. The result reads like a dated technical report a surveyor can hold — a document number, the period covered, and the contents listed by department.

Every entry resolves to a live record

What keeps the handover useful months later is that each entry stays connected to the work behind it. The handover is a live index into the vessel's operational data, not a static document. Open a single line — a starboard chiller short-cycling — and the original fault, the work order with its labour hours, the replacement part, and the OEM bulletin cited in the diagnosis are each one click away. The incoming engineer reads the line, follows it, and lands inside the live record itself. The incoming engineer inherits context, not chaos.

This is the practical answer to the paper checklist's core failure. A line that reads "watch the starboard chiller" is worth less than the fault it refers to, the work order that addressed it, the part that was fitted, and the bulletin behind the diagnosis. A handover built from one-tap captures keeps all of that attached — reviewed, then signed by both parties.

The record that holds up after the crew has gone

A handover checklist is also a record someone may need to defend later. Every action — logging a fault, creating a work order, signing a handover — is attributed by signed-in user and role, and timestamped. The trail is append-only: nothing is overwritten, corrections are recorded as new entries that reference the original, and the original remains intact. That matters most exactly when crew have rotated and the only account of what was handed over is the one the vessel kept. The records are independently verifiable at verifier.celeste7.ai. For how an append-only audit trail stands up under inspection, see the companion piece.

The point is not to replace the engineer's judgement. The system proposes; the engineer decides what enters the draft, reviews it, and signs. CelesteOS runs alongside the existing planned-maintenance system — nothing to replace, nothing to migrate — so the vessel keeps its own memory across every rotation. It is the difference between a checklist that depends on one person's diligence and a record the boat holds for itself, the way the next chief would actually need to inherit it when knowledge would otherwise walk off the vessel.

Frequently asked questions

Summary

• Engineering handovers on superyachts lack a standard format; most last a week or less and depend on individual diligence rather than the vessel's systems.
• A paper checklist records that a box was ticked, not the context behind it — and context is what walks off the gangway.
• A proper handover covers seven connected domains: equipment condition, defects, maintenance status, parts and suppliers, certificates, safety procedures, and operational notes — applied concretely to generators, watermakers, bilge and fire config, and alarm thresholds.
• The ISM Code and flag-state rules require records to exist; they do not require connected, searchable, transferable knowledge.
• A handover captured as the engineer works — reviewed, signed by both parties, with every entry resolving to a live record — keeps the vessel's memory aboard across rotations.

CelesteOS keeps a superyacht's operational knowledge in the vessel — faults, work orders, parts, certificates, and handovers, connected and searchable, captured as the crew works. Learn about the pilot.