HASCO: A Hybrid AI Simulation Compiler for Semantic Accident Reconstruction

Menzel et al. [15] categorize vehicular scenarios into three distinct levels based on their granularity and machine readability: functional, logical, and concrete, extending upon the foundational scenario definitions provided by Ulbrich et al. [23]. The hierarchy begins with functional scenarios, which consist of a verbal description focusing on actions and events, such as “maneuvers like cut-ins and following a vehicle ahead.” This level corresponds directly to the nature of news reporting, where the emphasis is on semantic understanding rather than mathematical precision. As the level of detail increases, the machine readability increases. The hierarchy progresses to logical scenarios, defined by parameter ranges and distributions and finally to concrete scenarios, which are defined by exact parameter values.

The “specification gap” addressed in this work can be understood as the translational distance between these levels. News articles are rich in context but underspecified. Conversely, standards like OpenSCENARIO typically operate at the concrete layer, requiring precise coordinates, trajectories, and triggers to function. This work links these varying aspects by processing the linguistic descriptions of functional scenarios and refining them, alongside imputation, into the exact parameters required for concrete, executable simulations.

While the ultimate ambition of generative AI in automotive engineering is fully automated scenario synthesis, current limitations necessitate a more guarded approach. Manual translation of forensic reports into simulation is prohibitively slow, yet direct end-to-end generation by LLMs remains unreliable for safety-critical applications. As noted by Nouri et al. [17], while LLMs demonstrate significant potential in accelerating software development, their stochastic nature introduces distinct risks, including hallucinations and non-compliance with safety requirements. Consequently, relying on them as autonomous creators of forensic scenarios is insufficient.

To address this, we adopt the “code co-generation” paradigm, positioning HASCO as a “Human-in-the-Loop” compiler. This methodology aligns with the “Generate fast, Eliminate fast” principle proposed by Nouri et al., which emphasizes integrating rapid, automated sanity checks directly into the generation pipeline to filter out invalid outputs before they reach human review. By subjecting generated artifacts to preliminary assessment via a deterministic feedback loop (Software-in-the-Loop simulation), we mitigate the risk of generating syntactically valid but semantically illogical code.

In this framework, the role of the LLM shifts from an autonomous agent to a semantic compiler. By automating the syntactic complexity of OpenSCENARIO (the “boilerplate”), HASCO allows human experts to shift their focus from debugging XML tags to validating the semantic fidelity of crash parameters. This “Human-in-the-Loop” workflow reduces the reconstruction burden from manual coding to mere high-level overview and supervision.

To validate this paradigm, we conduct a dual-layer analysis on real-world accident reports. We evaluate performance not only on executability (the rate of valid code generation) but also on semantic fidelity, utilizing a graded qualitative rubric to measure the alignment between the generated simulation and the original forensic narrative. We demonstrate that high executability does not guarantee forensic accuracy, reinforcing the necessity of the expert-in-the-loop for final semantic validation.

To address this gap and validate the “Code Co-Generation” paradigm proposed in this work, we formulate the following research questions:

• $\mathrm{■}$

  RQ1 (Feasibility): To what extent can an LLM-based tool automate the generation of syntactically valid OpenSCENARIO files from unstructured forensic text?

• $\mathrm{■}$

  RQ2 (Fidelity): How does the integration of a deterministic validation mechanism (the Judge) impact the semantic fidelity of the generated scenarios compared to direct “one-shot” LLM synthesis?

ASAM OpenSCENARIO serves as the industry standard for describing dynamic content in driving simulations. OpenSCENARIO XML (v1.x) relies on a rigid, hierarchical Storyboard architecture to orchestrate events within a static map definition. The map definition is part of the corresponding OpenDRIVE standard. A scenario is not merely a sequence of frames, but a complex state machine where Acts, Maneuvers, and Events are triggered by specific run-time conditions (e.g., “start lane change when Time-to-Collision < 2s”).

This structure creates a high degree of syntactic coupling. A single semantic action, such as an “overtaking maneuver,” requires synchronized updates across multiple nested tags, such as defining trajectories, speed profiles and trigger conditions that must remain mathematically consistent relative to the static road network. The existence of these dependencies pose a specific challenge for probabilistic models like LLMs, which are prone to losing context over long token sequences.

