With an ODD, autonomous driving teams start from one question: where and when is the system allowed to drive itself? The operational design domain, or ODD, is the answer. It describes the roads, conditions and situations a driving system is designed to handle safely. Outside the ODD, the system should not be driving on its own.
The ODD sounds like a legal or safety concept, and it is, but it is also one of the most practical tools for planning data. If you know the domain, you know what your data must cover.
The concept is defined in SAE J3016, the standard for driving automation levels. It refers to the operating conditions under which a system is designed to function. These can include roads, speeds, weather, lighting and the presence of other road users.
Several standards now describe how to write an ODD down. ISO 34503:2023 provides a specification for the ODD of automated driving systems. In the UK, BSI's PAS 1883 offers practical guidance for implementing it. Both aim to give developers, regulators and insurers a shared language.
The ODD matters most for Level 3 and Level 4 systems. Our guide to the SAE levels of autonomous driving explains why. At those levels, the system takes responsibility for driving within its domain.
A typical ODD description covers three broad groups of attributes.
A robotaxi ODD might cover one city's urban streets, in daylight and dusk, in dry or light rain, at speeds under 35 mph. A highway pilot's ODD might cover divided highways in daylight, at traffic-jam speeds.
Writing the ODD down precisely is harder than it sounds: "light rain" needs a threshold, and "urban streets" needs a list of road types and speed limits. Vague definitions lead to vague data plans, and vague data plans leave gaps. Precision at this stage saves a great deal of collection effort later.
This is where the ODD meets data planning. Each attribute in the ODD becomes a coverage target. If the domain includes light rain at dusk on four-way junctions, the data must contain enough of exactly that.
Teams usually turn the ODD into a coverage matrix. Rows list attributes, such as weather, lighting and road type. Columns track how many hours or clips the dataset holds for each combination. Gaps in the matrix show where more data is needed before the system can be trusted there.
The hardest part is usually the combinations. A dataset may contain plenty of rain and plenty of roundabouts, yet very little of both together. Those combinations are often where rare events hide.
Few systems keep the same ODD forever. Operators expand to new cities, faster roads, night driving or harsher weather. Each expansion adds new coverage targets, and each new target needs fresh data.
Monitoring matters as well. A deployed system must recognize when it is approaching the edge of its ODD, such as heavy rain arriving or a road closure forcing a detour. The data used to train that awareness should include many examples of the boundary itself, not only the comfortable middle of the domain.
This is why data sourcing is an ongoing process rather than a one-time purchase. A team that plans to move from one city to five should plan for five sets of local conditions. Local road layouts, signage and driving habits all differ. Some data providers can run targeted collection missions in a specific city, road type or ODD to close these gaps faster.
Driver assistance features also have operating limits. A lane-keeping system may only work above a certain speed, for example. But because the driver remains the fallback, these limits are usually broader and less formal. The data emphasis is on breadth across many markets rather than depth in one domain.
For Level 4, the ODD is central. The system is responsible inside it, so coverage inside the domain must be deep and complete. We explore this contrast further in our guide on how ADAS and full autonomy data differ.
Real-world data from many places helps on both sides. Broad collections support ADAS breadth. They also give Level 4 teams a head start when they enter a new domain. NATIX, for example, offers driving data from 35+ countries, collected by everyday drivers with factory Tesla cameras.
A clear ODD turns autonomy from an open-ended problem into a defined one. For autonomous driving teams working within an ODD, it also turns data sourcing from guesswork into a plan. Define the domain, map the coverage, and fill the gaps.
