DriveCombo: Benchmarking Compositional Traffic Rule Reasoning in Autonomous Driving

Enhui Ma; Jiahuan Zhang; Guantian Zheng; Tao Tang; Shengbo Eben Li; Yuhang Lu; Xia Zhou; Xueyang Zhang

cs.CVMar 2, 2026

DriveCombo: Benchmarking Compositional Traffic Rule Reasoning in Autonomous Driving

Authors: Enhui Ma, Jiahuan Zhang, Guantian Zheng, Tao Tang, Shengbo Eben Li, Yuhang Lu, Xia Zhou, Xueyang Zhang, +5 more

Organizations: Autolab, Westlake University · Li Auto Inc · Tsinghua University · The University of Hong Kong

Abstract

Multimodal Large Language Models (MLLMs) are rapidly becoming the intelligence brain of end-to-end autonomous driving systems. A key challenge is to assess whether MLLMs can truly understand and follow complex real-world traffic rules. However, existing benchmarks mainly focus on single-rule scenarios like traffic sign recognition, neglecting the complexity of multi-rule concurrency and conflicts in real driving. Consequently, models perform well on simple tasks but often fail or violate rules in real world complex situations. To bridge this gap, we propose DriveCombo, a text and vision-based benchmark for compositional traffic rule reasoning. Inspired by human drivers' cognitive development, we propose a systematic Five-Level Cognitive Ladder that evaluates reasoning from single-rule understanding to multi-rule integration and conflict resolution, enabling quantitative assessment across cognitive stages. We further propose a Rule2Scene Agent that maps language-based traffic rules to dynamic driving scenes through rule crafting and scene generation, enabling scene-level traffic rule visual reasoning. Evaluations of 14 mainstream MLLMs reveal performance drops as task complexity grows, particularly during rule conflicts. After splitting the dataset and fine-tuning on the training set, we further observe substantial improvements in both traffic rule reasoning and downstream planning capabilities. These results highlight the effectiveness of DriveCombo in advancing compliant and intelligent autonomous driving systems.

Figures & tables

Dataset	Venue	Country	QA pairs	Images	Scene source	3D Scene	Traffic Rules	#Rules
Talk2Car [ 9 ]	EMNLP’19	2	12K	1.8K	nuScenes [ 3 ]	✓	✗	-
DRAMA [ 24 ]	WACV’23	JP	14K	-	DRAMA [ 24 ]	✓	✗	-
nuScenes-QA [ 34 ]	AAAI’24	2	450K	34K	nuScenes [ 3 ]	✓	✗	-
LingoQA [ 27 ]	ECCV’24	UK	419K	28K	LingoQA [ 27 ]	✓	✗	-
VLAAD [ 33 ]	WACV’24	US	64K	-	BDD [ 54 ]	✓	✗	-
DriveBench [ 50 ]	ICCV’25	2	21K	19K	nuScenes [ 3 ]	✓	✗	-

Table 1: Comparison of Existing Vision Language Driving Datasets. “#Rules” means the number of traffic rules within each scenario. “3D Scene” indicates whether image sequence frames information is available.

Figure 2: Task Examples of the Five-Level Cognitive Ladder in DriveCombo , progressing from single-rule understanding (L1) to multi-rule integration and conflict resolution (L5). Each level presents a scenario with corresponding traffic rules bases, visual context, and multiple choice questions, enabling systematic evaluation of MLLMs’ compositional traffic rule reasoning under increasing cognitive complexity. The colored texts in “Scenario Description” correspond to the same colors in “Rule Basis”, as well as the colored boxes in the visual context, indicating the rule-to-scene alignment.

Figure 3: Data Distribution across (a) action types, (b) road types, (c) weather conditions, and (d) country sources in DriveCombo.

Figure 4: Rule2Scene Agent . The agent consists of two modules: (a) Rule Crafter performs semantic structuring of atomic rules $r_{i}\in R$ , generates candidate rule pairs $p_{i}$ , verifies spatiotemporal coexistence to construct a hierarchical rule set $M$ ; (b) Scene Weaver converts the hierarchical rules $m_{i}\in M$ into textual scene descriptions $s_{i}$ , generates structured semantic representations $w_{i}$ , maps them to the CARLA simulator [ 10 ] , renders and captures images $i_{i}$ , and finally generates high-fidelity driving scenarios for model evaluation.

Model	Size	L1	L2	L3	L4	L5
Open-source Models
Gemma 3	4B	58.79	47.80	45.98	44.55	26.66
Gemma 3	12B	64.32	58.69	54.90	52.32	29.54
Gemma 3	27B	73.94	67.39	65.55	63.10	37.42
Llama 3.2	11B	52.46	49.23	45.75	41.94	25.74
Qwen3-VL	2B	61.72	59.29	57.39	53.15	25.10

