PSC Code 10112. SIRE 4.1.1. RISQ 2.14. Same ECDIS Problem, Three Different Names.

A vessel picks up an ECDIS finding during a PSC inspection. Four months earlier, the ship’s own navigational audit flagged something that reads completely differently but is, on inspection, the same underlying issue. Eight months before that, a SIRE inspection raised a negative observation under a different question number again. Nobody connects the three, because none of the three systems does vessel deficiency trend analysis on your behalf — that connection has to happen somewhere else, or it doesn’t happen at all.

The Ship’s Navigational Audit Is Your First Line of Defence makes the case that when a finding surfaces at the outer rings — SIRE, PSC — instead of being caught at the ship’s own monthly audit, that’s already a signal worth reading. What doesn’t get discussed as often is what happens when the same underlying issue keeps reaching those outer rings, disguised as a new finding each time, because it arrives under a different code, from a different inspector, months apart.

One ECDIS Problem, Three Vocabularies

Take a single, ordinary example: an ECDIS finding. Here is how the three main ship inspection regimes record what is, potentially, the exact same underlying condition on the same vessel.

PSC — Paris MoU, Tokyo MoU, and the USCG all use the identical harmonised deficiency code 10112, “Electronic charts (ECDIS)”, filed under Safety of Navigation. The code says nothing about what was actually wrong — a defective unit, an incorrect safety contour, a missed software update, and a familiarisation gap all get logged under the same four digits.

SIRE 2.0 — Question 4.1.1 asks whether the Master and Navigation Officers were familiar with company ECDIS procedures, and whether records existed showing the ECDIS had been operated in accordance with those procedures throughout the voyage. A negative observation follows if settings were incorrectly entered without a passage-plan note, if a unit was defective, or if a required backup ECDIS wasn’t configured as one. The question is explicitly tied to TMSA KPI 5.1.2 — comprehensive navigation procedures, ECDIS named as one covered technology.

RISQ 3.2 — splits the same territory two ways. Question 2.14 asks specifically whether officers were familiarised with the installed ECDIS, with objective evidence of that familiarisation. Question 3.1 buries “ECDIS procedure (including chart and software updates)” as one bullet inside a much broader question about navigation procedures generally.

The company’s own records — a superintendent’s inspection report, an internal or external ISM audit and the ship’s own navigational audit describe the same condition again, in the company’s own format and wording, with no code in common with any of the above.

None of these cross-references another ship inspection. SIRE 2.0 states a link to the TMSA KPI it exists to verify, but that points to the office standard, not to PSC or RISQ. PSC’s code doesn’t point to SIRE’s question. RISQ’s two questions don’t point to PSC’s code. A vessel manager reading the three, and the company’s own reports, in isolation has no way of knowing whether they’re looking at separate weaknesses or one.

Closing the Finding Isn’t the Same as Recognising It

The Audit Is Closed. The Problem Isn’t. makes the case that closing a corrective action isn’t the same as fixing the root cause behind it. The problem this article is describing sits one step earlier than that. Before anyone can ask whether a root cause was actually addressed, someone has to recognise it’s the same cause at all — when the second and third instance of it arrive wearing a different code, from a different inspector, on a different inspection cycle, sometimes a year apart.

Nothing in PSC, SIRE or RISQ is designed to tell you these findings are the same finding. Someone has to recognise that before anyone can ask whether the root cause was ever actually fixed.

What This Costs a Superintendent Working From Spreadsheets, or Systems That Don’t Cross-Reference

What I see repeatedly across TMSA and SIRE preparation work is the same underlying condition logged two or three times under two or three different names, in two or three different registers, and nobody has connected them until someone sits down specifically to look for the connection — usually under pressure, ahead of a resubmission or a vetting cycle, not as a matter of routine.

That isn’t a failure of diligence. A superintendent managing a fleet is working from a PSC deficiency log in one format, a SIRE and RISQ inspection history in another, and internal navigational audit reports in a third — each using its own numbering, its own category structure, and its own descriptive language for what was actually found. It makes no difference whether those logs sit in spreadsheets or in a system that stores each source separately without cross-referencing them: either way the superintendent is shown separate lists, not a true picture of the vessel. Recognising that PSC code 10112 on one inspection, a SIRE 4.1.1 negative observation four months later, and a RISQ 2.14 finding on a sister vessel are all pointing at the same ECDIS familiarisation gap requires someone to hold all three vocabularies in their head at once, across a timeline that can span a year or more. Most fleets don’t have anyone whose job is specifically to do that.

Where Vessel Deficiency Trend Analysis Actually Happens

This is the specific gap MarineKPI is built to close. Every navigation audit finding, PSC deficiency, SIRE observation, and RISQ finding a fleet produces goes into a single record, cross-referenced against TMSA elements, RISQ categories, and SIRE 2.0 question numbers as it’s entered — not reconstructed afterward from separate systems when someone finally goes looking.

That structure is what turns “has this come up before, somewhere else, under a different name” from a question that requires someone to remember several coding systems into a question the record can answer directly. A PSC code, a SIRE question number, and a RISQ question sitting against the same vessel, close together in time, in the same underlying category, is visible the moment the third one is logged — not eighteen months later when a DPA finally cross-checks by hand.

None of this replaces the judgement a superintendent brings to deciding whether three findings are actually the same root cause or three genuinely separate ones. What it removes is the much more basic failure mode — never noticing there were three findings to compare in the first place.

→ See how MarineKPI works

More from the MarineKPI Series