What your assurance system isn't telling you

Strip away the superyacht and the headlines, and the Bayesian is a governance case. Here was an asset that had passed every gate a board relies on: classed by a recognised society, certified against the applicable code, operating with an approved stability document. By every artefact a director would point to, it was safe. Seven people died anyway — not because a rule was broken, but because the failure occurred in a condition no document had ever described.

"We were compliant" was precisely the owners' position. It is also, in almost every serious incident, the board's. Which is why the Bayesian is not a story about a boat. It is a story about the distance between what your assurance tells you and what is actually true.

A board does not see hazards directly. It sees assurance: safety cases, audit reports, verification statements, certificates of compliance. Each of these is a promise that controls are in place and effective. But each is also bounded — valid only for the conditions it actually examined. The board's confidence is therefore only ever as wide as the conditions its assurance assessed.

On the Bayesian, the approved stability document carried the right safeguard — limits to prevent a sudden gust from flooding the vessel — but only for its sailing conditions. For the condition it was actually in that night, at anchor under engine, the document was silent. The stability limit there was later calculated at 70.6°, against the 84.3°–92.3° the document had certified for other states. The approval was entirely real. The assurance was partial. And no one knew which part was missing until seven people were dead.

If your internal investigations keep arriving at "operator error", the board is being systematically misinformed — and not by anyone lying. It is being misinformed by method. An investigation process built to identify who acted will reliably produce a person. An investigation process built to identify what conditions made the act inevitable will reliably produce a system. The same event yields either answer depending on which process you commissioned.

That is a governance fact, not a technical one. The board, or its delegate, mandates the investigation standard the organisation uses. So the board owns the blind spot its method creates. You cannot delegate the methodology and disown the conclusions it was built to reach.

"The sole objective of a safety investigation shall be the prevention of future accidents. It shall not be the purpose to determine liability nor to apportion blame."

The Bayesian shows this in public. Its safety investigation, barred by law from apportioning blame, reached a latent condition — an undocumented vulnerability in the operating state. The parallel criminal investigation, built to assign liability, has reportedly looked at the crew. A board that quietly runs a blame-oriented internal process is making the same choice as the prosecutor: it is choosing to see acts, and therefore choosing not to see its own latent conditions.

When an investigation closes on an individual, the latent condition that produced the event stays exactly where it was. The control is "retraining" or "a reminder"; the vulnerability is untouched. So the event recurs — and the second time, it carries the board's name, because the record now shows the organisation knew and acted only against the person. That is the sequence that converts an operational failure into a governance and liability failure.

The Bayesian's parallel proceedings make the exposure concrete: "operator error" and "systemic cause" are now competing in public, in the press and in court, over the same seven deaths. A board that has only ever been handed the "operator error" version of its own incidents has no defence prepared for the day the systemic version surfaces — because it never commissioned anyone to find it.

You do not need technical depth to govern this. You need three questions — usable in any assurance review, and mandatory after any serious incident.

1. Which operating conditions has our assurance actually assessed — and which are silent? — Demand the list of operating states the asset actually runs in, mapped against what the safety case assessed. Red flag: management can describe the controls but cannot produce the list of unassessed conditions.
2. What was our last serious investigation built to find — system conditions, or individual acts? — Audit the method, not just the report. Red flag: the recommendations are dominated by retraining, discipline and reminders, and no latent organisational condition is named.
3. For every "human error" finding in the last 12 months, what latent condition remains in place? — Reopen the ones that ended at a person. Red flag: no one can answer, because the condition was never sought — which means it is still live, and still capable of producing the next event.

These three questions convert assurance from a comfort exercise — receiving confirmation that things are fine — into an oversight one: actively probing for the conditions no one assessed. That shift is the whole of the board's safety job.

A board's safety duty is not to receive assurance. It is to test what the assurance does not cover, and to insist on a method that reaches the system rather than a name. "Approved" is a statement about a set of conditions, not about reality. The conclusions you are willing to hear are the conclusions you have built the capacity to act on — and the latent condition you never asked about is the one that will arrive with your name attached.

"A board that only receives assurance is governing the conditions someone chose to assess — not the ones that will actually fail."