Scenario Mining
How rare situations are retrieved from fleet logs long after they were recorded, why the recall of a scenario query is almost never measured, and where two defensible readings of one scenario type quietly split a corpus.
Operational Design Domain
What a declared operating domain actually enumerates before an autonomy claim carries information, why the boundary is far harder to detect at runtime than to write down, and where a fleet's recorded coverage stops matching the domain it claims.
Summary
An operational design domain, usually shortened to ODD, is the written statement of the conditions a machine was built to operate in: which roads, which speeds, which weather, which lighting, and which traffic. It exists because a claim about automation says nothing on its own about when that automation applies, so the level of automation and the domain it holds within have to be read together. For Physical AI it is the document that turns a safety argument into something checkable, because every claim about how well a system performs is a claim about how well it performs inside a stated domain. It is also the specification that a recorded dataset either covers or does not cover.
Operational Design Domain: Definition and Scope
SAE J3016, the taxonomy [[Autonomous Systems]] are graded by, defines the ODD as the operating conditions under which a driving automation feature is designed to function. NHTSA’s testable cases framework describes those conditions concretely as roadway types, speed range, lighting conditions, weather conditions and other operational constraints. The pairing matters more than either half: J3016 combines the level of driving automation with the ODD into what it calls a usage specification%20SAE_J3016_Taxonomy%20and%20Definitions%20for%20Terms%20Related%20to%20Driving%20Automation%20Systems.pdf?api=v2), and notes that levels 1 through 4 all contemplate ODD limitations while level 5 disavows them. A Level 4 claim with no domain attached is therefore not a weaker claim, it is an incomplete one.
The taxonomy for writing one down is ISO 34503:2023, which specifies a hierarchical set of operating conditions and a required definition format, and which applies mainly to level 3 and level 4 systems. It grew out of BSI PAS 1883, published in 2020 with Siddartha Khastgir as lead author, and the ISO revision added measurability of environmental elements and a format for ODD definition. Two distinctions are worth holding. The operational domain is the whole space a vehicle could meet; the ODD is the subset the system is designed for, and the taxonomy standards actually classify the former. And an ODD is neither a scenario library nor a safety case. It is the input both are built from.
How an Operational Design Domain Works in Practice
A real declaration reads as an attribute list, not a mission statement. California’s DMV publishes Waymo’s approved driverless operating parameters as exactly this kind of list: a named vehicle platform, “all times of day and night,” “all rain, fog, and other conditions,” and “all speeds,” each scoped to a mapped territory, as of September 2026. That is a categorical declaration rather than a numeric one, granting broad authority within the mapped area instead of stating a visibility floor or a rainfall ceiling, and it is published because California’s deployment permit process requires it, not because Waymo’s own safety literature works at this level of detail.
Consider a worked example next, since a program outside a permit regime like California’s has no regulator publishing its domain on its behalf: a hypothetical freight program running a fixed highway lane. Its ODD is written as a list of attribute ranges: divided highway of a named class, a posted speed band, day and night, dry or wet road surface, no active snow, visibility above a stated distance, and no unmapped construction zone. That list goes into three places at once. It becomes the runtime monitor, which compares measured conditions against the declared ranges. It becomes the test matrix, since each attribute range is a dimension the scenario set has to span. And it becomes the collection target for the data program.
At runtime the monitor watches for a boundary crossing. When one occurs, the system starts a fallback toward a minimal risk condition, which the April 2021 revision of J3016 tightened to a stable, stopped condition a vehicle is brought to after performing the fallback rather than any generically low risk state. The output that should survive all of this is a per-episode record saying which ODD attributes held while that episode was recorded.
Here is the failure. The ODD attribute is written over the road surface, and the annotation guideline is written over the sky. Suppose rain stops and the pavement stays wet for twenty minutes, an illustrative duration rather than a measured one: every frame in that window would be tagged clear while the surface condition the ODD actually names is still present. The corpora themselves disagree on this point: BDD100K’s frame attributes are weather, scene and time of day describing the scene rather than the pavement, while Zenseact Open Dataset annotates road-surface condition as its own task, with values such as wet or snow. A research re-annotation of BDD100K added road and visibility labels precisely because the original tags do not identify road state. The downstream consequence is that a safety case built this way reports hours of wet-surface exposure computed from an atmospheric tag. The number is smaller than the truth, nobody can see that it is, and the residual wet road the fallback logic actually keys on was never counted.
Use Cases
Deployment permission and regulatory filings. Production. The domain is what a filing describes, and NHTSA’s AV framework update of 31 July 2026 sits on exemption and reporting processes that assume it is stated.
Runtime boundary monitoring and fallback triggering. Production inside geofenced services, research stage at the perceptual edge, where zero-shot vision-language perception of ODD attributes is still being evaluated.
Test allocation and coverage argument. Production in AV safety engineering, where ODD-driven coverage is the standard way to argue a scenario set spans the parameter space.
Collection planning and dataset curation. Uneven. The ODD names what the fleet should have encountered, but few corpora record attribute state per episode.
Domains beyond the road. Research stage. The concept has been carried into teleoperation and into agricultural machinery, and both of those domains have had to rebuild the attribute list from scratch.
Companies
Waymo: the one operator-specific ODD document located for this node with attribute-level detail rather than a marketing description. The California DMV publishes Waymo’s approved driverless operating parameters directly, as an attribute list tied to a mapped territory: vehicle platform (Jaguar I-Pace and Zeekr Ojai), all times of day and night, all rain, fog and other conditions, and all speeds within the approved area, current as of September 2026. That the document exists at all is a function of the permit process, not of Waymo publishing a safety case at this level of detail on its own; Waymo’s own safety framework and safety case papers stay at the principle level and do not enumerate the domain this way.
Aurora: production driverless freight on a deliberately bounded set of Sun Belt routes, which is an ODD narrow enough to be enumerated route by route. Aurora’s own Safety Case Framework states the claims a domain declaration has to support without publishing the attribute ranges themselves.
Zenseact: research and production data organization that published a corpus annotating road condition, time of day and road type as first-class labels.
WMG, University of Warwick: research group behind PAS 1883 and the ISO 34503 taxonomy work.
ASAM: standards consortium publishing OpenODD, the machine-readable format layer above the ISO taxonomy.
Datasets
Zenseact Open Dataset: 100k annotated frames plus 1,473 sequences and 29 drives from several European countries, with road condition as a separate annotation task and a permissive license. Of the public driving corpora surveyed here, it is the one whose labels come closest to naming ODD attributes directly.
BDD100K: 100K driving videos from more than 50K rides, with weather, scene and time of day tagged per annotated frame. The reference case for condition tags that describe the scene rather than the surface.
ONCE: a million lidar scenes across varied areas, lighting and weather in China, largely unlabeled and without GNSS or map data, which makes geographic ODD attributes unrecoverable after the fact.
Papers
Teleoperation Operational Design Domain based on Minimal Risk Maneuver Capability, Brettin, Salem, Hans and Maurer, arXiv:2605.29818, 2026.
Operating Within the Operational Design Domain: Zero-Shot Perception with Vision-Language Models, arXiv:2605.07649, 2026.
Formalizing Operational Design Domains with the Pkl Language, arXiv:2509.02221, 2025.
Formalization of Operational Domain and Operational Design Domain for Automated Vehicles, arXiv:2408.14481, 2024.
Operational Design Domain-Driven Coverage for the Safety Argumentation of Automated Vehicles, Weissensteiner, Stettinger, Khastgir and Watzenig, IEEE Access 11, 2023.
A Framework for Automated Driving System Testable Cases and Scenarios, Thorn, Kimmel and Chaka, NHTSA DOT HS 812 623, 2018.
Software
ASAM OpenODD provides a language and format for expressing an ODD so a monitor or a test generator can consume it rather than a person reading prose. ISO 34503 supplies the taxonomy underneath it. Independent efforts such as ODD in Pkl exist because teams keep finding that a natural language domain statement cannot be diffed, versioned, or evaluated against a recorded episode.
State of Practice
The field has converged on the requirement. ISO 34503 specifies a taxonomy and definition format for Level 3 and Level 4 automated-driving ODDs, and ASAM OpenODD provides a machine-readable model for representing them: PAS 1883 and ISO 34503 for the taxonomy, ASAM OpenODD for the machine-readable format. Coverage methodology exists too, and ODD-driven coverage for safety argumentation is a well developed line of work with acceptance criteria based on parameter space coverage and the variance introduced by discretizing it.
Where it has not converged is the join between the declared domain and the recorded data. Published coverage work operates on scenario parameter spaces destined for simulation, not on the episodes a fleet actually collected, and the two are counted differently. A 2025 formalization paper argues from the same direction that prose ODD statements are ambiguous enough that teams building tooling reach for a configuration language instead, and a 2024 formalization notes that the taxonomy standards classify the operational domain rather than the design domain, which leaves the mapping from taxonomy to a specific system’s declared subset as work each program does privately.
The practical result is a gap that shows up in procurement rather than in the literature. A program can hold a compliant ODD document, a compliant scenario coverage argument, and a corpus of several hundred thousand annotated frames, and still have no way to answer how many of those frames sit inside each declared attribute range. The taxonomy standards are also paywalled, with ISO 34503 listed at CHF 159 as of August 2026, so smaller teams often write domains from secondary readings of a standard they have not opened.
Pain Points
Attribute measurability. The failure above is the concrete mechanism: an ODD attribute stated over road surface, an annotation guideline written over atmospheric appearance, and a coverage number that silently counts the wrong thing.
Boundary onset. Suppose fog thickens over ninety seconds. Whether the ODD exit is labeled at the first frame the condition is measurably violated or at the frame the monitor declared it changes what a runtime monitor learns to fire on. It is a guideline decision before it is a modeling one.
Coverage accounting. Without per-episode attribute state, coverage is estimated from route and calendar metadata, which cannot distinguish a route driven a thousand times in clear weather from the same route across the declared range.
Privacy and compliance. Geographic attributes make ODD-tagged records location data under regional rules, and anonymization has to preserve the condition evidence it passes over. ZOD ships anonymized imagery precisely for this reason.
Standards access and drift. Paywalled taxonomies and domains that change between software releases without the corpus being re-tagged.
Kotwel’s Role
Kotwel is the data-quality and data-operations partner for Physical AI. We turn multimodal physical-world and synthetic data into synchronized, structured, validated, and traceable datasets for training, evaluation, and continuous improvement. We make consequential data choices explicit and develop measurable quality criteria that enable organizations to benchmark and improve the data behind physical AI systems.
Scope and responsibility
Kotwel works at the data layer and remains independent of hardware, sensing architecture, and model family. We define data-quality criteria, audit datasets, and assess conformance against documented requirements. Clients retain control over program-specific conventions, intended model behavior, and operating requirements, provided those choices are explicitly documented and consistently applied. We do not build robots or autonomy stacks, develop control systems, or train foundation models. Decisions about system safety, legal compliance, and deployment remain with the client and its qualified advisers.
The specification stops giving one answer at the same illustrative frame introduced above, a hypothetical frame recorded twenty minutes after rain has stopped: dry sky, standing water in the wheel tracks, and an ODD whose attribute is written over the road surface. The attribute the ODD names is the road surface, so a coverage count has to be labeled over the surface. Labeling from the atmosphere is how nuScenes records weather at scene level, while ZOD labels road surface condition directly, and atmosphere labeling measures something else: here it would tag the frame clear while the wet surface the ODD names is still present. Labeling from the inferred surface state matches how the ODD is written and how the fallback logic keys on it, at the cost of an inference annotators will disagree on more often, so the specification has to say how that case is judged. A program that labels one thing and writes its coverage argument against the other has a number nobody can defend, and the discrepancy stays hidden in any offline check that reuses the atmosphere label as its reference, though a check that compares the surface labels or inspects the recorded imagery can expose it. Kotwel builds annotation specifications for multimodal fleet data and surfaces this class of question when the attribute list is written rather than after a coverage query returns, for the program to settle, including the sequence-level conventions that decide where a boundary crossing starts. Kotwel does not author operational design domains, operate fleets, or certify safety cases.
At a glance
Key takeaways
An ODD is the stated set of operating conditions a system was designed for, and J3016 reads it together with the automation level as a single usage specification, so a level claim without a domain is incomplete rather than merely vague.
ISO 34503:2023 supplies the hierarchical taxonomy and definition format, mainly for level 3 and level 4 systems, with ASAM OpenODD adding the machine-readable layer above it.
At the domain boundary the system performs a fallback to a minimal risk condition, which the April 2021 J3016 revision tightened to a stable, stopped condition.
The field has converged on declaring domains and on scenario coverage methodology, and has not converged on joining a declared domain to the episodes a fleet recorded.
The recurring data failure is a vocabulary mismatch: ODD attributes written over physical state, annotation guidelines written over appearance, and a coverage number computed on the wrong one with no offline check that can see it.
FAQ
Is an ODD just a geofence?
No, geography is one attribute among many. A domain also states roadway class, speed range, lighting, weather, surface state, traffic conditions, and the state of the machine itself. The rest of this point is not established.
Who decides the ODD, and can a vendor quietly widen it?
The developer declares it, which is exactly why the written version and its version history matter. Nothing in the taxonomy standards prevents a domain from being widened in a software release, so the practical control is asking which ODD version a given safety claim was computed under and whether the corpus behind that claim was re-tagged when the domain changed.
How would I check whether our dataset actually covers our declared ODD?
Cross-tabulate recorded episodes against each declared attribute range and look for the cells with near-zero counts. The rest of this point is not established.
Does any of this apply to robots that are not vehicles?
Yes in substance, though the vocabulary has not been standardized outside road transport. A manipulation policy has implicit operating conditions, meaning lighting, object set, surface, and clutter, and the same problem appears: the conditions the policy was validated under are rarely recorded per episode. The road industry is simply further along in writing them down, which is why its taxonomy is being borrowed by teleoperation and agricultural work.
