ODD is short for operational design domain. SAE J3016 defines it as the operating conditions under which a driving automation system or feature is specifically designed to function, including environmental, geographical and time-of-day restrictions, and the required presence or absence of certain traffic or roadway characteristics. An ODD specification is the document that pins this down: a finite set of declarative statements, each giving the acceptable range of values for one operating-condition attribute, based on what the system can actually handle. Build it on the ISO 34503 taxonomy instead of inventing your own fields, test it at its boundaries, and keep re-baselining it against real use. Done that way, it is an artefact an assessor can audit and a test team can derive scenarios from, and it stays defensible after deployment.

Operational design domain definition: the ODD sits inside the operational domain

The operational domain (OD) is the attributes of the physical surroundings a vehicle navigates: natural terrain and built infrastructure, environmental phenomena and traffic conditions. The ODD is the subset of that domain within which a specific system is designed and engineered to operate safely. ISO 34503 adds a third term, the target operational domain (TOD), for the real-world conditions an automated driving system may actually experience in deployment. The gap between them is the point of the exercise. If the operational domain includes snowfall and the system cannot drive in snow, that difference highlights a limitation of the system.

A draft of ISO 34503 states that no ODD definition will be exhaustive enough to cover every attribute or occurrence in a target domain. That is why the standard asks for the ODD boundary to be defined objectively and for design mechanisms that execute a fallback manoeuvre when the vehicle exits its ODD. The ASAM OpenODD concept paper names a terminology misuse in practice: treating the ODD as a description of the real world, when it describes the intended capability, not the world itself.

One naming quirk is worth knowing before you start. The taxonomies in ISO 34503 and BSI PAS 1883 are, strictly speaking, taxonomies of operational domain attributes, even though both call them ODD taxonomies. The practical consequence is simple. The taxonomy gives you the vocabulary, and your specification is the set of statements you make with it. An ODD is also not a scenario. The ODD describes the operating conditions, while a scenario describes how traffic participants behave within (or outside) one instance of those conditions.

How does a vehicle’s ODD relate to its SAE level, and why does Level 4 need a narrower one?

Levels 1 to 4 all have ODD limits, and Level 5 does not. Under SAE J3016, describing any feature other than Level 0 or 5 accurately requires both its level and its ODD, and that pair is called a usage specification. Level 5 means the system can operate anywhere a typically skilled human driver could reasonably drive a conventional vehicle, with no design-based restrictions on weather, time of day or geography.

The level changes what the ODD has to do. Level 3 and 4 ADS features, by contrast, are designed to monitor and enforce their own ODD limits and to refuse engagement outside them. At Level 4 the system must also perform the fallback itself, reaching a minimal risk condition such as pulling onto the shoulder and summoning assistance, without relying on anyone to respond to a request to intervene. NHTSA’s 2024 AV STEP proposal puts the consequence plainly: in operations without fallback personnel, the ADS must be able to handle all scenarios within its ODD without intervention.

Narrowness is the engineering response to that obligation. J3016 itself notes that enclosed-course people movers have operated at Level 4 for decades because their ODD is simple, controlled and physically protected, while a Level 3 feature on open roads in mixed traffic and bad weather faces a much higher technological bar. If the system has to handle everything inside the boundary unaided, drawing the boundary tighter is often the only way to make that promise testable. Levels are also assigned by design intent rather than measured.

Declaring an ISO 34503 ODD instead of inventing fields

The defensible route for road vehicles is to declare the ODD against a recognised taxonomy (ISO 34503, with PAS 1883 as its implementation guide), extend it only where your system needs attributes it lacks, and back any completeness claim with scenario and coverage evidence. Conformance to the taxonomy alone does not establish completeness.

Which attributes must an ISO 34503-aligned ODD specification declare?

At the top level, a draft of ISO 34503 classifies the ODD into three attributes. Scenery elements are the spatially fixed parts of the environment, such as roads and traffic lights. Environmental conditions cover weather and atmospheric conditions, including connectivity. Dynamic elements are the movable parts, such as traffic and the subject vehicle. Roads therefore sit under scenery, weather under environmental conditions, and traffic under dynamic elements. NHTSA’s 2018 framework (DOT HS 812 623) cuts the same space into six top-level categories: physical infrastructure, operational constraints, objects, connectivity, environmental conditions and zones.

