How Do You Handle Requirements When the Standard You Are Designing To Has Not Caught Up With Your Technology?

Here is the scenario: your team is building an autonomous surface vessel (ASV) for offshore inspection. The system uses multi-modal sensor fusion, machine learning-based collision avoidance, and a remote operations center that can supervise up to twelve vessels simultaneously. You need to certify. You open the relevant standard — COLREGS for navigational behavior, maybe IMO MSC guidelines, perhaps a flag state’s own marine regulations — and you immediately see the problem.

The standard assumes a human watchkeeper on the bridge. Every rule about collision avoidance is written in terms of what a human mariner shall do. The standard does not contemplate an algorithm making a give-way decision. It does not cover how you validate an ML model’s behavior in degraded sensor conditions. It does not address the supervision ratio for remote operators, or what “proper lookout” means when the lookout is a camera array processed by a neural network.

This is not a fringe situation. It is the defining engineering challenge of any sufficiently novel system: you are ahead of the standard, and you still have to ship.

Why Standards Lag — And Why That Is a Solved Problem in Other Domains

Standards lag technology because they are written to codify existing practice, not to anticipate new capabilities. This creates a predictable gap whenever a new technology class emerges. The gap is not a regulatory failure; it is the normal state of affairs for novel systems, and regulators know it.

What this means practically: regulators — whether maritime classification societies like DNV, Lloyd’s Register, or Bureau Veritas, or national administrations operating under IMO frameworks — have established procedures for handling exactly this situation. Those procedures exist because they have had to handle it before. The eVTOL certification programs at the FAA (using Part 23 and Special Conditions), the European Union Aviation Safety Agency’s approach to novel VTOL aircraft, and the NHTSA / FMCSA engagement with autonomous trucking all followed the same pattern: the technology moved first, the formal standard followed years later, and programs were certified in the gap using structured engineering arguments rather than checklist compliance.

That pattern gives maritime autonomous programs a body of practice to draw from, even if the specific domain differs.

The Three Tools Teams Actually Use

1. Alternative Means of Compliance (AMoC)

An AMoC is a formal proposal to a regulator or classification society that says: the existing requirement was written with a specific implementation in mind; I cannot implement it that way; here is what I am doing instead; here is why my approach provides equivalent or better safety.

AMoC is not a waiver. A waiver says “we do not have to meet this requirement.” An AMoC says “we meet the intent of this requirement through a different means.” That distinction matters enormously in how regulators receive it, and in how you structure your engineering argument.

A well-constructed AMoC has five components:

  • Identification of the originating requirement — the exact rule, clause, or standard you cannot comply with literally
  • Reason for non-compliance — why the literal requirement does not apply or cannot be implemented (e.g., “no human watchkeeper is present to execute COLREGS Rule 5”)
  • Proposed alternative — what your system does instead, described with sufficient technical detail that a regulator can evaluate it
  • Safety equivalence argument — evidence that the alternative provides the same or better safety outcome as the original requirement intended
  • Verification method — how you will demonstrate that the alternative is actually implemented and performing as claimed

The quality of the AMoC depends entirely on the quality of the safety equivalence argument. That argument is built from hazard analysis, not from assertion.

2. Issue Papers and Certification Review Items

In aviation, the FAA formalized the AMoC concept into “Issue Papers” — documented agreements between the applicant and the regulator about how a specific novel or unusual design feature will be handled. Classification societies have analogous instruments: DNV’s “Qualification of New Technology” process, Lloyd’s Register’s Technology Qualification process, and Bureau Veritas’s Innovation and Research qualification pathway all serve the same function.

The value of these instruments is that they produce a documented, agreed basis for certification before you have finished building the system. You are not waiting until the end of the program to discover that the regulator disagrees with your approach. You are aligning on the approach early, which means your requirements and design can be structured to satisfy the agreed argument.

