The System Worked. That’s the Problem.

Picture a production lane-keeping assist system, camera-based, validated across thousands of kilometers of highway testing. On a sun-bleached road in August, where the white lane markings have faded to near-pavement contrast, the system drifts. No sensor has failed. No processing unit has thrown an error. The software executed exactly what it was specified to do. It just wasn’t specified for this scenario.

This is not a malfunction. It is a SOTIF hazard.

ISO 21448, formally titled Road Vehicles — Safety of the Intended Functionality, was published by ISO in 2022 to address exactly this class of problem. It fills a gap that ISO 26262 — the functional safety standard for road vehicles — was never designed to cover. ISO 26262 handles random hardware failures and systematic faults in the development process. SOTIF handles something structurally different: hazardous situations that arise from the intended behavior of a correctly functioning system, when that system encounters the limits of its own design.

The practical importance of this distinction cannot be overstated. A system can be fully ISO 26262 compliant — fault-tolerant, redundant, systematically developed — and still create unreasonable risk. SOTIF provides the engineering framework for identifying, evaluating, and reducing that risk.

What SOTIF Is Actually Solving

The formal SOTIF problem space centers on two sources of unsafe behavior:

Functional insufficiencies — the system’s performance envelope is simply not wide enough. The lane-keeping camera cannot reliably detect markings below a certain contrast threshold. The radar cannot resolve closely spaced objects in certain geometries. These are not defects. They are boundaries of capability that weren’t matched to the boundaries of deployment.

Specification weaknesses — the system behaves as specified, but the specification itself was incomplete or incorrect. The decision algorithm was told to treat any object below 0.3 m/s as stationary, because in the scenarios the engineers anticipated, that heuristic held. In a scenario they didn’t anticipate, it causes a dangerous response.

Both sources lead to the same outcome: the system operates within its design, and the design fails the situation.

ISO 26262’s ASIL framework is built on fault models — component failures, systematic errors introduced during development. SOTIF requires a different analytical foundation. The question is not “what breaks?” but “what scenarios did we not design for, and what happens in them?”

The Four-Zone Model

SOTIF organizes the scenario space into four zones, defined by two axes: whether a scenario is known to the development team, and whether the system’s behavior in that scenario is safe or unsafe.

Zone 1 — Known and unsafe. The team has identified specific scenarios where the system behaves dangerously. These require immediate engineering work: redesign, additional sensors, tighter ODD restrictions, or countermeasures.

Zone 2 — Unknown and unsafe. Scenarios that have not yet been identified but will produce unsafe behavior. This is the most dangerous region because it represents gaps in the engineering team’s own model of the world.

Zone 3 — Known and safe. Scenarios the team has identified where the system performs correctly. The validated envelope.

Zone 4 — Unknown and safe. Scenarios the team hasn’t thought of, but where the system happens to behave correctly anyway.

The SOTIF goal is twofold: reduce Zone 1 to an acceptably small residual, and shrink Zone 2 as aggressively as possible. Zone 2 reduction is the hard problem. You cannot test for scenarios you haven’t imagined. SOTIF’s analytical methods — hazard analysis, scenario generation, operational coverage analysis, and field data evaluation — are all aimed at converting Zone 2 scenarios into Zone 1, where they can be addressed.

The Operational Design Domain Is Not a Formality

Every SOTIF argument stands on the Operational Design Domain (ODD) — the bounded set of environmental, geographic, and operational conditions within which the system is designed to function. Weather. Illumination. Road geometry. Speed range. Traffic density. Infrastructure quality.

Engineers sometimes treat ODD documentation as a regulatory checkbox. In SOTIF work, it is the load-bearing structure. If the ODD does not explicitly bound the low-contrast road marking scenario, then the system cannot be claimed safe only within that ODD. If it does bound it, then the safety argument has a clear scope — but the engineering work shifts to ensuring users and the system itself reliably stay within that scope.

This creates a cascade of requirements. The ODD limitation generates a requirement on the system’s operational monitoring — it must detect when it’s approaching ODD boundaries and respond appropriately. That requirement generates test scenarios. Those scenarios generate verification evidence. Each link must be traceable and auditable.

ODD definition, in practice, is an iterative process. Early in development, the ODD is broad and approximate. Hazard analysis narrows it. Sensor performance data narrows it further. Field incidents from similar systems refine it again. By the time a system reaches production, the ODD should reflect real engineering knowledge, not an aspirational scope.

The SOTIF Workflow in Practice

ISO 21448 defines a process with three primary activities:

1. Identify known unsafe scenarios (Zone 1 reduction)

This combines Hazard Analysis and Risk Assessment (HARA) methodology adapted from ISO 26262 with scenario-based analysis. The team systematically identifies triggering conditions — environmental factors, traffic situations, sensor degradation modes, edge cases in decision logic — that could cause the system to behave unsafely.

Functional Failure Mode and Effects Analysis (FMEA) is often applied here, but the failure modes being analyzed are performance limitations rather than component faults. What happens when camera contrast detection confidence drops below threshold? What happens when radar and camera produce conflicting object classifications? Each identified failure mode generates either a design requirement or an ODD restriction.

2. Evaluate unknown unsafe scenarios (Zone 2 reduction)