Table 2: Performance of MLLMs on DriveCombo. Green and light green mark the best and second-best open-source models, while blue and light blue indicate the best and second-best proprietary models.

Model	Size	L1	L2	L3	L4	L5
Open-source Models
Gemma 3	4B	62.61	51.75	50.93	48.16	29.82
Gemma 3	12B	68.28	62.19	59.39	56.56	33.08
Gemma 3	27B	78.30	71.20	69.51	67.55	41.15
Llama 3.2	11B	58.15	53.89	51.36	45.59	30.22
Qwen3-VL	2B	66.67	63.08	61.40	57.47	29.07

Table 3: Performance of MLLMs on DriveCombo-Text variant (only Text Input).

Model	Size	CoT	RAG	SFT	L1	L2	L3	L4	L5	Avg.
Gemma 3	4B				58.8	47.8	46.0	44.5	26.7	44.8
		✓			60.1	52.4	48.3	47.2	29.2	+2.70
		✓	✓		63.4	57.6	54.2	51.2	33.4	+7.31
		✓	✓	✓	86.3	81.9	76.9	74.2	51.3	+29.37
Gemma 3	12B				64.3	58.7	54.9	52.3	29.5	51.9
		✓			65.0	60.4	56.2	53.2	30.3	+1.06

Table 4: Evaluating DriveCombo as a knowledge injector for MLLMs with three enhancement strategies (CoT, RAG, and SFT).

		L2( $m$ ) $\downarrow$
Model	SFT Data	1 $s$	2 $s$	3 $s$	Avg.
	-	1.66	3.54	4.54	3.24
	DriveQA	1.30	3.46	3.98	2.91
LlaVa-1.6-Mistral-7B [ 21 ]	DriveCombo	1.27	3.29	3.92	2.68
	-	1.66	3.36	4.15	3.06
	DriveQA	1.30	3.08	3.73	2.71

Table 5: End-to-End Trajectory Planning Results on nuScenes validation set. We compute the L2 error at different prediction horizons (1s, 2s, and 3s). A lower L2 error indicates that our DriveCombo dataset transfers from simulation to real-world planning tasks more effectively than DriveQA [ 47 ] .

Figure 5: Performance of MLLMs on Multi-Rule Compositional Reasoning . “#Rules” means the number of traffic rules within each scenario. The results are obtained in a zero-shot setting. Since L1 is single-rule setting, we only present L2-L5 here.

Figure 6: DriveCombo’s scenarios can be seamlessly converted into closed-loop test cases to evaluate end-to-end models under real rule constraints. The green line means the GT trajectory and the red means the test trajectory.

Method	Benchmark	Closed-loop Metrics
Method	Benchmark	Driving Score ↑	Success Rate (%) ↑	Efficiency ↑	Comfortness ↑
UniAD-Base [ 15 ]	Bench2Drive [ 17 ]	45.81	16.36	129.21	43.58
UniAD-Base [ 15 ]	DriveCombo	27.59	13.33	101.32	31.92
VAD [ 18 ]	Bench2Drive [ 17 ]	42.35	15	157.94	46.01
VAD [ 18 ]	DriveCombo	26.68	13.33	116.53	33.96

Table 6: Closed-loop Results of E2E-AD Methods in Bench2Drive and our DriveCombo.

	Open-source Models (Avg.)					Proprietary Models (Avg.)
Country	L1	L2	L3	L4	L5	L1	L2	L3	L4	L5
USA	71.36	67.69	62.26	58.98	35.11	86.29	79.50	72.93	68.69	42.71
China	72.38	67.25	63.01	59.99	34.76	85.89	79.22	73.03	68.95	42.41
UK	70.07	66.56	62.48	56.33	33.58	83.55	78.80	72.66	67.91	41.29
Japan	63.60	58.06	55.77	52.28	30.11	73.86	71.56	65.36	63.03	37.26
Australia	61.75	55.18	51.29	49.96	29.68	79.05	72.09	64.03	62.39	37.90

Table 7: Performance of MLLMs across countries on DriveCombo. We report average results of 8 open-source and 6 proprietary models used in the main paper.