Manually generating machine-readable .xosc and .xodr files is highly complex. A useful intermediary framework for generating OpenSCENARIO files is the scenariogeneration Python package [20]. This package provides bindings between Python and the standard, enabling the generation of .xosc and .xodr files using a well-established and user-friendly syntax.

To execute these files, we utilize esmini [8], the standard open-source reference implementation. The esmini tool functions not only as a visualizer but as a deterministic constraint solver. Unlike high-fidelity simulators such as CARLA [6] or LGSVL [22], which prioritize realism and sensor rendering and require significant computational overhead, esmini focuses exclusively on logical validation and trajectory execution. This lightweight, headless architecture allows for fast validation cycles, making it the ideal simulator for our iterative feedback loop. In our pipeline, esmini serves as the ground-truth validator: if the generated XML contains logical contradictions or syntax errors, esmini provides the explicit failure signals required for the feedback loop.

The validation of ADAS/AD systems has shifted from distance-based validation (driving billions of miles) to Scenario-Based Testing (SBT). As established by Wachenfeld et al. [24], physical test driving alone is statistically infeasible for validating safe autonomy due to the rarity of critical events. To verify safety, manufacturers must therefore test systems against rare, safety-critical events (more specifically, accidents) which are statistically scarce in naturalistic driving data [16, 21].

This methodology was standardized by the PEGASUS project [25], as part of which Menzel et al. established the aforementioned widely adopted layer model (functional, logical, concrete) for highway automation. Its successor, the VVM project [9], subsequently extended these verification frameworks to complex urban environments, cementing simulation as the cornerstone of industrial safety argumentation.

Currently, populating these test libraries relies on two primary methods:

1. 1.

   Manual Engineering: Experts manually script scenarios using simulation environment tools (e.g., IPG CarMaker, dSPACE ASM Traffic, VIRES Virtual Test Drive). This ensures high fidelity and expert control but is unscalable and labor-intensive, as every parameter must be explicitly defined and maintained [15, 3].

2. 2.

   Sensor-Based Reconstruction: Pipelines that convert log data (Lidar/Camera) from test vehicles into simulation files. While accurate, this method is strictly limited to events the fleet has actually encountered during operation [10].

This creates a “data scarcity” gap, as thousands of critical crashes occur daily and are documented in textual reports (police records, news), but this data remains inaccessible to simulation pipelines due to its unstructured nature. Automating the translation of these texts into executable scenarios offers a scalable third path for generating the critical edge cases required for robust ADAS validation [11, 12].

To ensure environmental exactness, HASCO first extracts location strings from the report and queries the Nominatim API for geocoordinates. It then downloads the corresponding OpenStreetMap (OSM) data for the defined bounding box. This OSM data is converted into an OpenDRIVE (.xodr) network using a dockerized CARLA conversion script, ensuring the static road topology matches the real-world location described in the text. Finally, the XODR map is “summarized” into a textual description that gets passed later into a combined prompt for the scenario synthesis pipeline. The pipeline may be observed at Figure 2.

In parallel with this, the vehicle extraction module resolves actor dimensions. Rather than relying on a static lookup table, this module operates dynamically per scenario. It parses vehicle descriptions (e.g., “2015 Volvo V60” or “small silver hatchback”) and queries an external knowledge base from Wikipedia to retrieve precise physical dimensions (length, width, wheelbase). For vague descriptions, it approximates dimensions based on the nearest real-world vehicle class, ensuring that collision physics in the simulation are grounded in realistic bounding boxes. This output too, in the form of an OpenSCENARIO vehicle catalog, is passed to the combined prompt for later use. The pipeline may be observed in Figure 3.

Simultaneously, the system synthesizes the dynamic scenario, the temporal script that dictates the behaviors of moving actors, their specific maneuvers and event triggers over time. To ensure the generated code is both syntactically valid and compliant with industry standards, the pipeline employs a hybrid Retrieval-Augmented Generation (RAG) module. RAG enhances the language model’s accuracy by actively retrieving relevant technical documentation to ground its output, pulling from a composite knowledge base containing:

• $\mathrm{■}$

  The ASAM OpenSCENARIO Standard (v1.x) schema definitions,

• $\mathrm{■}$

  The esmini documentation and validator rules,

• $\mathrm{■}$

  The complete scenariogeneration Python library repository.

A re-ranking mechanism filters retrieved snippets to prioritize pertinent API calls (e.g., specific ManeuverGroup classes), which are then injected into the system prompt to guide the LLM’s code generation.

To evaluate the trade-off between various levels of scenario representation, HASCO implements three distinct synthesis strategies. Each strategy operates on a different level of specification, employing a unique feedback loop to ensure validity before the final output reaches the Judge. The structural overview of these different strategies is visible in Figure 4, and the execution in Figure 5.

1. 1.

   Direct syntactic synthesis: The LLM attempts to generate raw ASAM OpenSCENARIO (.xosc) XML. The output is fed immediately into esmini in headless mode. If parsing fails (e.g., missing parameter definitions), the error log is fed back to the LLM for self-correction.

2. 2.

   Programmatic synthesis using Python: The LLM generates a Python script utilizing the scenariogeneration library. This acts as an IR of a scenario. The script is executed in a sandboxed environment; if the Python interpreter throws an error (e.g., AttributeError), the traceback is returned to the LLM to repair the API usage.

3. 3.

   Ontology-driven synthesis: To accommodate the difference between unstructured text and rigid syntax, we employ a semantic intermediate layer adapted from the framework by Bogdoll et al. [4], a choice made based on analyzing the ontology framework survey from Zipfl et al. [28] and selecting a framework that would match the needs of our generative pipeline without being overly detailed. We distilled a lightweight JSON-LD (JSON for linked data) profile focusing on core classes (Actor, Event, StartPose). This mode uses a deterministic SHACL [19] (Shapes Constraint Language) data consistency validation loop:

   • $\mathrm{■}$

     Generation: The LLM outputs a JSON-LD instance representing the semantic graph of the crash.

   • $\mathrm{■}$

     Validation: The instance is validated against a SHACL schema (shapes.ttl) to ensure logical consistency (e.g., verifying that all actors referenced in events exist in the actor list).

   • $\mathrm{■}$

     Feedback: Specific violations are injected into the next prompt. Only upon passing semantic validation is the graph passed to the heuristic translation layer for compilation.

A significant component of the ontology mode for converting from the ontology instantiation to an XOSC is the decoupling of semantic intent from syntactic implementation. Once a valid JSON-LD instance is produced, HASCO employs a deterministic compiler to convert the high-level event graph into a concrete OpenSCENARIO XML file. This layer handles the low-level syntactic engineering that LLMs typically struggle with.

The translation layer parses the sequence of Event nodes for each actor. Unlike direct generation, which must output frame-by-frame coordinates, our compiler reconstructs a continuous polyline trajectory from sparse keyframes. It extracts the StartPose ($t=0$) and subsequent event timestamps ($t_n$). If an event implies a lane change (inferred via regex matching of laneId tokens in the event summary), the compiler automatically injects intermediate waypoints to smooth the lateral transition, ensuring kinematic feasibility without requiring the LLM to calculate vector math.

To translate natural language summaries into executable triggers, the layer utilizes a keyword-based heuristic classifier:

• $\mathrm{■}$

  Stop Logic: Events containing tokens such as “stop”, “stationary”, or “halt” are automatically mapped to an OpenSCENARIO SpeedAction with a target speed of $0.0$.

• $\mathrm{■}$

  Crash Inference: Events containing “collision”, “impact”, or “rear-end” (provided they lack disqualifiers like “near-miss”) are treated as stop triggers.

This compiler ensures that the complex ConditionGroup and SimulationTimeCondition XML blocks required to synchronize these actions across multiple actors are mathematically consistent, effectively functioning as a “type system” for physical interactions.

A critical innovation of HASCO is the Judge loop, which operates as a self-healing feedback mechanism to enforce both runtime robustness and forensic fidelity. The process is visualized in Figure 6.

