Operational Design Domain
The specific conditions a system is designed and validated to work in, outside which its performance is undefined rather than merely worse.
When not to use it
- As a way to excuse poor performance. A domain explains scope; it does not justify failure inside it.
- Where the domain is so narrow the system does nothing useful, which is a product problem rather than a safety one.
- As a substitute for monitoring, since a stated domain does not prevent the population drifting outside it.
Reach for something else instead
- Selective prediction — let the system abstain on inputs it recognises as unfamiliar, which is domain enforcement at the instance level.
- Continuous revalidation — re-measure on the current population rather than relying on a domain declared at launch.
- -
Read more on the blog
- Robots weed ten million acres. They still cannot pick.Agricultural robotics has a clean split between what scales and what does not, and the line falls exactly where the thesis of this territory predicts.
- Ten domains, and the specification moved in every oneTerritory 7 closes. Physical automation succeeded wherever the task could be changed, and the one place it has not is where nothing was negotiable.
- A million deliveries, and the drone never landsThe most successful autonomous delivery system in the world solved the problem by removing its hardest part rather than by solving it.
- 0.03% of construction spend, so the work moved indoorsOn a building site nothing about the task is negotiable. The industry's answer was not a better robot but a different location.
Further reading
- Kusano et al. (2025), Comparison of Waymo Rider-Only crash rates by crash type to human benchmarks at 56.7 million miles — benchmark construction weighted to the domain actually driven.
- Wong et al. (2021), External Validation of a Widely Implemented Proprietary Sepsis Prediction Model — what happens when a model meets a population outside the one it was tuned on.
Primary sources, listed so you can check the claims on this page rather than take them on trust.
Where people go wrong
- Reporting accuracy without scope, which leaves the number uninterpretable.
- Assuming performance degrades gracefully outside the domain, when it is simply unmeasured.
- Treating domain exit detection as solved because the domain is written down.
At a glance
Where this sits
A starting point. Nothing needs to come before it.
Computed from the prerequisite graph, not assigned. How this works