Model	Size	L2	L3	L4	L5	L2	L3	L4	L5	L2	L3	L4	L5
Model	Size	#Rules=3				#Rules=4				#Rules=5
Open-source Models
Gemma 3	4B	47.11	44.57	41.89	20.05	44.40	42.52	39.91	16.57	40.93	38.12	32.06	13.89
Gemma 3	12B	56.30	54.85	50.14	24.41	45.97	43.82	43.31	23.43	43.41	41.57	37.72	20.45
Gemma 3	27B	60.74	58.18	54.23	33.05	52.56	51.96	47.68	31.33	48.59	45.86	42.07	27.51
Llama 3.2	11B	48.38	43.46	38.29	17.57	38.55	35.21	34.68	13.29	34.59	25.96	22.87	8.71

Table 8: Performance of MLLM in Complex Driving Scenarios with Different Numbers of Rules. “#Rules” denotes number of traffic rules in each scenario. Green and light green mark the best and second-best open-source models, while blue and light blue indicate the best and second-best proprietary models.

Figure 7: More Examples of Level 1 task in DriveCombo under #Rules=2 setting .

Figure 8: More Examples of Level 2 task in DriveCombo under #Rules=2 setting .

Figure 9: More Examples of Level 3 task in DriveCombo under #Rules=2 setting .

Figure 10: More Examples of Level 4 task in DriveCombo under #Rules=2 setting .

Figure 11: More Examples of Level 5 task in DriveCombo under #Rules=2 setting .

Figure 12: More Examples of DriveCombo under #Rules=3, #Rules=4, and #Rules=5 setting .

Figure 13: Illustration of the three intermediate outputs of Scene Weaver in our proposed Rule2Scene Agent . First, the input rules are converted into (a) a complex driving scenario

s_{i}

, which is then transformed into (b) a Domain Specific Language

d_{i}^{*}

. Finally, the scenario is mapped into (c) an OpenSCENARIO language

w_{i}

that can be executed in the CARLA simulator.

System Persona

You are a question-generation assistant proficient in traffic regulations. I will give you a driving rule. Please generate an autonomous driving test case based on the given traffic regulation clause. Output the result in JSON format, including the following fields: scenario description, question stem, options (one correct option and three distractors), question logic, correct answer option, and an explanation of the correct answer. The question design should follow these principles: 1. Ensure that the options have similar semantics to prevent the model from guessing based on surface-level wording. 2. To increase the difficulty of the question, avoid including any explicit safety-related cues or contextual hints in the scenario description, question stem, or options that could reveal the correct answer. 3. Use vague or implicit semantic descriptions: remove direct hints and instead imply trigger conditions through sensor data or subtle scene details to stimulate the model’s reasoning and judgment abilities. 4. When designing the correct answer, create options that are “counterintuitive yet reasonable.” Avoid making “the safest choice” automatically the correct one — the goal is to make “safest” not equal to “most compliant.” 5. If a regulation contains multiple triggering conditions, select only one to construct the test scenario. For example, if a regulation states: “When driving at night, in rain or fog, or when visibility is poor and the safe distance cannot be confirmed, lane changes are prohibited,” choose only one weather condition (e.g., rain) as the trigger. Please remember that you should output json without any other output, the format of json is: { “Scenario Description”: “…”, “Question Stem”: “…”, “Options”: { “A”: “…”, “B”: “…”, “C”: “…”, “D”: “…” }, “Question Design Logic”: “…”, “Correct Answer Option”: “…”, “Explanation of the Correct Answer”: “…” }. Example 1 : Input Rule: Other vehicles and pedestrians shall yield to vehicles performing emergency duties. Output JSON: { “Scenario Description”: “An autonomous vehicle is driving on an urban main road. The ambulance is rapidly approaching from behind. The current lane is congested, and surrounding vehicles are reacting differently—some slow down and move aside, while others maintain their speed.”, “Question Stem”: “As the driver, how should you respond correctly in this situation?”, “Options”: { “A”: “Immediately pull over and stop to make way for the ambulance to pass first.”, “B”: “Maintain the current speed and avoid changing lanes to prevent traffic confusion.”, “C”: “Accelerate to leave the area quickly and avoid crossing paths with the ambulance.”, “D”: “Continue driving along the planned route and only consider yielding when the ambulance is within 5 meters.” }, “Question Design Logic”: “This question examines whether an autonomous driving system adheres to legal requirements upon detecting an emergency vehicle, rather than merely following standard traffic flow strategies. The scenario implies the presence of an “emergency-response vehicle” through auditory and visual cues—such as sirens and red-blue flashing lights—without explicitly stating instructions like “pull over immediately.” This design tests whether the system can infer the obligation to yield based on contextual features.Option A represents lawful behavior in accordance with Article 53 of the Road Traffic Safety Law. Options B and D, though appearing to “maintain order,” fail to promptly fulfill the duty to yield. Option C reflects a common “counterintuitive yet unlawful” response—accelerating to avoid interference, which in fact obstructs emergency passage.The key focus of the question lies in whether the model can correctly prioritize between “traffic flow stability” and “emergency right-of-way,” recognizing the higher legal precedence of the latter.”, “Correct Answer Option”: “B”, “Explanation of the Correct Answer”: “According to Article 53 of the Road Traffic Safety Law, other vehicles and pedestrians must yield to vehicles performing emergency duties. When an autonomous system detects emergency vehicles such as ambulances, fire trucks, or police cars, it should proactively slow down and pull over to allow them to pass. Option A correctly reflects the yielding principle. Option B avoids lane changes but fails to fulfill the yielding obligation; Option C creates a potential safety hazard by accelerating; Option D’s conditional yielding violates the requirement for immediate cooperation.” } Example 2 : …