Unlike “fire-and-forget” generators, this component employs a two-stage validation process:

1. 1.

   Syntax and runtime repair: Before the scenario is semantically evaluated, HASCO attempts to compile the generated artifact (Python or Ontology) into a .xosc file. If the generation process throws a runtime exception or violates static guardrails (e.g., using invalid enums), the error trace is immediately fed back to the synthesis model for repair. This ensures that the system recovers from brittle syntax errors before they cascade into downstream failures.

2. 2.

   Semantic and functional alignment: Once a valid .xosc artifact is produced, it is parsed into a structured event log (e.g., “Actor A: ChangeLane at $t=5s$”). The Judge LLM compares this log against the original police report. Crucially, this step detects silent failures, scenarios where the code executes successfully but produces an empty or inert simulation (e.g., actors spawning but never moving). If the Judge detects a misalignment or a functional void, it generates a natural language critique (e.g., “The simulation is inert; the report describes a collision, but no trigger was activated.”). This critique acts as a semantic constraint for the next synthesis iteration, often converting a “technically valid but broken” scenario into a fully executable one.

We first analyzed binary executability (pass/fail) and failure causes to quantify the validity of the overall procedure and measure the Judge’s contribution. Table 1 presents the success rates across the three synthesis strategies. The results strongly validate the “Intermediate Representation” hypothesis.

Direct LLM generation (Mode 1) proved unreliable for complex scene engineering, suffering a 95% failure rate. The verbose nature of OpenSCENARIO XML led to frequent “long-dependency” errors, where the model failed to synchronize coordinate systems across nested ManeuverGroup tags. In contrast, the Ontology-guided compiler (Mode 3) achieved 95% validity. By offloading the syntactic complexity to the deterministic heuristic translation layer, the LLM only needed to produce a valid JSON graph. The remaining 5% of failures were attributed to external geocoding timeouts (Nominatim API) rather than generation logic errors; resolving these infrastructure issues could potentially raise this method to near 100% executability. Two notable examples of outright failures across the board are the report in Japanese (which failed to geocode in all pipelines, owing to the language barrier for the Nominatim OSM pipeline) and another report in Spanish (comprising of a complex textual report) which failed compilation across the board due to failures to extract the location, mentioned vehicles and the events that occurred.

The addition of a Judge Loop improved executability modestly across modes 1 and 3, but the effect was most pronounced in the Python mode (+10.0%). This gain is attributed to the Judge’s ability to detect silent failures, scenarios where the generated Python script executes successfully (i.e., no runtime exception) but produces a functionally inert or empty OpenSCENARIO file. By critiquing these empty outputs (e.g., “The scenario duration is 0s”), the Judge essentially acts as a semantic linter, forcing the model to correct the underlying logic during the retry phase and converting invalid outputs into executable artifacts.

To quantify the performance of HASCO beyond a binary pass/fail, we adopted a 4-point Likert scale (0–3) evaluating the simulation’s utility. This rubric classifies scenarios based on the intervention required to make them usable:

• $\mathrm{■}$

  Bin 0: Syntax failure (indication of compilation error). The pipeline failed to produce a valid, runnable .xosc file. We categorize these failures into two distinct groups: infrastructure errors (e.g., geocoding API timeouts) and generative failures. The latter reveals specific limitations in the LLM’s ability to generate rigid XML structures, which we classify as a “Failure mode catalogue” for future research:

  Structural malformation (broken XML format): The LLM fails to generate a well-formed XML tree, often missing closing tags or root definitions due to context window limits. For example, the parser returns “Couldn’t find OpenSCENARIO element,” indicating a truncated file. This may be potentially fixed by enforcing constrained decoding (grammar-based sampling) or increasing token limits for verbose XML output.

  Asset hallucination (catalog integration failures): The model generates syntactically valid code that references non-existent external assets, failing to ground the generation in the local file system. One example of this is a log showing “Couldn’t locate catalog file: VehicleCatalog,” because the model hallucinated a standard library path. A potential fix is to explicitly inject available asset paths and catalog entry names into the system prompt context.

  Simulator incompatibility (semantic violations): The model generates valid standard OpenSCENARIO, but utilizes conditions or actions not supported by the specific target simulator (e.g., esmini). One common error of this type is “Exception: Unsupported condition: SimulationTimeCondition”, occurring because the engine does not implement that specific standard feature. The model may be fine-tuned or prompt-engineered specifically on the target simulator’s documentation rather than the general ASAM standard.

  Convergence failure: Cases where the self-correction loop exhausted all attempts without reaching a valid state. A common instance is that the pipeline times out after the maximal number of retries, unable to resolve a complex dependency chain. One way of remediating this may be to decompose complex scenarios into smaller, modular generation steps rather than attempting single-shot generation.

