The Understanding Problem — The Trials Deck No. 4: where a machine's understanding of a boat actually comes from.

Michael Healey and I connected this week over his piece, The Captain, The Computer, and the Future of Seamanship. It is worth reading in full, and one line in it is the cleanest statement of the problem I have seen from outside the trials side of this business:

“The question is not whether a computer can control a boat. The question is whether it can truly understand one.”
— Michael Healey

That distinction is correct, and it is the reason this series exists. I want to take it one step further than the article does, because I think the answer to “can it understand?” has a specific, locatable address — and it is earlier in the vessel's life than most of this conversation assumes.

Understanding is not a compute problem

The instinct is to treat understanding as a capability that arrives with enough processing power, enough sensor coverage, enough model. It doesn't. Understanding, in the sense Michael means it — knowing that the other operator is about to overcorrect, knowing where the stern goes before the wind takes it — is not computed in the moment. It is retrieved. It is a prior, built from outcomes.

That is the mechanical difference between processing and anticipation. A sensor captures state. An experienced captain carries weighted outcomes: thousands of hours in which a particular set of conditions resolved a particular way, including the times it resolved badly and cost something. The weighting is the expensive part. It is acquired at cost, over decades, and it cannot be inferred from a data stream that never carried consequence.

So the question is not whether the machine can eventually hold that weighting. It can hold it. The question is where it gets it.

It gets it by transfer.

The transfer has an address

The first three installments of this series laid the groundwork. The Sea Trial Problem argued that autonomy quality is bounded by the operational envelope established during design, commissioning, and validation. The Transfer Standard asked what has to be true of that envelope for it to be worth inheriting. The third piece made the case that the baseline is not a machine artifact or a human artifact — it is a joint product, established at the interface, where human senses and machine sensing calibrate against each other in real conditions.

This is the practical consequence: a system cannot exercise judgment outside the envelope it was baselined into. Whatever seasoning it eventually appears to demonstrate in service was placed there during trials, by people who knew what optimal operation looked like and, more usefully, what it didn't.

That is why I keep pushing back on treating trials as the last checkbox before delivery. Trials are where the ceiling gets set. An under-specified trials program does not produce a vessel that is 90 percent as good. It produces a vessel with a permanently narrower envelope, and nothing downstream — no software revision, no fleet-learning pass — widens it until somebody goes back out and re-baselines it against the real world.

The obvious objection: simulation

Simulation and reinforcement learning appear to break this argument. A model can accumulate millions of hours of synthetic experience without a single human aboard, without cost, without consequence. Why does anyone need a captain in the loop?

Because simulated experience is acquired against a model of the world, and the fidelity of that model is bounded by what was measured — during trials. The sim-to-real gap is not a software defect to be engineered away. It is the distance between the envelope you characterized and the envelope that actually exists. Millions of synthetic hours inside a model that never captured how a particular hull loads up quartering into a short chop at three-quarter throttle will produce a system with high confidence and no reference.

Confidence without reference is the specific failure mode worth worrying about. It doesn't look like hesitation. It looks like a clean, decisive, wrong maneuver.

So — will AI replace captains?

In certain scenarios, yes, and it should.

Station-keeping. Docking in a known basin under characterized conditions. Watchkeeping through hour eleven, when human attention is measurably degraded and the machine's is not. Repetitive, well-bounded, heavily instrumented work where the envelope is fully mapped and stays mapped. Those are machine problems, and human insistence on holding them is sentiment, not seamanship.

But Michael's list is the other half of the ledger, and he's right about all of it. The channel that shifted. The stump lodged mid-channel after a winter storm. The thirty-footer whose operator has not yet worked out what is about to happen to him. Those cases share one property: they fall outside the characterized envelope. The machine has no prior. The captain does.

The sure bet, near term, is not replacement in either direction. It is symbiosis — machine sensing and machine reaction operating inside an envelope that experienced human judgment established and continues to correct. That is not a compromise position. It is the only configuration in which both parties are doing what they are actually good at.

The addendum

Michael closes by suggesting the future may not be a world without captains, but a world with a better first mate. I think that is the correct landing point, and I'd add one line to it:

The mate is only as good as the captain who trained it — and that training happens during trials, at the interface, before the vessel ever carries a customer.

Which puts a specific obligation on the builders. Put experienced operators in the trials loop, not just at the delivery handoff. Document where the envelope ends and why, not just that the vessel passed. And when the person at the helm says that doesn't feel right, treat it as an unresolved data point requiring closure — not as noise from someone who doesn't read telemetry.

That sentence is the whole transfer. Everything the machine will ever know about understanding a boat is sitting in it.

Captain Carl McBride is the principal of Boater Ventures International LTD. He holds a USCG Master license (100 GT) and has spent 45+ years in high-performance hull design and fabrication, marine systems commissioning, propulsion R&D, forensic marine survey, and high-performance powerboat instruction and certification. The Trials Deck series examines how operational baselines are established, transferred, and inherited by autonomous marine systems.