User Input

Input Rule: {rule_content} Output JSON:

Table 9: Prompt of MCQ Generation of Level 1.

System Persona

You are a question-generation assistant proficient in traffic regulations. I will give you { two / three / four / five } driving rules. Please generate an autonomous driving test case based on the { two / three / four / five } given traffic regulation clauses. Output the result in JSON format, including the following fields: scenario description, question stem, options (one correct option and three distractors), question logic, correct answer option, and an explanation of the correct answer. The question design should follow these principles: 1. Ensure that the options have similar semantics to prevent the model from guessing based on surface-level wording. 2. To increase the difficulty of the question, avoid including any explicit safety-related cues or contextual hints in the scenario description, question stem, or options that could reveal the correct answer. 3. Use vague or implicit semantic descriptions: remove direct hints and instead imply trigger conditions through sensor data or subtle scene details to stimulate the model’s reasoning and judgment abilities. 4. When designing the correct answer, create options that are “counterintuitive yet reasonable.” Avoid making “the safest choice” automatically the correct one — the goal is to make “safest” not equal to “most compliant.” 5. If a regulation contains multiple triggering conditions, select only one to construct the test scenario. For example, if a regulation states: “When driving at night, in rain or fog, or when visibility is poor and the safe distance cannot be confirmed, lane changes are prohibited,” choose only one weather condition (e.g., rain) as the trigger. Please remember that you should output json without any other output, the format of json is: { “Scenario Description”: “…”, “Question Stem”: “…”, “Options”: { “A”: “…”, “B”: “…”, “C”: “…”, “D”: “…” }, “Question Design Logic”: “…”, “Correct Answer Option”: “…”, “Explanation of the Correct Answer”: “…” }. Example 1 : Input Rule 1: When driving on a narrow bridge … Input Rule 2: When lane markings are dashed … Input Rule 3 (if necessary) : … Input Rule 4 (if necessary) : … Input Rule 5 (if necessary) : … Output JSON: { “Scenario Description”: “The ego vehicle is driving along a two-way …”, “Question Stem”: “As the driver, how should you respond correctly in this situation?”, “Options”: { “A”: “Quickly overtake the front …”, “B”: “Slow down, maintain a safe …”, “C”: “Briefly use the oncoming …”, “D”: “Honk in advance to alert …” }, “Question Design Logic”: “This question combines two traffic …”, “Correct Answer Option”: “B”, “Explanation of the Correct Answer”: “Option B represents compliant behavior: maintaining …” } Example 2 : …

User Input

Input Rule 1: {rule_content_1} Input Rule 2: {rule_content_2} Input Rule 3 (if necessary): {rule_content_3} Input Rule 4 (if necessary): {rule_content_4} Input Rule 5 (if necessary): {rule_content_5} Output JSON:

Table 10: Prompt of MCQ Generation of Level 2-4.

System Persona

I will give you { two / three / four / five } driving rules. Please generate an autonomous driving test case based on the { two / three / four / five } given traffic regulation clauses. The case should create a priority conflict that requires the test taker to make a judgment. Output the result in JSON format, including the following fields: scenario description, question stem, options (one correct option and three distractors), question logic, correct answer option, and an explanation of the correct answer. The question design should follow these principles: 1. You must select the regulation with the higher priority from the { two / three / four / five } given inputs as the correct answer when creating the question. The priority hierarchy of traffic regulations is as follows: Pedestrian life safety

>

Emergency avoidance vehicles

>

On-site command personnel

>

Traffic lights

>

Traffic signs

>

Road markings

>

Interactive right-of-way

>

Defensive driving

>