• $\mathrm{■}$

  Bin 1: Semantic failure (narrative/physics hallucination). The scenario executes, but the core causal event is missing or fundamentally incorrect. For example, the report describes a T-bone collision at an intersection, but the simulation depicts two vehicles passing on a highway without contact.

• $\mathrm{■}$

  Bin 2: Draft quality (necessitates a revision by a Human-in-the-Loop). The scenario captures the correct core event, but exhibits kinematic artifacts or asset mismatches. For example, the collision occurs as described, but the target vehicle “teleports” (jerky movement) or the vehicle type is generic (e.g., a sedan instead of a bus). These files are usable but require manual “polishing”, either via a GUI tool or by manually editing the generated XML.

• $\mathrm{■}$

  Bin 3: Production quality (One-Shot). The scenario is semantically faithful, kinematically smooth, and requires no or very little human intervention. Turns taken, events and timing align with the report; the collision physics are plausible, with potentially minor manual expert updates.

The results are visible in Table 2, and the distribution is visualized in Figure 7. These results give us key insights into the qualitative benefits of various HASCO modalities. To begin with, we may observe that Mode 1, both with Judge and without Judge, despite initially having non-zero executability, displays no possibility of achieving syntax compatibility with OpenSCENARIO. Those rare several instances where Mode 1 executes result in a static environment only determined by the .xodr map file within esmini. Therefore, the entire generative corpus of Mode 1 within HASCO may be discarded (bin 0), with the conclusion that recreating vehicular scenarios by way of generating direct .xosc files is not a task achievable without great difficulty. Modes 2 and 3 provide much more interesting nontrivial results.

Half of all the scenarios in Python mode without Judge bin as either Draft (42.5%) or Production quality (7.5%). Generation quality rises when the Judge is added into the pipeline, with Draft bin encompassing 32.5% of cases and Production bin encompassing 30% of total cases. Therefore, with Judge, a total of 62.5% cases are of “acceptable” Draft or Production quality. As per Figure 8 on the left, this indicates that adding the Judge significantly increases the quality of produced scenarios via Python intermediate representation, with a 300% relative increase in Production quality scenarios when compared to the non-Judge mode.

With regards to the Ontology mode, the non-Judge version initially bins 37.5% of all scenarios as either Draft (17.5%) or Production quality (20%), a result worse than Python, but shows a significant uptick when Judge is introduced, with acceptable case numbers going to 57.5% of either Draft (35%) or Production quality (22.5%). As visualized on Figure 8 on the right, the Judge reduces the amount of scenarios that bin as semantic failures by 36.3%, a significant drop.

We tracked token consumption to determine the cost-fidelity trade-off (Figure 9). Here, the quality score $S_{avg}$ is a weighted mean of the rubric bins ($S_{avg}=\frac{1}{N}\sum w_i{n}_i$, with weights $w\in \{0,1,2,3\}$ corresponding to syntax failure, semantic failure, draft, and production quality).

Figure 9(A) shows Ontology mode achieving the most favorable trade-off. Figure 9(B) illustrates the executability rate, where Ontology mode again excels. The Judge loop provides relatively modest improvements for both Python and Ontology modes given the outsized $\approx 2.5\times$ token cost and $\approx 3\times$ latency increases (averaging 180 s per run vs. 60 s). Thus, for large-scale generation, Mode 3 (Ontology, No Judge) is the most cost-effective configuration, reserving the expensive Judge loop for complex edge cases (e.g., scenarios that execute but remain semantically inert).