The Manual Got Sent. Version Control Isn’t the Same as Received.

Version control has two requirements built into it under ISM 11.2, and most fleets satisfy only one of them reliably. Clause 11.2.1 requires valid documents to be available at all relevant locations. Clause 11.2.3 requires obsolete documents to be promptly removed. A Word file distributed by email can usually manage the first, eventually. It structurally can’t guarantee the second, and the reason has nothing to do with anyone’s diligence.

What Version Control Actually Requires

Email-and-track-changes redistribution isn’t one action, it’s a chain of them: someone sends the file, someone on each vessel receives it, opens it, replaces the old copy, and — this is the step that quietly fails — deletes or archives the version it replaced.

Every link in that chain is a separate person doing a separate thing, on their own schedule, with no shared record of whether it happened. The office can confirm the email went out. Confirming the old copy is actually gone from a specific vessel’s shared drive is a different question, and usually nobody’s asking it until an audit does.

That’s not a discipline problem. It’s what happens when “promptly removed” is implemented as a series of independent, unverified human actions instead of a single controlled state. Every fleet I’ve reviewed has at least one vessel working from a version that’s technically superseded, not because anyone was careless, but because the chain has exactly as many failure points as it has links.

Sent Isn’t the Same as Current

A copy, once sent, is out of your control in a specific and structural sense: it’s a fork, not a live pointer back to the source. The moment that Word file leaves the office, it stops being the same object as the one still being edited there.

Whatever happens to the master document next — another revision, another correction — has no path back to the copies already sitting on twenty different vessels. Redistribution isn’t a bridge between those two states. It’s a second, separate send, with the same chain of failure points as the first one.

This is the actual distinction between “distributed” and “current.” Distributed means a copy went somewhere. Current means whatever’s being read right now is provably the same as what the office approved last.

A system built around sending files can promise the first. Only a system where there’s one copy, read from everywhere, can promise the second — which is what version control is supposed to mean in the first place.

Where Wayfinder Fits In

This is where Editor Workflow does the actual version control work, and it connects directly to the review process the flag itself goes through.

A change enters as a draft, gets diffed against the current version so the DPA and editor are reviewing an actual before-and-after, not trusting memory of what changed, and gets approved through the same reviewed-and-approved path any document control decision requires. Publishing doesn’t trigger a send. It changes what every vessel is already reading, because there was never a separate copy to update in the first place — one system, not one file times however many ships are in the fleet.

It’s worth being precise about what that does and doesn’t solve. It doesn’t guarantee a crew member has read or understood the update — that’s a separate problem, closer to training and comprehension than to document control. What it solves is narrower and more foundational: whether the thing available to be read is, provably, the current one. Sent stops being a meaningful category at all once there’s nothing to send.

The Practical Point

Across this series, the shape has been the same question asked from five angles: does the procedure exist, can it be found, can it be found in the language someone’s actually thinking in, who’s allowed to change it, and now — once changed, is what’s on every vessel actually the current version, or just a copy of what used to be. A gap analysis answers the first question well. None of the other four are questions a document, however well-written, can answer on its own.

See how Wayfinder keeps every vessel on the current version →

More from the Wayfinder Series

Gaurav Khanna
Gaurav Khanna

Capt. Gaurav Khanna is the Founder and Director of Vraga Marine Services. He began his sea career in 1995 and spent 18 years working up from cadet to Master on product tankers and crude carriers across the Persian Gulf, North Sea, and Baltic trades. Coming ashore in 2013, he moved into fleet management with a Japanese ship management company, rising to Sr. Deputy General Manager and Branch Head with direct responsibility for fleet safety, vetting performance, and SMS compliance across a mixed tanker fleet. In 2021 he founded Vraga Marine to bridge the gap between compliance documentation and operational reality — combining VDR-based navigational auditing, SMS redesign, remote pre-inspection services, and physical inspections for ship managers across Asia, Europe, and the Middle East. He is formally qualified as a Lead Auditor, Navigation Assessor, and VDR Data Analyser, with additional certifications in crisis management, risk assessment, and management systems.

Articles: 58