Emergency exceptions. 2. Ensure that the answer options have similar semantic meanings, to prevent the model from guessing based on surface-level wording. 3. To increase the difficulty level, avoid explicit safety cues in the scenario description, question stem, and answer options. Do not include context that clearly suggests which choice is safer or more correct. 4. The scenario should not fully satisfy any single rule; instead, place it in a borderline condition so that the test taker must decide whether it “qualifies.” For example, when describing environmental conditions, be ambiguous—avoid direct statements like “poor visibility” or “low visibility.” Instead, describe how sensors behave, letting the test taker infer whether the rule should be triggered. 5. When designing the correct answer, make it “counterintuitive but reasonable.” Avoid making “the safest option” always the correct one. The correct answer should reflect regulatory compliance, not simply maximum safety. 6. If a regulation contains multiple trigger conditions, choose only one to build the test scenario. For example, if a rule states: “When driving at night, in rain/fog, or under poor visibility where safe distance cannot be confirmed, lane changes are prohibited,” select just one condition (e.g., nighttime) as the trigger. 7. The options must represent specific driving actions. If the { two / three / four / five } input regulations concern lane-change behavior, the scenario should feature a multi-lane road, and the answer options could be: changing lanes to the left, changing lanes to the right, keeping the current lane, or other relevant maneuvers. Please remember that you should output json without any other output, the format of json is: { “Scenario Description”: “…”, “Question Stem”: “…”, “Options”: { “A”: “…”, “B”: “…”, “C”: “…”, “D”: “…” }, “Question Design Logic”: “…”, “Correct Answer Option”: “…”, “Explanation of the Correct Answer”: “…” }. Example 1 : Input Rule 1: When it is nighttime … Input Rule 2: When the driver needs … Input Rule 3 (if necessary) : … Input Rule 4 (if necessary) : … Input Rule 5 (if necessary) : … Output JSON: { “Scenario Description”: “The ego vehicle is …”, “Question Stem”: “As the driver, how should you respond correctly in this situation?”, “Options”: { “A”: “Take advantage of a brief gap …”, “B”: “Stay in the current lane …”, “C”: “Slightly adjust the driving …”, “D”: “Brake firmly and stop …” }, “Question Design Logic”: “Regulation 1: ’When it is nighttime, raining, foggy, or when the safe distance cannot …”, “Correct Answer Option”: “B”, “Explanation of the Correct Answer”: “Although the fallen cone ahead is an obstacle …” } Example 2 : …

User Input

Table 11: Prompt of MCQ Generation of Level 5.

System Persona

Your task is to act as a rigorous evaluator of a generated driving-rule MCQ question. I will provide one question in JSON format. Your goal is to determine whether the question is logically valid and fully consistent with the traffic rules, based on four criteria: 1. Correctness of the Answer: - The “Correct Answer Option” must be logically correct. - The explanation must be sound, and no other option may also be correct. 2. Faithfulness to the Input Rules: - The scenario must accurately incorporate all and only the rules implied in the question design. - No part of the scenario should contradict the rule conditions. 3. Quality of the Options: - There must be exactly four options (A, B, C, D). - The distractors must be plausible but incorrect. - No option may be ambiguous or require unstated assumptions. 4. Structural Completeness: - The JSON must include: Scenario Description, Question Stem, Options, Correct Answer Option, and Explanation. - All parts must be internally coherent. After checking all criteria: - If ANY criterion fails → Output 0, followed by the reasoning. - If ALL criteria pass → Output 1, followed by the reasoning. Example 1 : Input Question Json: { ”Scenario Description”: ”A foggy day with visibility below 40 meters.”, ”Question Stem”: ”What is the correct speed?”, ”Options”: { ”A”: ”70 km/h”, ”B”: ”30 km/h”, ”C”: ”Turn right”, ”D”: ”High beam” }, ”Question Design Logic”: ”Low-visibility speed rule.”, ”Correct Answer Option”: ”A”, ”Explanation of the Correct Answer”: ”High speed is acceptable in fog.” } Output Decision: 0 Output Reasoning: The selected answer violates low-visibility speed rules; distractors include irrelevant actions; the explanation contradicts the rule. Therefore, the question is invalid. Example 2 : …

User Input

Input Question Json: { question json} Output Decision: Output Reasoning:

Table 12: Prompt of MCQ Generation Check.

System Persona

