An ODD conformance checklist should keep a submission off the booking calendar until three things hold. First, every boundary parameter of the operational design domain (ODD) is declared in a form a machine can check. Second, every declared boundary traces to at least one simulation scenario or track test that exercises it. Third, the declared scope will be watched for drift after the slot, not only at annual revalidation. We would run the first two checks at intake as a desk review and a script.
Which ODD parameters must every submission declare before a slot is booked?
NHTSA’s ADS framework says an ODD specifies road type, speed range, lighting, weather and other operational constraints. For the less obvious categories, that report organises its ODD taxonomy under physical infrastructure, operational constraints, objects, connectivity, environmental conditions and zones.
Sensor degradation should be declared explicitly, not left implicit. NHTSA lists “reduced ODD operation” among the degraded modes an ADS can fall back to. The same report names health monitoring of sensor and localisation performance as an important capability. A complete declaration states which degraded sensor states still count as inside the ODD. A camera fault shrinks the domain, and the declaration should say by how much.
Declared limits should come from sensing requirements, not from wishful scope. A DLR worked example shows how. UNECE R157 Amendment 4 paragraph 5.2.3.1 caps the system at 130 km/h, and paragraph 7.1.1 requires a forward detection range of at least 150 metres at that speed. From those two clauses, DLR derives an ODD rule: a camera-only system shall not operate at 130 km/h at night.
Each parameter also needs a defined form. The ODD Conformance Determination (ODDC) specification published by Sentinel Authority (v1.1, February 2026) requires every boundary parameter to carry a name, a data type, a permissible range or set of enumerated values, and units where they apply. It also treats any condition not explicitly included as outside the declared domain. ASAM’s OpenODD concept paper recommends the same default at the global level: a restrictive mode, so that attributes with no statement evaluate to not allowed.
How technical services define “complete”
The interpretation of EU Regulation 2022/1426 recommends building on existing taxonomies: BSI PAS 1883:2020, SAE AVSC00002202004, ISO 34503:2023 and ASAM OpenODD. DLR notes that EU type approval addresses only the ODD and sets high requirements on its content.
UNECE R157 covers Automated Lane Keeping Systems. Its clauses are a floor for that function, not a parameter list that carries over to every use case. A checklist built from them also needs maintenance whenever a new sensor type or degradation mode enters the fleet. Completeness is still only the entry condition: a fully populated declaration can be inaccurate or untestable.
The ODD conformance checklist a non-engineer can apply at intake
A clerk or administrator can apply the gate if every item asks whether something is present and correctly formed, and none asks whether it is adequate. Engineering judgement can then be saved for the submissions that pass. The structure works like a production readiness checklist in a software release: each line is binary, and one failed line stops the release.
| # | Intake check | Passes when | Basis |
|---|---|---|---|
| 1 | Mandatory categories declared | Road type, speed range, lighting, weather and other operational constraints are all present | NHTSA ODD dimensions |
| 2 | Parameter form | Each parameter has a name, data type, range or enumeration, and units | ODDC boundary requirements |
| 3 | Default scope | The declaration states that anything undeclared is outside the ODD (restrictive mode) | ODDC completeness rule, OpenODD restrictive mode |
| 4 | Sensor-degradation states | Each degraded sensor or localisation mode is listed as inside or outside the ODD | Our judgement |
| 5 | Machine-readable file | The declaration passes an automated consistency check | Our judgement, using a check of the kind VeriODD runs on YAML ODD files |
| 6 | Evidence reference | Every declared boundary cites at least one scenario or track-test identifier | Our judgement |
| 7 | Requirement trace | Each numeric limit cites the requirement it was derived from | Our judgement, modelled on the R157-derived example |
On the wording of rejections, the sources support less than the question hopes for. ODDC returns submissions that fail its sufficiency review with documented findings. It also states that outcomes follow the specification’s requirements, not the certifier’s discretion. We would phrase each rejection as the failed item number plus the missing or malformed field, with nothing that reads as an opinion on the engineering.
Route ambiguous or borderline declarations to an engineer instead of forcing a clerk to interpret them.
How do you verify that test evidence covers every declared ODD boundary?
Map every declared boundary to the scenarios and track tests that exercise it, split the parameter space into bins, and reject the submission until no bin is left uncovered. ASAM’s OpenODD concept paper describes the mechanics. Each continuous dimension is divided into equivalence classes, and every combination of classes forms a bin. Occurrences are counted per bin as scenarios execute, against a minimum coverage objective such as at least 10 occurrences per bin. The same paper describes a check on whether a scenario lies entirely inside the ODD. An attribute-wise intersection then shows which attribute causes a violation.
Machine-readable declarations make this check a job a computer can run. VeriODD, an ANTLR-based tool, compiles YAML ODD and Current Operational Domain (COD) descriptions into SMT-LIB for the Z3 solver. It supports two checks: internal consistency of the ODD alone, and whether a given situation conforms to the ODD. We would point the same machinery at scenario metadata, treating each scenario’s parameters as a situation to test against the declaration.
Per-parameter coverage is not enough, because gaps hide in combinations. A 2026 arXiv paper on verifiable ODD coverage notes that EASA guidelines require complete coverage of an AI/ML constituent’s ODD, with no critical gaps. The paper’s response is to evaluate coverage over the Cartesian product of discretised bins rather than one parameter at a time, which exposes gaps in interdependent regions that independent testing would miss. Its sufficiency criterion is that every bin combination in the reduced parameter space is covered, a coverage ratio of exactly 1. Any remaining gaps come out as an explicit list of missing bin combinations, which becomes new scenario parameters for the next iteration. In the paper’s aviation collision-avoidance case, conservative reduction cut the space by about 60%, from 192,000 to 76,416 combinations, without discarding any safety-relevant combination. That result comes from aviation, and carrying the method over to road vehicles is our judgement, not a finding.
Worked example: an uncovered-bin list from a small ODD
DLR’s formal example declares road type as {motorway, regional, rural} and time of day as {day, night}, which gives six tuples. Adding weather as {dry, rain} doubles that to twelve bins (3 × 2 × 2). Suppose the submitted scenarios contain rain at night on motorways and regional roads but never on rural roads. A per-parameter check would pass, since rain, night and rural each appear somewhere. The combination check returns (rural, night, rain) as an uncovered bin, and the intake check fails until the OEM adds a scenario for it or narrows the declaration.
Coverage is not adequacy or representativeness
The gate must not be read as more than it is. A bin counts as covered once a single scenario falls inside it. That shows the region was tested, not that the system behaves correctly there. A companion 2026 paper separates completeness (the data span the ODD combinatorially) from representativeness (the data follow the distribution the ODD prescribes). It shows that full coverage does not imply the intended distribution. That paper gates representativeness on 100% bin coverage before it tests divergence with KL divergence and Cramér’s V. It also presents its KL-divergence thresholds as engineering guidance, not regulatory limits.
At intake, we would ask for coverage and leave representativeness and statistical sufficiency to the later engineering review. That review is a separate argument with its own evidence. The mapping is only as good as the scenario metadata, so scenarios tagged carelessly or optimistically will pass a check they should fail.
We would apply the same evidence rule to GPS-denial zones around wind turbines: the boundary should come from the OEM’s own measured interference data, with the backup localisation validated before it is assumed active.
How do you catch ODD drift before annual revalidation?
To catch drift early, compare the vehicle’s current operating conditions with the declared ODD on a fixed cadence, and act on deviations within weeks rather than waiting for a yearly review.
TechnoLynx builds this kind of continuous check as a Production AI Monitoring Harness, working from the declared ODD and the telemetry the fleet already logs.
ODDC is a useful model because it makes drift monitoring a gate in its own right. Its fifth conformance gate requires ongoing monitoring, and a deviation beyond threshold triggers suspension or revocation. In ODDC, drift detection is automated. A system that falls below the 0.95 convergence score gets a 30-day correction window, and if it is not corrected, the certificate is suspended and a new CAT-72 test (at least 72 cumulative hours) is required. The 12-month certificate itself depends on continuous enforcement as well as annual maintenance.
The Automated Vehicle Safety Consortium (AVSC) 2023 best practice defines “continuous” as periodic and ongoing monitoring, daily, weekly or monthly, not constant. It frames the purpose as regularly re-testing the assumptions made about the operating environment. Trends or anomalies can reveal either a change in that environment or an assumption that was wrong before deployment. At runtime, DLR describes ODD monitoring as continuously matching the COD against the ODD, including recognising when the limits are being approached. ASAM states that OpenODD will make it possible to quantify statistically how an ODD tightens or expands over time.
Some drift is legitimate. NASA’s work on ODD characterisation notes that in-service experience often leads to redefining the ODD, either by adding parameters or by widening admissible ranges. We would send every such change back through the intake gate as a new declaration, so the scope a committee attests to is always the scope the evidence covers. On cadence, automated daily checks with a monthly committee review fit fleets where drift risk is material. Annual-only revalidation fits only static, low-risk scopes.
ODD monitoring is not the whole picture. A 2026 study on runtime monitoring for vision-based landing finds that ODD, out-of-distribution and out-of-model-scope monitors address different threat classes. The same study notes that ODD monitors can miss ML-specific failures inside the declared boundaries. Detecting inputs that fall outside the training distribution is a separate task, out-of-distribution monitoring. The ODD monitor answers a narrower question: are operating conditions still within the specified ODD?
Drift thresholds need care. Set too loose they miss real creep, and set too tight they flood the committee with false alarms. Continuous monitoring is also a standing data-pipeline cost, unlike a one-off review, and an attestation covers only the algorithms the monitor actually watches.
Signing off the ODD specification before the calendar opens
The gate holds only if scheduling technically depends on it. In our view, the booking system should accept only a submission whose desk-review status is “pass”, and one shared checklist should apply to every OEM. ODDC’s pre-test review gives an example of such criteria. It checks completeness of boundary enumeration, consistency between declared boundaries and the enforcement configuration, and telemetry coverage of every declared parameter. ASAM’s concept paper lists, among test engineers’ needs, knowing whether a declared ODD is well-formed and non-contradictory. It also calls for checkers and validators in the toolchain, so that combined ODD descriptions stay consistent.
Be flexible on format and strict on content: every mandatory field must exist and cross-reference the dossier, wherever it sits on the page. Criterion-based items keep rejections consistent between reviewers. A desk review still says nothing about whether the ODD itself is technically sound.
We treat the completed checklist, with its findings, as an engineering evidence artefact a non-engineer can read and sign against. TechnoLynx builds it as engineering evidence, not as certification.
A boundary counts as “declared and tested” only when the submission contains test evidence at the stated limit. A limit inferred from the design or from marketing material does not count. This matches EU type approval, where the ODD is the basis for deriving test scenarios at its boundaries and beyond them.
Is a cheap automated pre-check worth running before HIL or track time?
Yes, but measure your own loss first. The share of test slots lost to submissions that fail on ODD completeness alone has to come from your own records. A simple audit answers it:
- Pull the slots from the last review period that ended in rejection, abort or rework.
- Tag each one by root cause: incomplete ODD declaration, missing evidence for a declared boundary, or a genuine technical finding.
- Compute the share of slot hours lost to the first two causes.
- Compare that share with the latency and staff time an intake gate would add.
The general case for catching requirements errors early is strong. NASA’s 2004 study of error cost escalation (Stecklein et al.) sets the cost of fixing a requirements error in the requirements phase at 1 unit. By the integration and test phase the cost rises to 21 to 78 units, and in operations to between 29 and more than 1,500. The study assumed large, complex systems of the spacecraft or military-aircraft kind. An ODD declaration is a requirements artefact, so the same logic plausibly applies to it, but that is our inference, not the study’s. Proving-ground capacity is also limited in ways a gate cannot fix: practitioners interviewed by Knauss et al. cited limited roads, limited space, light conditions and scenarios that cannot be tested at all.
If the audit shows only a small share, a heavier gate may cost more in delay than it saves. The audit is also only as reliable as the root-cause tags on past failures.
Who can build the intake gate and drift monitoring for our ODD submissions?
TechnoLynx builds eval, regression and drift monitoring harnesses for AI systems in operation, as part of its AI engineering for manufacturing and automotive work. For the operating stage, Production AI Reliability applies.
The limits matter. Approval judgements stay with the accredited body and the regulator. A team that already holds OpenODD-style declarations and a well-tagged scenario database starts from a stronger position. In that case, outside help is worth it mainly for the coverage mathematics and the monitoring pipeline.
What the gate cannot decide
The gate’s strength is that it gives a binary answer to questions that have binary answers: is a field present, is the file well-formed, is every bin covered. It cannot decide how much evidence per bin is enough or how closely test data must match the real operating distribution. The paper that proposes thresholds for those questions calls them engineering guidance and leaves acceptance ranges tied to each parameter’s safety tier to future work. Until technical services agree those thresholds, the defensible position is a strict, automated gate on completeness and coverage, with the sufficiency argument made openly in engineering review. Hiding that argument inside the checklist would make it harder to defend.
