HMNZS Manawanui | 05 AcciMap
The accident above the bridge
Introduction
The cause was clear enough. The ship was in autopilot, nobody on the bridge realised it, and every attempt to steer or stop her was quietly discarded by a system doing exactly what it had been told.
But that is where most accounts stop, and the situation is more complex than it looks.
A navy is a large organisation. Long before that evening, decisions had been taken about who would be posted to the ship and with what qualifications. About what training the crew would receive and whether it would be completed. About which tasks the vessel was cleared to perform. About what orders and procedures existed, and what to do where none existed. About how much would be asked of a lean workforce, and how quickly.
All of that was in place before anyone touched a control. Some of it reached down through the years and the ranks and arrived on the bridge that evening as a set of conditions nobody on watch had chosen.
This series looks at the loss through several analytical lenses, because no single one captures everything. In this post the lens is the AcciMap.
What an AcciMap is
The method comes from Jens Rasmussen, a Danish system safety researcher, in a 1997 paper called Risk Management in a Dynamic Society. Rasmussen had spent decades on control-room design and human error, and his argument was that safety is not a property of any one level of a system.
It emerges instead from decisions taken at many levels by people who mostly never meet — legislators, regulators, boards, managers, supervisors, operators — each of them optimising for their own local pressures. Systems drift toward accidents because every actor is rationally pushing toward efficiency and away from effort, and the boundary of safe operation stays invisible until it is crossed.
The AcciMap is the diagram that goes with that argument. It stacks causal factors in horizontal bands, one band per level of the organisation, and draws the links between them vertically.
Its real value is structural. In a conventional accident chain you stop where the story stops, and the story almost always stops at the person who touched the controls. An AcciMap makes the upper levels rows on the page — so if nothing is written in them, the emptiness is itself a finding. You cannot draw one that ends at the crew without the top half of the diagram sitting blank.
Which is exactly why it suits this case. The Court of Inquiry declined root cause analysis and published twelve unranked contributory factors. Drawn as a structure rather than a list, the same evidence says something the list cannot.
How to read the map
The loss of HMNZS Manawanui as an AcciMap. Each band is a level of the organisation; magenta marks the chain the Court identified as directly causal.
Author’s own work, reconstructed from the Court of Inquiry final report, 31 March 2025. Enlarge the map to filter it by path.
Read each band as a level of the organisation, and read downward. Government and strategic at the top, then the organisation, then local management, then the people on watch, then the equipment. Causation flows down the page.
The magenta chain is the direct causal path — the factors without which the grounding would not have happened. The grey links are contributory: real influences, but not sufficient on their own.
The bands matter more than the boxes.
Government and strategic holds the conditions set above the Navy: a lean and inexperienced workforce held to the same output, risk management training that the Court found inadequate across the service, and a risk culture weighted toward achieving the mission rather than completing it safely.
Organisation holds what the Navy did with the ship: surveying was never operationally released or approved by the Seaworthiness Board, force generation was never completed, people were posted without the required proficiency, and orders and procedures had voids where nothing existed at all.
Local management holds the ship’s own decisions: risk assessment not done, planning inadequate, haste, and a supervisor role that had never been defined.
Actor activities is the fourteen minutes everyone writes about.
Equipment is the layer that surprises people, because on this map it acts upward. The autopilot in speed mode turned an astern order into acceleration. The control mode could not be read — not by the crew, and not by the Court, which had to infer every mode change from thruster behaviour. These are not background conditions. They are causes acting on the bridge team in real time.
And then look at the right-hand column. Charges laid, by band: none, none, none, three officers, none.
That column is the whole argument, and it needed no commentary from me. Causation runs vertically. Accountability did not.
What is not on the map, and should be
A map like this is an argument, not a measurement. AcciMap has no taxonomy — nothing tells you what counts as a node — so two analysts working from the same report will produce different diagrams. That is a known weakness of the method, and the honest response is to say out loud what you left out.
Three things belong on it and are currently absorbed into broader boxes rather than named.
Was there a rule against autopilot near a navigational hazard? The report contains no such rule, and no discussion of one. What it does say is that significant deficiencies existed across a wide range of orders, instructions and procedures, including areas where no procedure existed at all, and that there was no standing procedure for the survey task. So the absence is real, but on my map it sits inside a general box about deficient orders. It deserves its own node, because it is the specific gap that made the mode change permissible.
Training, or drills? The map says force generation was incomplete and that the ship never completed a work-up after entering service. Those are different failures and I have collapsed them. Knowing a procedure and having rehearsed it under pressure are not the same capability, and the bridge cards for a thruster control failure were known and not actioned.
And a protocol for announcing mode changes. This one is missing entirely, and it is the sharpest of the three. The ship changed control mode four times in nine minutes and not one change was announced. The report is explicit that the course alteration onto 340 degrees — the heading that killed her — has no verbalisation anywhere on the recording.
On my map that appears only as an event in the actor band: four undeclared mode changes. But an undeclared mode change is only a failure if something required it to be declared. Nothing did. There is no node in the organisation band saying no protocol required control mode to be spoken aloud, and there should be, because that is where the failure actually lives.
Put it there and the geometry changes. What looks like four lapses by one officer becomes one missing rule, applied four times.
What the method cannot hold
There is one more gap, and it is not mine.
Researchers comparing accident analysis methods have noted that AcciMap’s actor level represents flawed decisions without identifying what shaped them — no slot for situation awareness, no slot for operator mindset. The method is built to make the levels above the operator visible. It is not built to look inside the operator.
So the map is accurate about what happened and silent about why a competent officer, holding a procedure he had been trained on, did not reach for it.
The Court was silent in the same place, and filled the silence with a judgement: the officer of the watch should not have been distracted.
Two different disciplines, arriving at the same blank space and handling it the same way.
The map is reconstructed from the Court of Inquiry into the loss of HMNZS Manawanui, final report dated 31 March 2025, with paragraph references on each node. Paragraphs 83 and 84, the Court’s discussion of direct causes, are redacted in the public version; the direct-cause chain is reconstructed from paragraph 277 and the sequence at paragraph 61. One node — the absence of an external regulator — is inference rather than a finding, and is marked as such.
About
YachtPrep Team
YachtPrep Team is a passionate developer and boating enthusiast with years of experience in web development and maritime activities. They love sharing knowledge and helping others navigate the waters of both coding and boating.