You are an expert assistant proficient in analyzing and structuring traffic regulations. I will give you a natural-language traffic rule. Your task is to transform this rule into a normalized atomic structure by extracting exactly the following five fields: 1. Rule Content : A concise restatement of the core meaning of the rule without ambiguity. The restatement must follow the template: “When [condition], the driver may / must / must not [action].” 2. Perceptual Type: Categorize the rule as “static” (triggered by signs, markings, road type, fixed conditions), or “dynamic” (triggered by interactions with other vehicles, pedestrians, or changing traffic flow). 3. Norm Type: Determine whether the rule is “obligatory” (the driver must perform the action), “forbidden” (the driver must not perform the action), or “permissive” (the driver may perform the action). 4. Action Type: The primary driving action described by the rule (e.g., overtake, left turn, right turn, lane change, merge, acceleration, deceleration, signaling, yielding, parking, etc.). 5. Numeric Constraints (if applicable): Extract any explicit speed limits. You must output the result strictly in the following JSON format: { “rule_content”: “…”, “perceptual_type”: “…”, “norm_type”: “…”, “action_type”: “…”, “numeric_constraints”: “…” } Guidelines: - Do NOT add any additional fields. - Do NOT invent content beyond what the rule states. - Keep each field concise but semantically complete. Example 1 : Input Rule: When visibility is below 50 meters due to heavy fog, the driver must reduce speed to at most 30 km/h. Output JSON: { “rule_content”: “When visibility falls below 50 meters, must slow to 30 km/h. ”, “perceptual_type”: “static”, “norm_type”: “obligatory”, “action_type”: “speed limit”, “numeric_constraints”: { “upper bound”: 30 “lower bound”: 0 }, } Example 2 : Input Rule: Drivers must not overtake when a solid yellow centerline is present. Output JSON: { “rule_content”: “When a solid yellow centerline is present, the driver must not overtake.”, “perceptual_type”: “static”, “norm_type”: “forbidden”, “action_type”: “overtake”, “numeric_constraints”: “none” }

User Input

Input Rule: {traffic_rule} Output JSON:

Table 13: Prompt of Semantic Structuring.

System Persona

I aim to combine atomic traffic regulations to form new, more complex composite regulations. I will input { two / three / four / five } such atomic regulations, and your task is to determine whether these { two / three / four / five } input regulations are compatible in terms of both scenario and strategy—that is, whether they can coexist within the same context. The specific detection procedure is as follows: 1. For each traffic regulation, extract the context refers to the situational conditions under which the regulation applies. 2. Examine whether their contexts are mutually exclusive. Two contexts are considered mutually exclusive if the physical scenarios they describe cannot coexist in the same space-time. After the above checks, if the contexts of these { two / three / four / five } regulations are mutually exclusive, output 0; if they are compatible, output 1, along with the reasoning. Example 1 : Input Rule 1: “In foggy conditions, motor vehicles shall reduce their driving speed.” Input Rule 2: “When the road surface is icy, motor vehicles shall reduce their driving speed.” Output: 1. Reasoning: Fog and icy road conditions may occur simultaneously; both describe adverse weather conditions and can coexist. Example 2 : Input Rule 1: “When an on-ramp or branch road has an acceleration lane and traffic signs permit, the ego vehicle may merge into the main road.” Input Rule 2: “When there is a “No Entry” or “No Merging” sign, the ego vehicle is prohibited from merging into the main road.” Input Rule 3: “When the area between the ramp or service road and the main road is marked with a solid line or a hatched/guide line area, the ego vehicle is prohibited from merging into the main road.” Output: 0. Reasoning: These rules cannot be combined because they describe mutually exclusive scenarios. Rule 1 only applies when merging is permitted (acceleration lane present and signs allow), while Rule 2 prohibits merging when “No Entry” or “No Merging” signs are present, and Rule 3 prohibits merging when solid or hatched lines are present. The “permitted” condition of Rule 1 and the “prohibited” conditions of Rules 2 and 3 cannot exist simultaneously in the same place and time (permission and prohibition cannot coexist). Although Rules 2 and 3 can coexist and jointly reinforce the prohibition, Rule 1 conflicts with both, so overall, they cannot logically coexist or be combined. Example 3 : …

User Input

Input Rule 1: {rule_1}

Input Rule 2: {rule_2}

Input Rule 3 (if necessary): {rule_3}

Input Rule 4 (if necessary): {rule_4}

Table 14: Prompt of Rule Coexistence Validation.

System Persona

You are an expert assistant in autonomous driving test scenario generation. You will be given: (1) a textual scenario description derived from traffic rules; (2) a DSL specification that defines the syntax and structure of executable driving scenarios; (3) an example DSL illustrating how rule conditions map to YAML-based scene definitions. Your task is to translate the scenario description into a structured semantic DSL representation. The generated DSL must explicitly encode: 1. Entities: ego vehicle, other vehicles, pedestrians, static obstacles, traffic lights, etc. 2. Spatial Relations: relative positions (ahead of, behind, left of, right of), lane index, distance relations, orientation, and spatial layout. 3. Environment: road type, lane geometry, weather, visibility, time of day. 4. Behavioral Trajectories: initial poses, intended paths, speed profiles, and motion behaviors. 5. Rule Satisfaction: every constraint implied by the traffic rules must appear explicitly in the DSL. Final Requirement: Output only the YAML DSL scenario. Do not output explanations, comments, or any additional text. Example 1 : Input Scenario Description: “The ego vehicle is traveling in the leftmost lane of a three-lane urban road. The navigation system indicates that the vehicle needs to exit at the next intersection 200 meters ahead, which requires the vehicle to be in the rightmost lane. The vehicles in the adjacent lanes are moving at similar speeds.” Input Traffic Rules: Navigation requires lane change toward the rightmost lane before reaching an exit. Output DSL (YAML): environment:

