Your Incident Form Asks for a Cause. That Question Is the Problem.

Every incident report ends up in front of a drop-down. Somewhere between the narrative and the corrective action, the form asks the reporter to pick a cause, and the list of causes on offer is the incident reporting taxonomy. It looks like a neutral filing system. A report published in 2026 by DNV and Equinor, CLUE (Contextual Learning & Understanding of Events), argues it is anything but: the categories on the form shape how an event is understood before anyone has analysed it.

I read it against the coded technique I wrote about in Root Cause Analysis in Shipping, and the two don’t sit comfortably together. That’s worth working through, because ISM Section 9, TMSA Element 8 and RISQ all expect incidents to be investigated and analysed without saying which taxonomy to use. The choice is the company’s, and it matters more than it looks.

What an Incident Reporting Taxonomy Actually Does

The report describes a reporting system in four stages: a narrative of what happened, an assessment of consequence, a classification of contributing factors, and the corrective actions. The taxonomy formally sits at the third stage, but its influence runs into the fourth. The report’s argument is that the categories available to the reporter decide which explanations look credible, and so which actions get written. Classification isn’t a neutral record made after the thinking is done. It is part of the thinking.

What the Codes Make Easy to Say

The report’s criticism is aimed at deficit-based language: categories such as “failure to follow procedure”, “lack of competence” or “incorrect action”. Drawing on Dekker, Reason and others, it argues that labels like these carry a hindsight judgement that someone should have acted differently, so incidents are framed as failures of people rather than outcomes of conditions. Corrective actions then gravitate, in the report’s words, toward training, supervision or procedural reinforcement. Those rarely change the conditions that made the behaviour reasonable at the time, and the report adds that they can suppress reporting by implying blame.

The report names SCAT and HFACS, not MSCAT, and its point about both is that they were built for post-incident investigation and then repurposed for high-volume, low-severity reporting. MSCAT was likewise designed to analyse incidents, and the report doesn’t test it, so nothing here is a criticism of the method. The narrower question is whether a vocabulary written for investigation reads the same way on a routine near-miss form. That is one for each fleet to answer from its own register.

Two further observations from the report are worth keeping. A customer that changed the order of the codes in its reporting system found the codes listed earlier were used more often. And the project team’s own review of incident data found that a few codes, often related to human error, dominate the causal picture even where the taxonomy is large. The report gives no figures for either, but it draws the same conclusion from both: a finer-grained taxonomy doesn’t necessarily produce more nuanced data.

What CLUE Proposes Instead

CLUE replaces “cause” with “contributing factor” and offers 26 factors in four groups: task, individual, organisational, and workplace and equipment. The wording is descriptive rather than judgemental. Examples include available time, workload, conflicting priorities, availability of information, software, and workarounds and adaptations. The structure is flat, with no split between immediate and basic causes. Reporters are prompted to select several factors, typically two to five, after writing a narrative of what happened.

Two design choices stand out for anyone used to coded techniques. Gross negligence is kept as an exceptional code, to be used sparingly and only where clear evidence exists. And “risk perception”, a staple of many lists, was deliberately left out because the authors judged it highly counterfactual. Some established lists, MSCAT’s among them, do carry such a code, so this is a difference of design rather than a flaw in either approach.

What the Report Doesn’t Show

CLUE is a proposal, not a validated method, and it should be read that way. Its user survey had 60 respondents, five of them from maritime, and the 84% who found the titles and descriptions clear were rating the labels, not whether the taxonomy improves outcomes. The authors list validating intercoder reliability and evaluating the actions that result as future work. They also state the cost: with the causal layers removed, it becomes harder to extract statistics on substandard acts.

Importantly, the report says CLUE is meant to supplement root cause analysis and not necessarily replace it, with serious events escalated to traditional methods. That is where the argument in the earlier article sits, and the two are not in conflict. A layered, coded technique is built for a casualty or a serious finding. The open question is whether the same vocabulary belongs on a routine near-miss form.

Where ISM, TMSA and RISQ Leave the Choice Open

ISM 9.1 asks for procedures ensuring non-conformities, accidents and hazardous situations are reported, investigated and analysed with the objective of improving safety and pollution prevention, and 9.2 asks for corrective action “including measures intended to prevent recurrence”. TMSA 8.2.1 asks that the root causes and factors contributing to an incident or significant near miss are accurately identified, with a systematic methodology or tool as best practice, and the guidance under 8.2.4 says the reporting system should be simple and user friendly. RISQ 4.10 (version 3.2) asks whether the reporting, investigation and close-out procedures are followed, and whether an investigation report or lessons learned bulletin exists for each reported incident. What a RightShip RISQ Inspection Actually Tests covers the wider inspection.

None of the three names a taxonomy. TMSA 8.2.1 even speaks of factors contributing to an incident alongside root causes. The usability point in 8.2.4 is the one the report speaks to most directly, and the prevent-recurrence test in ISM 9.2 is the one its criticism of retraining speaks to.

The Practical Point

The corrective-action column is where an incident reporting taxonomy shows itself. A fair question to put to any fleet’s register: of the actions closed over the last year, how many are retrain, remind or reissue, and does the list of causes on the form make those the easiest thing to write? If so, the form may be doing some of the explaining that the crews are being blamed for. The Audit Is Closed. The Problem Isn’t. describes the same pattern from the audit side, and Your Near-Miss Reporting Looks Healthy describes the gap between accumulating data and learning from it. That gap may start at the form.

CLUE won’t suit every fleet, and the evidence for it in shipping is still thin. But it makes a useful point about every incident reporting taxonomy, including the one a company already uses: the vocabulary is a design decision, and it deserves to be made deliberately rather than inherited. In MarineKPI, the root cause of an inspection finding is recorded against the method the company has chosen, with DNV MSCAT as one of the options, so the choice is a visible setting rather than an accident of the form.

→ See how MarineKPI works

More from the MarineKPI Series