Granularity follows capability. You may declare an attribute at a high level of abstraction, but if you do, ISO 34503 treats every predefined sub-attribute as inside your ODD. A system that handles only light rain below 2.5 mm/hr therefore has to declare rainfall at that finer level. Interdependencies must be stated in a prescribed format. The standard’s own illustration is a maximum allowable speed of 70 km/h without rainfall and 40 km/h with it. Boundaries may also carry qualifiers, including temporal ones, such as tolerating up to two minutes of heavy rain. Where you extend the taxonomy, the standard asks you to place new attributes at the correct point in the hierarchy, justify them, avoid conflicts with existing attributes and give an objective measurement for each.

The statements themselves come in four types under ISO 34503: include, exclude, conditional and mode. Each segment of the ODD can be assigned a default, permissive or restrictive mode. Under a permissive reading, an attribute the specification says nothing about is allowed at every value. Under a restrictive reading, it is allowed at none. The OpenODD concept paper recommends a restrictive global mode, because conditions the ontology does not model are then clearly outside the ODD, which is consistent with J3016’s “specifically designed to function” wording.

For toolchains, the machine-readable counterpart is ASAM OpenODD. Its SUITABLE and UNSUITABLE keywords set the permissive or restrictive nature of each statement, DETERMINE builds classes such as “heavy rain” from measured values, and MEASURE attaches units, data types and ranges. An instantiated ODD with a speed limit outside the template’s valid range fails validation with an error. The authors describe that work as a proof of concept that may contain errors, so treat it as a pattern to copy, not a finished tool.

Can we reuse ISO 34503, SAE J3259 or BSI PAS 1883 instead of inventing our own fields?

Yes, and reuse is the expected route. ASAM lists the current standardisation activity as BSI PAS 1883 (the ODD taxonomy), SAE J3259 and the AVSC ODD lexicon, ISO 34503 (taxonomy and definition format) and the ASAM OpenX family. PAS 1883:2025 now implements BS ISO 34503, with practical examples and additional attributes for motor vehicle type and vulnerable road users. The AVSC best practice adds labels, definitions and measurement ranges so that manufacturers describe ODDs in consistent terms. Regulators point the same way. The interpretation of EU Regulation 2022/1426 recommends using existing taxonomies such as PAS 1883, the AVSC lexicon, ISO 34503 or ASAM OpenODD.

Reuse does not mean full coverage. None of PAS 1883, the AVSC lexicon or ISO 34503 fully covers a six-layer model, with temporary limitations such as road debris and dynamic objects such as animals not always covered. Adopt the taxonomy, then audit it against your own hazard list and extend it under the standard’s rules.

Worked example: an operational design domain example for a highway-assist L2+ feature

The table below is an illustrative highway-assist ODD assembled from fragments of different published examples. A real programme substitutes its own measured limits, so read the structure as the template and the numbers as placeholders with provenance.

Top-level attribute	Attribute	Statement	Where the value comes from
Scenery	Road type	INCLUDE fully access-controlled freeways only	J3016’s Level 2 example operates on fully access-controlled freeways
Scenery	Lane markings	INCLUDE clearly visible lane lines; brief obscuration tolerated, sustained obscuration is an exit	J3016’s lane-line example for a Level 3 highway feature
Scenery	Lane width	INCLUDE lane width above 2.6 m where trucks are present	Pkl template constraint for drivable area
Environmental	Rainfall	INCLUDE light rain below 2.5 mm/hr; EXCLUDE higher intensities	ISO 34503 granularity example
Environmental	Illumination	CONDITIONAL: camera-only configuration excluded at 130 km/h at night	DLR example ODD statement derived from sensing limits
Dynamic	Pedestrians	EXCLUDE pedestrians	Formal motorway ODD example
Dynamic	Speed	CONDITIONAL: lower maximum speed when raining	ISO 34503 interdependency example

Two details separate this from a Level 3 declaration. A Level 2 feature is not designed to enforce its own ODD the way Level 3 and 4 features are. ISO 34503 also asks for the ODD to be understandable to the user so they can respect its limits. So for L2+, the specification serves the driver and the reviewer as much as the software.

Taxonomy conformance does not prove the scenario set is complete