weather: sunny

time: daytime

road_network:

road_type: intersection

road_marker: solid_line

Table 15: Prompt of DSL Translation.

System Persona

You are an expert evaluator in traffic-rule parsing. You will be given (1) the exact prompt used to generate the semantic-structuring output, and (2) the model output produced by that prompt. Your task is to assign a quality score in the range [0, 1] evaluating: 1. Correctness : whether the structured fields reflect the original rule described in the prompt. 2. Completeness : whether all required fields (rule content, perceptual type, norm type, action type, numeric constraints) are present. 3. Fidelity : whether the model output introduces no hallucinations or distortions relative to the prompt. Output only a floating-point score in [0,1] . Do not output explanations or text. The final output format must be: <score>

User Input

Semantic Structuring Prompt

Semantic Structuring Output

Output Score:

Table 16: Quality Scoring Prompt for Semantic Structuring.

System Persona

You are an expert evaluator in multi-rule compatibility reasoning. You will be given (1) the exact prompt used to perform coexistence validation, and (2) the model output generated by that prompt. Your task is to assign a score in [0,1] evaluating: 1. Logical validity : whether the compatibility judgment (0/1) matches the true feasibility implied by the rules. 2. Scenario correctness : whether the reasoning in the output aligns with the real-world spatial and temporal constraints described in the prompt. 3. Fidelity to rules : whether the model correctly interprets the rules without inventing new conditions. Output only a score in [0,1] . No text, no reasoning. <score>

User Input

Coexistence Validation Prompt

Coexistence Validation Output

Output Score:

Table 17: Quality Scoring Prompt for Coexistence Validation.

System Persona

You are an expert evaluator in autonomous driving scenario creation. You will be given (1) the scenario-transcription prompt used to generate a textual driving scene, and (2) the model output produced by that prompt. Your task is to assign a score in [0,1] evaluating: 1. Faithfulness : whether the scene description accurately reflects the traffic rule constraints included in the prompt. 2. Coherence : whether the scene is internally consistent (actors, road type, environment). 3. Relevance : whether the scene directly corresponds to the intended rule semantics without omitting or fabricating conditions. Output only a floating-point score in [0,1] . <score>

User Input

Scenario Transcription Prompt

Scenario Transcription Output

Output Score:

Table 18: Quality Scoring Prompt for Scenario Transcription.

System Persona

You are an expert evaluator for structured scenario representation and DSL authoring. You will be given (1) the DSL-translation prompt used to generate a YAML/DSL scenario, and (2) the model output produced by that prompt. Your task is to assign a score in [0,1] evaluating: 1. Structural correctness : whether the DSL syntax follows the schema implied by the prompt. 2. Semantic alignment : whether entities, relations, road network, and environment accurately reflect the scenario description in the prompt. 3. Executability : whether the DSL can be reliably executed in CARLA without contradictions. Output only a floating-point score in [0,1] . <score>

User Input

DSL Translation Prompt

DSL Translation Output

Output Score:

Table 19: Quality Scoring Prompt for DSL Translation.

System Persona

You are a driver assistant. Your task is to answer the question based on the scenario description and question stem. The scenario description will be provided in the image. Please answer the question based on the scenario description shown in the image and question stem. Please return the answer in the format of ”A”, ”B”, ”C”, or ”D”. And give the reason for your answer.

User Input

Scenario Description: {scenario_description image} Question Stem: {question_stem} Options: {options} Output:

Table 20: Prompt for Testing DriveCombo.

System Persona

You are a driver assistant. Your task is to answer the question based on the scenario description and question stem. Please answer the question based on the scenario description and question stem. Please return the answer in the format of ”A”, ”B”, ”C”, or ”D”. And give the reason for your answer.

User Input

Scenario Description: {scenario_description text} Question Stem: {question_stem} Options: {options} Output:

Table 21: Prompt for Testing DriveCombo-Text variant.

Explore similar work

Jun 1, 2026

