Ship certification is built on type approval: an artefact is tested once, stamped, and identical copies are assumed identical. Software assurance for AI breaks every assumption of that model — the system changes (retraining, updates), its internals are not inspectable in the way a pump's internals are, and its performance depends on data that varies with deployment. The MASS Code needs to verify AI; the certification apparatus was built to verify equipment.
This is the least-solved problem in autonomous-ship regulation — and the one the experience-building phase exists to figure out.
Key findings
- Type approval presumes a static artefact; a learning system violates that presumption in three ways — it updates, it's opaque, and it's data-dependent. Established
- The MASS Code's goal-based structure is the workaround: certify the <em>safety case</em> and the <em>change process</em>, not the weights — how the system is verified, not what it contains. Established
- The aviation analogue (DO-178 for software, and the harder problem of learning-enabled systems) is the closest template — and it's not yet solved there either. Established
- Assurance anchors are emerging: scenario-based testing, simulation-plus-trial evidence chains, and runtime assurance envelopes. Research demonstration
- The unresolved core is change management — how a model update gets recertified without re-surveying the ship. Maritime-GPT analysis
Why AI defeats the survey
- <strong>It changes.</strong> A certified neural net that gets updated weights is a different system — the certification refers to a version, not a product. Established
- <strong>It's opaque.</strong> A surveyor can test a valve; a vision model's internal representation can't be inspected for correctness — assurance must come from behaviour, not anatomy. Established
- <strong>It's data-dependent.</strong> The model's performance is a function of the data it trained on — which varies by vessel, route and season in ways the certifier didn't see. Established
- <strong>It's stochastic.</strong> Two runs of the same input can differ; the pass/fail model of a survey assumes determinism the system doesn't have. Maritime-GPT analysis
The goal-based workaround
The MASS Code's response is structural: it doesn't say 'the AI must be a certified artefact'; it says the ship must meet safety goals and the operator must demonstrate how they are met — including how the AI is verified, how it's kept verified through updates, and how it degrades safely. The assurance object becomes the <em>process and the evidence chain</em>, not the model weights. It's the same shift aviation is making from DO-178's static assurance to the harder problem of learning-enabled system certification. Established
The emerging assurance stack
- <strong>Scenario-based testing.</strong> Defined test scenarios (encounter types, failure injections) that the system must demonstrably handle — the coverage argument replacing code coverage. Research demonstration
- <strong>Sim-to-real evidence chains.</strong> Simulation for breadth, sea trials for validation, a documented link between them — the certification evidence as a chain, not a stamp. Research demonstration
- <strong>Runtime assurance.</strong> A certified supervisory layer that bounds the uncertified model's actions — the 'the AI can be wrong, the gate can't' pattern. Proposed
- <strong>Change-control certification.</strong> Processes that certify the <em>update mechanism</em> — regression tests, staged rollout, rollback — so a model can evolve without resurvey. Proposed
The honest current state
No classification society has a settled answer to AI assurance — the societies are working on it (DNV, LR and others publish frameworks), but the certification path for a genuinely learning navigation system is an open research-and-regulation problem, not a solved process. The MASS Code's non-mandatory status is partly because the assurance technology doesn't exist to make it mandatory yet. Established
What we know
- Static type-approval is incompatible with learning systems.
- Goal-based certification (safety case + process) is the code's chosen mechanism.
- Scenario testing + runtime assurance are the emerging assurance patterns.
What we don't
- A completed certification of a learning navigation system under class.
- How updates recertify without operational shutdown.
- Whether scenario coverage can ever substitute for field mileage.
Being tested
- Scenario-library development for collision and fault cases.
- Runtime assurance / safety-envelope supervisory layers.
- Continuous-certification processes for updating models.
Maritime-GPT analysis
Assurance is the reason the MASS Code is a decade from mandatory, not a year. The engineering can produce the system; the certification can't yet verify it — and the two problems are now the same problem. Watch the classification societies: whoever publishes the first credible AI-assurance standard doesn't just unlock autonomous shipping, they define what 'safe enough' means. Maritime-GPT analysis
This is a research feature, not operational guidance. Simulation results are reported as simulation; demonstrations are not deployments; company claims are attributed as such. Verify safety-critical decisions against official nautical publications and flag-state requirements.
Sources & evidence
The goal-based certification framework the assurance problem sits inside.
The adjacent assurance track — software/system verification as class requirement.
The closest template — and evidence that learning-system certification is unsolved even in aviation.