Declaring an ODD does not show that the evidence covers it. Coverage research on scenario databases separates two questions: whether the collected scenarios cover all relevant aspects of the ODD, and whether they cover everything that appears in the driving data. Work aligned with EASA’s AI learning-assurance objectives adds a second split. Completeness asks whether the data span the ODD combinatorially, and representativeness asks whether the data follow the distribution the ODD prescribes. Complete coverage does not imply representative data. The same authors conclude that no single metric is sufficient on its own.

To show an assessor you have not missed a known failure mode, map the scenario set back to the ODD and to an external library, not to your own judgement alone. NHTSA’s 2021 report DOT HS 813 073 describes 36 pre-crash scenarios that account for 94 percent of fatal crashes and 89 percent of police-reported crashes involving light vehicles in the 2011-2015 FARS and GES data. Those scenarios come from human-driving crash data, and the report notes it is unknown whether they occur at a similar frequency with automated vehicles. For quantified coverage, the OpenODD concept paper suggests equivalence-partitioning every continuous ODD dimension into bins, with a minimum such as at least 10 occurrences per bin, and reporting the share of bins that meet it. Testing also has to reach past the edge: ISO 34503 expects tests within the ODD, across its boundary and outside it. DOT HS 813 073 likewise sets parameter ranges both inside and outside the ODD to exercise minimum risk fallback.

How many field-trial scenarios are enough is a risk judgement, not a number you can read off the taxonomy. Pairing the scenario plan with risk tiering, as in tiering models by risk to scale governance appropriately, is how that judgement gets documented instead of asserted.

Harmonised templates, and ODDs outside road vehicles

A regulator who wants every manufacturer to fill in the same ISO 34503 template is making a governance decision: which fields are mandatory, at what granularity, before evidence is reviewed. That decision is separate from any single company’s ODD document. OpenODD shows one way to keep exchange workable. Manufacturers share ODDs at an agreed level of detail in included files while keeping their own confidence values outside the shared specification. J3016 also says a feature has exactly one ODD, however multi-faceted. A single document covering several platform types therefore needs per-platform limit tables, not one flat list.

Outside road vehicles, the pattern carries over as an analogy, not an equivalence. In aviation, recent work on AI-based collision avoidance defines the AI/ML constituent ODD by the neural network’s input state variables (range, bearing, closure time) instead of road scenery. Traffic-grid controllers, drone fleets crossing aviation and maritime rules, and even trading algorithms (venue, session, volatility regime) can be given an ODD-shaped declaration. Each of them needs its attribute set and thresholds re-derived for its own domain.

How should an ODD template line up with UNECE WP.29 and US precedents?

Build on ISO 34503 as the technical backbone, with SOTIF-style argument per ISO 21448, then add jurisdiction-specific addenda for UNECE type approval and for US programmes.

TechnoLynx’s AI Governance and Trust work builds the approval evidence pack behind an ODD declaration so it survives a regulator’s or auditor’s review.

On the UNECE side, the WP.29 NATM guidelines recommend validating ADS through a scenarios catalogue plus five validation pillars. They are anticipated to inform future regulatory requirements, subject to WP.29 approval, rather than being requirements themselves. The new ADS regulation requires a structured safety case of claims, arguments and evidence, a lifecycle safety management system subject to audit, and demonstrated credibility of simulation, track and real-world validation. Even within the existing instruments there are differences. Nolte et al. (2025) note that EU Regulation 2022/1426 ties its risk-acceptance criteria to the system’s ODD, while UN Regulation 157 lacks that reference.

In the US, NHTSA’s 2024 AV STEP proposal defines ODD in terms largely derived from SAE’s and would assess applications through a safety case reviewed by an independent entity. In the Texas DMV rulemaking, the City of Austin asked for clarity on whether ODD parameters must be reported to local jurisdictions. These instruments ask for overlapping content in different shapes. A taxonomy-based core with addenda avoids maintaining a separate document per regulator. WP.29 provisions are still evolving, and alignment with ISO 34503 improves review readiness without guaranteeing approval anywhere.

Can a type-approval authority mandate a harmonised ODD template?

WP.29’s NATM guidelines describe themselves as input to future requirements, subject to approval, not as binding rules. This is not legal advice, and an authority’s counsel decides its mandate.

Germany’s AFGBV runs a two-stage approval: first a verified ODD specification for the vehicle (an “abstract operational domain”), then approval of a specific operating area with local authorities. At the second stage, compatibility between the declared ODD and the target domain of the area is checked, for example whether road markings exist throughout or whether mobile coverage is sufficient. At EU level, the taxonomies come in through the interpretation of Regulation 2022/1426, which recommends existing ones. US precedent from California or NHTSA is persuasive context for a European authority, not binding authority.