This is methodologically harder. Common approaches include:

  • Systematic scenario generation using combinatorial techniques — varying environmental parameters, traffic configurations, and sensor conditions across a defined space.
  • Simulation-based coverage analysis — running the system against generated scenarios in simulation to identify behavioral anomalies before they appear in the field.
  • Statistical field data analysis — leveraging fleet data from similar systems to surface scenarios the development team didn’t generate themselves.
  • Expert elicitation and HAZOP-style workshops — structured sessions aimed at surfacing assumptions and gaps in the team’s scenario model.

The standard does not prescribe a single method. It requires that the team demonstrate they have applied a sufficiently rigorous and complete approach, and that residual uncertainty is within acceptable bounds.

3. Define and demonstrate acceptance criteria

SOTIF requires an explicit argument that the residual risk — from both Zone 1 and Zone 2 — is acceptably low. This is not a statistical threshold the standard sets for you. It is an engineering judgment the development organization must make, document, and defend to authorities and customers.

Acceptance criteria typically reference exposure probability, severity of potential harm, and the degree of verification coverage achieved. The argument must be consistent — the same logic that justifies Zone 1 residuals must also apply to Zone 2 unknowns, with appropriate acknowledgment of epistemic uncertainty.

How Requirements Tooling Fits Into SOTIF Work

SOTIF generates a dense web of artifacts: ODD specifications, triggering conditions, hazard analyses, functional requirements, verification scenarios, and acceptance arguments. The connections between these artifacts matter as much as the artifacts themselves. A requirement derived from a SOTIF hazard analysis that can’t be traced forward to a verification scenario is a safety argument with a gap. A verification scenario that doesn’t trace back to a triggering condition is test effort that may not be covering what it needs to cover.

Traditional document-based requirements management — where requirements live in Word or PDF, linked by manual reference tables — struggles with this traceability problem. Connections get stale. Updates to ODD constraints don’t propagate automatically to derived requirements. Test plans diverge from safety cases over multiple development iterations.

This is where graph-based, AI-native requirements tools offer a material advantage over legacy approaches.

Flow Engineering (flowengineering.com) implements requirements as interconnected nodes in a live graph rather than rows in a document. For SOTIF work, this means an ODD limitation — say, “system not validated for road marking contrast below 30% delta luminance” — can be a parent node with explicit, typed relationships to the triggering condition it defines, the hazard that condition creates, the functional requirements that mitigate that hazard, and the verification scenarios that demonstrate coverage.

When that ODD constraint is revised — tightened based on new sensor characterization data, for example — Flow Engineering can surface every downstream artifact that depends on it. Engineers see immediately which requirements need review, which test scenarios need updating, and whether the acceptance argument is still coherent. This propagation of change through a connected structure is not something a requirements document does.

Flow Engineering also applies AI assistance to gap identification: analyzing whether the scenarios generated for verification actually cover the triggering conditions the hazard analysis identified. In SOTIF work, where Zone 2 reduction depends on the completeness of scenario coverage, this kind of automated consistency checking replaces a class of manual review that is slow, expensive, and error-prone.

The platform is focused on hardware and systems engineering contexts — it is not a general-purpose project management tool wearing a safety hat. That focus means the data model and AI capabilities are shaped around the artifacts SOTIF work actually produces, rather than adapted from a generic schema.

One deliberate trade-off: Flow Engineering is optimized for the requirements-to-verification traceability layer. Teams needing deep formal verification integration or complex simulation pipeline orchestration will connect it to specialized tools rather than replace them. That is an architectural choice, not a gap.

Practical Starting Points

If your team is beginning SOTIF work, three things tend to unlock progress faster than anything else:

Get the ODD on paper before the hazard analysis. SOTIF hazard analysis without a documented ODD produces requirements that can’t be scoped. You will argue indefinitely about what scenarios are “in scope” because no one has formally bounded them.

Separate triggering conditions from hazards. A triggering condition is what causes the system to misbehave. A hazard is the resulting dangerous situation. Teams that conflate these generate requirements at the wrong level — and verification scenarios that test the trigger detection rather than the hazardous outcome.

Build traceability from day one, not as a retrofit. The temptation to capture requirements in documents first and link them later reliably produces trace matrices that don’t reflect the actual derivation logic. The connection between an ODD constraint and a verification scenario needs to be established when the requirement is created, not reconstructed from memory during a safety review.

Honest Assessment

SOTIF is a significant piece of regulatory and engineering infrastructure, and ISO 21448 is a serious standard. It is also genuinely hard to implement well. The Zone 2 reduction problem — how do you demonstrate sufficient coverage of scenarios you haven’t thought of? — has no clean answer. The acceptance criteria question — how safe is safe enough for an unknown residual? — requires engineering judgment that the standard cannot fully prescribe.

What SOTIF does is give teams a structured way to think about and document their answers to these hard questions. It makes the arguments auditable. It forces the ODD to be a real engineering boundary rather than a marketing scope. It requires that Zone 2 uncertainty be confronted rather than assumed away.

For autonomous and semi-autonomous driving systems, engaging with SOTIF seriously is not optional. The hazards it addresses are real, the regulatory trajectory is clear, and the alternative — functional safety compliance without addressing functional limitations — produces systems that pass audits and fail in the field.