For maritime autonomous programs currently operating, this means engaging your flag state, your classification society, and (where applicable) IMO correspondence groups early — before the design is locked. The qualification basis you negotiate becomes the effective standard against which you are designing.

3. Self-Constructed Compliance Frameworks

When no standard exists at all for a specific capability — and for ML-based collision avoidance at scale, nothing fully prescriptive exists — teams must build their own compliance framework. This means:

  • Identifying the analogous standards from adjacent domains (aviation DO-178C / DO-254 for software and hardware, ISO 26262 for automotive functional safety, IEC 61508 for industrial safety-critical systems)
  • Selecting and adapting the applicable elements with documented rationale for why each element was selected, adapted, or excluded
  • Constructing a compliance matrix that links every safety objective to at least one verification activity and at least one design requirement
  • Making the framework auditable — a regulator reviewing your safety case should be able to trace any claim back to evidence

This is harder than working from a prescriptive standard. It is also more defensible in some respects, because you cannot hide behind a checkbox you do not fully understand. Every requirement in a self-constructed framework exists because your team put it there and can explain why.

Lessons From eVTOL and Autonomous Vehicle Certification

The eVTOL industry arrived at its standards gap problem around 2015-2017 and has spent the decade since building the frameworks that maritime autonomous programs can now borrow.

What worked in eVTOL:

The FAA’s Special Conditions and Issue Paper process gave programs a path to certification without waiting for AC 20-XXX documents that did not yet exist. Joby Aviation, Archer, Beta Technologies, and others each constructed certification bases that were bespoke to their specific configurations. The diversity of approaches did not undermine safety — it generated the data that the FAA is now using to write the standards that will govern the next generation of programs.

The critical lesson: start the regulatory conversation before you know all the answers. The qualification basis is negotiated, not discovered. Programs that waited until their design was mature before engaging with regulators lost years.

What worked in autonomous vehicles:

The SAE Levels framework gave the industry a shared vocabulary for describing autonomy, which made regulatory conversation possible even without prescriptive rules. NHTSA’s “voluntary guidance” approach in the 2016-2020 period essentially told programs: describe your safety case systematically, and we will evaluate it on its merits. The Waymo Safety Case Framework and similar public documents from autonomous vehicle programs are direct precedents for how maritime teams should structure their own safety arguments.

The critical lesson: the safety case is the product. Not the system alone — the system plus the documented argument that the system is acceptably safe for its operational design domain (ODD). Defining the ODD tightly is what makes the safety argument tractable. An autonomous vessel operating on fixed inspection routes in a specific sea state envelope, with defined exclusion zones and defined abort criteria, has a bounded ODD. A general-purpose autonomous vessel operating worldwide has an ODD so large that a credible safety case becomes extremely difficult. Constrain the ODD to make the argument winnable.

What failed in both domains:

Programs that treated safety documentation as a post-design activity. When the system is designed first and documented second, the documentation describes what was built rather than what was intended to be built. Regulators can tell the difference. A safety case written after the design is locked cannot credibly influence the design — and regulators reviewing it know that.

Building a Safety Case Without a Prescriptive Standard

The structure of a defensible safety case under standards uncertainty follows a consistent pattern regardless of domain:

System Description and Operational Design Domain — What the system does, where it operates, under what conditions, and what operational limits define its boundary. Every claim in the safety case is implicitly conditioned on the ODD. Regulators evaluate whether the ODD is realistic and whether the system actually stays within it.

Hazard Identification and Risk Assessment — A systematic identification of everything that can go wrong, with likelihood and severity assessments. HAZOP, FMEA, STPA (Systems-Theoretic Process Analysis), and FTA are all appropriate tools. STPA is particularly well-suited to ML-based systems because it reasons about control actions and their unsafe contexts rather than just component failures.

Safety Objectives — Derived from the hazard analysis, stating what the system must achieve to make each identified hazard acceptably unlikely or acceptably mitigated. Safety objectives are not requirements. They are the goals that requirements must satisfy.

