The IMO autonomy code makes ship functions more important than the autonomy label

A vessel can navigate automatically while people make its route decisions, monitor machinery or handle exceptions from shore. Calling the whole vessel autonomous hides those distinctions. As machines share busy waterways with conventional ships, describing each function and its responsible organisation becomes more useful than assigning one broad label.

The International Maritime Organization’s May 22, 2026 announcement records adoption of the Maritime Autonomous Surface Ships code, effective from July 1 for its stated commercial scope. Its FAQ emphasises a functional approach and continuing master responsibility. The framework concerns commercial shipping. It should not be presented as certification of a particular naval system or a substitute for military mission testing.

Divide the ship into functions

A useful functional account asks what is performed locally by software, what is done remotely and what still requires people aboard. Navigation, watchkeeping, machinery and emergency handling can have different answers. That account exposes dependencies that a simple remote-versus-autonomous category misses, particularly when the operator’s role changes during an exception.

For a defense buyer, the lesson is methodological. A surveillance craft’s local navigation might be mature while its intelligence interpretation remains experimental. A logistics vessel might follow a route well but require human help during replenishment. Neither should inherit the strongest claim made for another function. Procurement language should connect each accepted capability to its actual conditions.

Human responsibility also has to remain practical. Naming a responsible person does little if that person cannot obtain the information or exercise the authority needed during a time-sensitive event. A remote operating concept should specify the observations available, communication delays and situations in which the local system must stop or continue. Those arrangements deserve testing rather than reliance on a role name.

This includes the conditions under which a system changes operating mode. A transition from routine automatic operation to human assistance can fail if the operator lacks context. The functional record should preserve what happened before the handoff and explain which action is now expected. A clean interface screenshot cannot establish that the transition works under realistic workload.

A framework is not a performance result

The code can help create a common way to organise assurance, but it does not measure a vehicle’s behaviour by itself. Conformance to a stated process and success in a particular traffic encounter are different forms of evidence. A buyer should retain both where relevant without using one to imply the other.

There is a countercase to importing commercial expectations too directly into military operations. Naval missions can have distinct authorities, hazards and operational requirements. The commercial framework’s jurisdiction must remain explicit. Its value to the autonomy debate is the disciplined description of functions, not an assumption that every requirement transfers unchanged to a warship.

An informative military test could use the same functional clarity while choosing its own mission conditions. Report who handles navigation, fault diagnosis and mission decisions, then record interventions and mode changes. That makes it possible to compare systems that use different mixes of automation and remote supervision on the same practical job.

The industrial consequence is more precise responsibility at interfaces. If a sensor supplier, autonomy supplier and operating service perform different functions, acceptance criteria should identify their boundaries. A single autonomous-system claim can make failures difficult to assign. Function-level evidence lets the customer see whether an improvement belongs in the machine, the communications link or the operating organisation.

Follow the handoff between people and software

The functional approach also helps a reader ask a concrete question about a new ship: which action is the machine trusted to perform, and who handles the next step when that action cannot continue? A navigation demonstration might answer the first part for an ordinary route while saying little about a machinery problem. Describing the functions separately keeps those uncertainties available for examination.

A useful assurance record would follow a mode change from beginning to end. It would identify what prompted the change, the information presented to the responsible person and the authority available to that person. That prevents responsibility from becoming a paper assignment detached from an operator's practical ability to influence the vessel. These are suggested evaluation questions, rather than additional obligations attributed to the code.

For the defense debate, this offers a clearer vocabulary for buying mixed systems. People and software may each perform different parts of one mission. The meaningful advance is that their contributions can be specified and assessed, making it easier to identify where a failure occurred and what evidence would support a subsequent improvement.