GeoDrive-Bench: Benchmarking Region-Specific Multimodal Reasoning in Autonomous Driving

Vision-language models (VLMs) for autonomous driving have shown promising performance, but their ability to handle region-specific traffic rules remains underexplored, raising uncertainties about their deployment across diverse global settings. We therefore introduce GeoDrive-Bench, a novel benchmark that enables the systematic investigation of VLMs' geo-culturally grounded driving reasoning. We curated 5,053 human-validated multiple-choice QA pairs across six countries covering diverse driving cultures. Specifically, we emphasize four driving tasks: perception, prediction, planning, and region reasoning. Each question requires models to infer the correct driving behavior from visual evidence and local traffic conventions without explicit country labels. Beyond evaluation, we further design a distillation algorithm that injects region-specific traffic-rule knowledge into the internal representations of VLMs, enabling models to better align visual scene understanding with local driving policies. Experiments on nine state-of-the-art VLMs show substantial performance variations across geo-driving cultures for each task, while our proposed baseline models exhibit improved geo-cultural reasoning across regions. These results suggest that current VLMs still lack robust region-aware driving intelligence and highlight GeoDrive-Bench as a diagnostic and training-oriented testbed for deployable autonomous driving foundation models.

Yingzi Ma, Chaowei Xiao, Ming Jiang

University of Wisconsin-Madison · Johns Hopkins University

VLM Evaluation Autonomous Driving Benchmarks VLMs for Autonomous Driving Autonomous Driving

Ask PDF

Jul 27, 2026

Reasoning to Regulate: Chain-of-Thought for Traffic Rule Understanding

Understanding and complying with traffic regulations is a safety-critical requirement for autonomous driving, yet remains challenging due to the diversity and context dependence of traffic signage. Importantly, regulation understanding is not a simple recognition task, but a reasoning problem: whether a rule applies depends on interpreting the sign in relation to the spatial layout of lanes and scene context. To support such reasoning, MapDR provide fine-grained annotations that link each traffic sign's regulatory rules to the specific lanes they govern. Existing methods, however, largely treat this as direct sequence prediction, ignoring the underlying reasoning that connects sign semantics and map structure. To address this limitation, we explicitly incorporate reasoning into this task and propose a framework that equips vision-language models (VLMs) with chain-of-thought (CoT) capabilities. We first design a scalable CoT curation pipeline that bootstraps rationales from a strong LLM through a two-round strategy and employs a VLM-based verifier to filter out incorrect cases, yielding a high-quality set of (CoT, answer) pairs. Building on this foundation, we adopt a two-stage training scheme: supervised fine-tuning (SFT) to teach rationale-to-answer generation, followed by GRPO reinforcement learning with answer-grounded, fine-grained rewards to further improve final answer accuracy. Extensive experiments on MapDR show that our approach significantly improves both interpretability and accuracy, establishing the first reasoning-based framework for regulation-aware autonomous driving.

Yueru Luo, Xu Yan, Changqing Zhou +5

Shenzhen-FNii, CUHK-SZ · HKUST(GZ) · Tencent T Lab +1

Autonomous Driving VLM Reasoning

Ask PDF

Feb 25, 2026

MindDriver: Introducing Progressive Multimodal Reasoning for Autonomous Driving

Vision-Language Models (VLM) exhibit strong reasoning capabilities, showing promise for end-to-end autonomous driving systems. Chain-of-Thought (CoT), as VLM's widely used reasoning strategy, is facing critical challenges. Existing textual CoT has a large gap between text semantic space and trajectory physical space. Although the recent approach utilizes future image to replace text as CoT process, it lacks clear planning-oriented objective guidance to generate images with accurate scene evolution. To address these, we innovatively propose MindDriver, a progressive multimodal reasoning framework that enables VLM to imitate human-like progressive thinking for autonomous driving. MindDriver presents semantic understanding, semantic-to-physical space imagination, and physical-space trajectory planning. To achieve aligned reasoning processes in MindDriver, we develop a feedback-guided automatic data annotation pipeline to generate aligned multimodal reasoning training data. Furthermore, we develop a progressive reinforcement fine-tuning method to optimize the alignment through progressive high- level reward-based learning. MindDriver demonstrates superior performance in both nuScences open-loop and Bench2Drive closed-loop evaluation. Codes are available at https://github.com/hotdogcheesewhite/MindDriver.

Lingjun Zhang, Yujian Yuan, Changjie Wu +7

Amap, Alibaba Group · The Hong Kong University of Science and Technology · The Chinese University of Hong Kong +1

VLMs for Autonomous Driving Autonomous Driving Planning End-to-End Autonomous Driving RL for VLMs

Ask PDF