Requirements and Design Decisions — The specific, verifiable requirements derived from safety objectives, and the design decisions that implement them. Each requirement traces to at least one safety objective. Each design decision that affects safety traces to at least one requirement.

Verification and Validation Evidence — Test results, simulation results, analysis results, and operational data that demonstrate requirements are met. Evidence must be complete enough that a reviewer can evaluate each claim without taking your word for it.

Residual Risk and Limitations — An honest statement of what risks remain, why they are acceptable, and what operational constraints exist to manage them.

This structure is recognizable across aviation, automotive, rail, and industrial safety. Regulators in maritime contexts accept it because it is the established pattern for novel systems.

How Flow Engineering Supports Non-Standard Compliance Frameworks

The administrative challenge of managing all of this — AMoC documents, issue paper responses, self-constructed compliance matrices, safety objectives, requirements, verification evidence — is substantial. Most teams reaching for this challenge initially reach for a spreadsheet or a document management system. Both fail in the same way: they cannot maintain live traceability across a graph of interdependent elements as the design changes.

When your safety objective changes because your hazard analysis was updated, you need to know immediately which requirements are affected, which verification activities need to be re-run, and which AMoC arguments need to be revised. A spreadsheet does not propagate that information. A document system does not propagate it either. You find out at the next review, when the inconsistencies surface.

Flow Engineering is built around a graph-based model of requirements and their relationships, which means it is well-suited to the exact problem of managing a compliance framework that does not come pre-loaded from a standard’s checklist. Because the traceability structure is defined by the engineering team rather than inherited from a tool’s built-in template, teams can model their own compliance framework directly: safety objectives link to requirements, requirements link to design elements, design elements link to verification evidence, all of it navigable and queryable.

For an autonomous maritime program operating without a prescriptive standard, this means you can construct the AMoC argument structure directly in the tool — linking the originating regulatory requirement to the proposed alternative, to the safety equivalence rationale, to the verification activities that demonstrate compliance. When the regulator asks “show me your traceability from Rule 5 of COLREGS to your sensor fusion specification to your collision avoidance test results,” the answer exists in the model rather than in a manually maintained document.

Flow Engineering is focused on hardware and systems engineering programs — it is not a general-purpose GRC tool, and it does not attempt to be. That focus is appropriate here. Maritime autonomous certification is a systems engineering problem, and the traceability it requires is systems engineering traceability, not compliance checkbox management.

Where to Start

If your program is operating in a standards gap right now:

Engage your classification society or flag state administration immediately. Not when the design is ready — now. The qualification basis is negotiated, and every month you wait is a month during which your design may be moving in a direction the regulator will not accept.

Define your ODD tightly and document it formally. The tighter your ODD, the more tractable your safety case. Resist the temptation to claim broad operational capability before you have the evidence to support it.

Start your hazard analysis before your requirements baseline is locked. Safety objectives must drive requirements, not the other way around. STPA is worth learning for ML-heavy systems.

Treat analogous standards as a menu, not a constraint. DO-178C’s software assurance levels, ISO 26262’s ASIL framework, and IEC 61508’s SIL framework were not written for maritime autonomous systems. They were written for aircraft software, automotive systems, and industrial control systems, respectively. Elements from each are applicable; no single one maps directly. Document why you selected what you selected.

Build your traceability infrastructure before your design is mature. The cost of retrofitting traceability to a completed design is high, the quality of the result is poor, and regulators can tell when documentation was written after the fact. Establishing a linked model of objectives, requirements, design decisions, and evidence from the start of the program is the difference between a defensible safety case and an exercise in post-hoc justification.

The standard for your technology will eventually exist. Programs operating today are generating the data that will produce it. In the meantime, the question is not whether you can certify without the standard — you can. The question is whether you have built the engineering argument rigorously enough that a regulator can evaluate it on its merits. That is entirely within your control.