Re-baselining the declared ODD against how the system is actually used

A declared ODD goes stale as soon as usage drifts beyond the scope it was approved for. Keeping it current means re-baselining it from operating telemetry, identifying every divergence explicitly, and treating each one as an open risk until it is closed. Copying the original scope forward does not do that.

TechnoLynx’s AI Governance and Trust engagement builds the approval evidence pack for the re-baselined ODD so it survives an auditor or regulator.

The standards anticipate this. ISO 34503 describes ODD definition as iterative, with attributes and value coverage that can grow or shrink during development. The AVSC best practice notes that changes such as long-term work zones on a route may warrant an updated ODD description. OpenODD’s stated aim includes quantifying the tightening or expansion of an ODD over time. Coverage researchers name the open problem directly: an ADS must handle the conditions it actually meets in deployment, its target operational domain, and measuring how well the ODD covers that domain is still future work.

The same logic applies to a trading algorithm approved for one set of venues and sessions and then used on thinner, more volatile ones. It is an analogy, and its attributes need re-deriving. Two cautions apply in every domain. Logs must be complete and correctly attributed. Re-baselining records current behaviour but does not by itself make the expanded scope safe, so a separate risk assessment is still needed. Drift monitoring and re-approval with traceability to the original safety case are adjacent problems that sit on top of a re-baselined ODD.

Scoping a pilot ODD that an OEM, reviewer or insurer will accept

A defensible pilot ODD is the smallest set of conditions that matches the real operating envelope. Each condition is mapped to a test case, and any planned expansion is written down from the start.

TechnoLynx scopes a pilot ODD that holds up to the OEM, reviewer or insurer, framing its boundaries around the target validation pipeline and delivering on-target results, gap conditions included, in a phased evidence package. This is part of TechnoLynx’s AI engineering for manufacturing and automotive, starting with framing the boundaries against the contract or regulation in question.

Before an OEM contract: phasing without looking under-scoped

Euro NCAP’s driver engagement protocol defines ODD in the same terms as J3016. Phasing a pilot, narrow first and wider later, is consistent with ISO 34503’s view of the ODD as iterative. The claim stays defensible when the initial ODD is stated as complete for its declared scope, with the later phases listed as future declarations, not implied coverage.

For a reviewer: leave no condition without a test case

Give each ODD attribute an objective measurement, as ISO 34503 requires. Then map each condition to tests inside, across and beyond the boundary. Mapping closes documentation gaps only. A condition that was mapped but never physically or virtually tested is still a coverage gap.

For an insurer: compare the tested ODD with the exposure

For an insurer, the useful model is the ODD-to-target-domain compatibility check that Germany’s approval process performs for an operating area. Compare the tested ODD’s climate, road types and fleet mix with the book’s actual geography. OpenODD-style metrics can express a comparable result, for example the share of road kilometres in a region that one ODD covers compared with another. Where a region such as a fog-prone one is not covered, supplemental validation is the honest fix. It may not exist or be feasible at short notice, and then the mismatch stays open.

Who can help us build an ODD specification and validation evidence that hold up to review?

TechnoLynx builds the engineering behind a defensible ODD. TechnoLynx frames the boundaries against your taxonomy and the regulation you face, maps and runs scenario and on-target validation across those conditions, and assembles a phased evidence package. On build versus bring in: a team with a functional safety and SOTIF function and its own validation rig can own the specification in-house. A specialist helps most where the evidence pipeline (simulation, hardware-in-the-loop, on-device runs) has to be built or made credible quickly. When choosing a partner, ask to see how a condition in their ODD documents maps to a specific test result. The assurance side sits in TechnoLynx’s AI Governance and Trust offer.

The limits are real. Teams that need a certification authority’s opinion, or only a standards-conformance gap review with no validation work, are better served by a technical service or a standards consultancy. Teams with mature in-house safety engineering may only need the scenario tooling.

The boundary is only as good as the next audit of it

The hard part of an ODD specification is not filling in ISO 34503’s fields. It is keeping three things in agreement over time: the statements you declared, the scenarios you tested, and the conditions the system actually meets. Restrictive mode, objective measurements and boundary tests make the first two agree at submission. Research still treats measuring the ODD-to-deployment gap as future work.