16% to 76% Compilation Success: Building an Autonomous-Driving Scenario Ontology

Where the Bottleneck Sits: Regulation Is Text, Testing Is Structure

Autonomous-driving validation's bottleneck isn't the model — it's the scenario. Regulatory text from NHTSA or UN vehicle regulations describes "a pedestrian suddenly appearing at an intersection" in natural language, but a simulator needs road geometry, actor trajectories, and trigger conditions declared in a structured DSL (domain-specific language) before it can run anything. That conversion gap between legal text and an executable scenario is what sets the pace of validation.

The market size shows how much weight that conversion work carries. Global Market Insights' January 2026 report puts the global self-driving car market at $202.4 billion in 2025, growing to $220.8 billion in 2026 and $354.6 billion by 2035 (5.4% CAGR). By automation level, Level 3 held the largest 2025 share at 46%.

Ontology Isn't Scenario Generation — It's Scenario Grammar

Chat2Scenic (reviewed in detail in the companion research review below) demonstrates one way to automate this conversion. It refines scenarios iteratively through a chat interface, while retrieving DSL grammar and regulatory constraints together via RAG grounded in regulatory knowledge, keeping outputs in an executable script form. Industry standards like ASAM OpenSCENARIO and OpenLABEL have already defined schemas for describing roads, actors, and events — so the ontology's job isn't inventing a new taxonomy, it's bridging that standard schema to specific regulatory clauses.

From Standard Linkage to Operations: An Autonomous-Driving Scenario Ontology Roadmap

Planning doesn't mean generating scenarios from scratch — start by mapping ASAM OpenX schema elements to regulatory clauses (NHTSA and UN regulation article numbers). Reasonable starting targets: 80%+ compilation success rate for generated scenarios, and 100% scenario coverage per mapped regulatory clause.

Four failure patterns recur. Re-explaining DSL grammar to the model every time, so generation results fail to compile inconsistently across versions. Managing the regulation-to-scenario mapping in a manual spreadsheet, losing traceability when clauses get amended. Generating actor trajectories without specifying trigger conditions (e.g., the moment a pedestrian suddenly appears), letting unexecutable scenarios slip into the test set. And failing to declare ODD (operational design domain) boundaries in the schema, so out-of-domain scenarios get tested identically to in-domain ones.

Design the recovery branch to treat a compile failure as a reversible signal. When a generated script fails DSL grammar validation, don't discard it outright — classify the failure cause (grammar vs. constraint violation) and feed it back into the regeneration prompt; route repeated failures to a human review queue.

On the operational side, auto-tabulate per-clause coverage before every deploy, log the generated-scenario compilation success rate as a standard field, and sample-check that scenarios outside the ODD boundary haven't slipped in.

For ongoing operation, pull the top causes of compile failure each month and sort them into two buckets: DSL grammar explanation needs reinforcing, or the regulatory mapping does. Given Level 3 holds the largest 46% market share, prioritizing scenario coverage for Level 3's ODD is where the investment pays off most.

Quick Reference

The core of an autonomous-driving scenario ontology isn't a new taxonomy — it's the mapping between an existing standard like ASAM OpenX and regulatory clauses. Build a recovery branch that feeds compile failures back as regeneration signals, and track per-clause coverage operationally, and you can systematically shrink the conversion bottleneck from legal text to executable scenario.

References

Self-Driving Cars Market — Global Market Insights

Chat2Scenic research review — sunny34.com