PaperlayerView exact revision on arXiv

Source-linked AI summary

AutoAgent0: An Agentic Runtime for Safe Closed-Loop Driving

Jiageng Liu, Seth Z. Zhao, Zewei Zhou, Alejandro Huerta, Aidan Bayer-Calvert, Yuxin Bao, Haotian Lin, Robert Spataru, Zijun Cui, Yining Hong, Bolei Zhou, Jiaqi Ma

arXiv:2610.18866v1cs.RO

TL;DR

Long-tail interactions and accumulated errors challenge safe closed-loop driving, and nominal policies may struggle to recover from off-nominal states. AUTOAGENT0 adds scene refinement, rule-based verification, and feedback-refined recovery to existing experts; evaluations report improved robustness across driving experts and benchmarks.

  • Problem

    Long-tail interactions and accumulated execution errors challenge closed-loop safety, while nominal policies may fail to recover from off-nominal states.

    Source: §1 · p. 2, §3.1 · p. 3

  • Method

    AUTOAGENT0 augments existing driving policies with independent scene-context refinement, rule-based trajectory verification, and recovery maneuvers refined using verifier feedback.

    Source: §1 · p. 2

  • Results

    AUTOAGENT0 improves closed-loop robustness over single-expert execution on Fail2Drive and NavSafe-∞, with gains across experts and benchmarks.

    Source: §1 · p. 2, §5 · p. 10

  • Takeaways & Limitations

    Results suggest runtime supervision can complement advances in underlying policies and improve closed-loop driving without retraining them.

    Source: §5 · p. 10

    Verification and recovery remain constrained by scene-estimation accuracy and recovery-primitive coverage; NavSafe-∞ task-success gains accompany lower comfort and driving efficiency.

    Source: §5 · p. 10

Abstract

from arXiv · show

Safe autonomous driving requires more than accurate planning at a single frame: it demands reliable closed-loop execution in dynamic environments. Although end-to-end driving policies have advanced rapidly, the accumulated closed-loop errors, especially in unseen scenarios, can push vehicles into states from which the same policy struggles to recover. We address the challenge by treating closed-loop driving safety as a test-time execution problem. We introduce AutoAgent0, an agentic runtime and harness framework that augments existing driving experts with complementary detection skills, rule-based action verification, and feedback-driven recovery. To address inaccurate scene perception, an independent detection module constructs scene context using complementary perception skills, and a rule-based verifier checks proposed trajectories against this context before execution. When the nominal trajectories are unreliable, the orchestrator of the runtime activates Recovery Planning, where an agentic loop constructs alternative action proposals from action primitives and iteratively refines them using verification feedback. This design combines independent scene assessment with feasibility checks and online recovery, addressing both perception errors and the limited recovery capabilities of individual experts. Evaluations on Fail2Drive and NavSafe-$\infty$ demonstrate improved closed-loop robustness over single-expert execution in long-tail and safety-critical scenarios. These results demonstrate that runtime supervision can improve closed-loop robustness across multiple driving experts without retraining the underlying policies.

1 INTRODUCTION

Long-tail scenarios and compounding closed-loop errors challenge safe driving, raising whether safety should rely solely on a stronger expert or also use test-time supervision. AUTOAGENT0 adds scene assessment, rule-based verification, and recovery, with reported robustness gains over single-expert execution.

Motivation

  • Long-tail events and compounding decision errors make safe closed-loop driving difficult, while single experts may generalize poorly and fail to recover from their own deviations.The introduction frames explicit runtime supervision at test time as an alternative to relying solely on increasingly capable expert policies.Source: §1 · p. 2
  • Agentic driving runtimes can coordinate complementary skills, inspect execution, verify proposed actions, and initiate recovery when an expert cannot maintain safe progress.This motivates combining VLM reasoning with existing experts rather than relying on one expert in every situation.Source: §1 · p. 2

Approach

  • AUTOAGENT0 combines independent scene-context detection, rule-based action-feasibility checks, and recovery maneuvers iteratively refined with verifier feedback.Recovery Planning activates when the nominal trajectory is deemed unreliable and constructs alternatives from action primitives.Source: §1 · p. 2

Evaluation

  • Evaluations on Fail2Drive and NavSafe-∞ report improved closed-loop robustness over single-expert execution in long-tail scenarios.The runtime augments existing policies with detection, verification, and feedback-driven recovery.Source: §1 · p. 2

2 RELATED WORK

Related work spans closed-loop driving policies, runtime monitoring, and agentic harnesses. AUTOAGENT0 applies runtime supervision to long-tail failures without retraining the expert, combining refined scene evidence with feedback-guided recovery.

Closed-Loop Autonomous Driving

  • Prior driving work ranges from structured, multimodal, and diffusion planners to VLA and world-model policies, while AUTOAGENT0 addresses long-tail failures at runtime without retraining the expert.BridgeSim studies the open-loop to closed-loop gap; Fail2Drive reports degradation on matched long-tail routes.Source: §2 · p. 3

Closed-Loop Runtime Monitoring

  • Runtime-monitoring approaches use safety rules or predictive filters, while AUTOAGENT0 combines scene-evidence refinement with parameterized recovery around a frozen expert.Its scene refinement updates verifier inputs, and recovery proposals use verifier and execution feedback.Source: §2 · p. 3

Agentic Runtime Harnesses

  • Agentic harnesses coordinate tools and revise decisions using feedback; AUTOAGENT0 applies these mechanisms to driving recovery, with a rule-based verifier controlling which proposals reach the controller.The cited work spans reasoning-and-action interfaces, programmable execution harnesses, and embodied systems that refine skills from execution feedback.Source: §2 · p. 3

3 AUTOAGENT0: A RUNTIME HARNESS FOR CLOSED-LOOP DRIVING

AUTOAGENT0 surrounds a nominal driving policy with scene refinement, proposal verification, and recovery planning. Its recovery loop generates parameterized maneuvers and revises them using verifier feedback when nominal proposals are not admitted.

3.1 PROBLEM SETTING AND CLOSED-LOOP RUNTIME FORMULATION

  • Closed-loop driving is formulated as a route-conditioned POMDP in which a nominal planner proposes finite-horizon trajectories from observation history and route instructions.The objective is reaching the instructed goal while maintaining safe execution throughout interaction.Source: §3.1 · p. 3
  • Nominal policies may miss safety-critical actors or fail to progress from off-nominal states, motivating scene refinement and recovery when rejecting proposals alone is insufficient.The runtime verifies nominal proposals and invokes recovery when no nominal proposal is admitted.Source: §3.1 · pp. 3–4

3.2 AUTOAGENT0 RUNTIME

  • The runtime harness coordinates scene refinement, trajectory verification, and recovery, using VLM reasoning for semantic assessment and recovery decisions.The agent implements the runtime operator using scene-refinement skills, parameterized recovery primitives, and a rule-based verifier.Source: §3.2 · p. 4
  • Perception skills refine scene context by checking camera and LiDAR discrepancies and validating relevant objects and conditions, while a rule-based verifier applies trajectory scores and execution guards.The verifier returns admission decisions and feedback for nominal and recovery trajectories.Source: §3.2 · pp. 4–5

3.3 RECOVERY PLANNING VIA AGENTIC PARAMETER SEARCH

  • Parameterized primitives generate maneuvers such as braking, lateral bypass, and reverse, adapting trajectories to local geometry and route requirements.Their parameters include lateral displacement, target speed, and execution duration.Source: §3.3 · p. 5
  • Recovery alternates primitive selection, trajectory generation, and verifier checks, using rejection feedback to revise parameters or choose another maneuver.VLM reasoning is reserved for cases where no nominal proposal is admitted; recovery generalization is bounded by primitive-library coverage.Source: §3.3 · p. 5

4 EXPERIMENTS

Experiments test whether AUTOAGENT0 improves frozen driving experts across closed-loop benchmarks, and how its runtime components and alternative runtime designs affect safety and progress. Results show broad gains over standalone experts, with remaining trade-offs in recovery and comfort.

4.1 EXPERIMENTAL PROTOCOL

  • Experiments evaluate runtime robustness without retraining the driving expert, using Fail2Drive for long-tail scenarios and NavSafe-∞ for safety-critical events.The protocol uses SparseDriveV2 by default, BridgeDrive for detection, and Opus 5 for semantic supervision and recovery selection.Source: §4.1 · pp. 5–6

4.2 MAIN RESULTS (RQ1)

  • AUTOAGENT0 improves DS, SR, and HM for UniAD, SparseDriveV2, and BridgeDrive on both Fail2Drive splits, and improves task success and capability scores across experts on NavSafe-∞.Fail2Drive gains are larger on generalization routes; on NavSafe-∞, augmented experts surpass DrivoR and GTRS-Dense–V2-99 in DS and SR, at lower comfort.Source: §4.2 · p. 6, Table 1 · p. 7, Table 2 · p. 7
  • Scenario-wise gains depend on failure type: scene context refinement addresses missed pedestrians and animals, while recovery planning yields the largest gains in Behavior scenarios.In Visual–Lateral scenarios, avoided collisions can end in stops when no admissible bypass fits the tight geometry; NavSafe-∞ gains are largest in Traffic Incidents.Source: §4.2 · pp. 6–7, Figure 4 · p. 8

4.3 COMPONENT ANALYSIS AND ABLATION STUDIES (RQ2)

  • Cumulative ablations show that verification reduces collisions but slightly lowers task success, while context refinement improves safety and success and recovery planning further raises success and reduces trigger frequency.Ground-truth context yields further gains, indicating perception remains a bottleneck; moving past blockages increases collision events relative to braking.Source: §4.3 · pp. 7–8, Table 3 · p. 8
  • Across tested VLM backbones, all outperform the no-recovery variant, but Qwen has lower task success and more collisions than Opus and Astra.The passage attributes the gap mainly to scene understanding and error correction; Opus and Astra use failure feedback to revise interpretations and act more conservatively under uncertainty.Source: §4.3 · p. 8
  • Recovery-mechanism ablations find that scene-informed VLM maneuver selection and verifier-guided revision outperform primitive access alone and budget-matched retries, but improved completion does not necessarily mean safer execution.Parameter selection alone offers limited further gains, and verifier-guided refinement has a higher collision rate than retries.Source: §4.3 · p. 8, Table 4 · p. 9

4.4 COMPARISON WITH ALTERNATIVE RUNTIME METHODS (RQ3)

  • AUTOAGENT0 achieves the highest DS and SR on both alternative-runtime evaluation splits, while longitudinal MPC stalls after braking and AUTOAGENT0 completes a checked bypass.Adding the primitive library improves both DS and SR for the AESOP adaptation; the qualitative rollouts use different configurations from the runtime-monitor evaluation.Source: §4.4 · pp. 9–10, Table 5 · p. 9, Figure 5 · p. 10

5 CONCLUSION

The conclusion presents runtime supervision as a complement to advances in driving policies, while noting constraints on scene estimation, recovery-primitive coverage, and recovery quality. The appendix then organizes further evidence around recovery mechanisms, VLM backbones, runtime monitors, and scenario-level behavior.

5 CONCLUSION

  • Runtime supervision improves safety across multiple E2E policies and benchmarks, complementing rather than replacing advances in the underlying policy.The conclusion compares AUTOAGENT0 with evaluated runtime monitors and highlights scene context and execution feedback as valuable for recovery.Source: §5 · p. 10
  • Verification and recovery remain constrained by scene-estimation accuracy and available recovery-primitive coverage.The conclusion also notes room to improve recovery quality because NavSafe-∞ task-success gains accompany reduced comfort and driving efficiency; recovery decisions incur second-level VLM latency.Source: §5 · p. 10

AUTOAGENT0 APPENDIX

  • The appendix covers recovery behavior and performance, computational cost and latency, runtime architecture, and experimental configurations.It assigns scene-context refinement, recovery planning, and rule-based verification to Appendices C–E, with protocols in Appendix F.Source: AUTOAGENT0 APPENDIX · p. 17

A ADDITIONAL RESULTS AND MECHANISM ANALYSIS

  • The additional analysis asks how recovery ablations and VLM backbones affect decisions, how runtime monitors compare, and where gains and limitations occur.It provides ablation configurations, execution traces, backbone comparisons, and scenario-level analyses.Source: A ADDITIONAL RESULTS AND MECHANISM… · p. 17

A.1 RECOVERY ABLATION CONFIGURATIONS

  • The ablations distinguish conservative braking, constrained random or VLM primitive selection, parameter search, and retries with or without verifier feedback.Controlled fallback uses braking without primitive-based recovery; parameterized recovery searches a selected primitive’s parameters, while feedback-guided refinement excludes rejected primitive families within a three-call budget.Source: §A.1 · p. 17

A.2 RECOVERY TRACES AND FAILURE CASES

Recovery traces show that changing actions alone may not fix a mistaken scene interpretation; successful recovery can instead involve revising the interpretation, creating better conditions, or choosing a cautious response. The monitor comparisons distinguish detecting a hazard from enforcing a safe response.

A.2 RECOVERY TRACES AND FAILURE CASES

  • Qwen3.5-9B’s repeated action changes end in collision and timeout at 72.9% route completion, while Opus 5 and GPT-6 Astra complete the displayed route without collisions.Qwen misinterprets vehicle motion, bypass direction, and drivable area; Opus reverses before retrying a right bypass, while Astra waits before selecting a bypass.Source: §A.2 · p. 17, Figure 6 · p. 18
  • Opus 5’s unsuccessful bypass attempts are followed by reversing and retrying the right bypass, making the vehicle’s intermediate position part of recovery.The sequence completes without collisions despite the reverse reducing immediate progress.Source: §A.2 · p. 18
  • Astra’s initial wait keeps the vehicle distant from the blockage while it reassesses; waiting only helps if the model later switches to another maneuver.Remaining stopped without reassessing can time out, while closing distance under a mistaken interpretation can expose the vehicle to collision.Source: §A.2 · p. 18

A.3 QUALITATIVE COMPARISON WITH TRADITIONAL RUNTIME MONITORS

  • In the animal encounter, AUTOAGENT0 holds a stop, whereas RSS braking loses arbitration and the other monitors do not intervene at the shown step.The comparison distinguishes detecting a conflict from ensuring that the correction governs execution.Source: §A.3 · p. 18, Figure 7 · p. 19
  • For the pedestrian encounter, AUTOAGENT0 rejects a trajectory and brakes; uncertainty monitoring fails to sustain its warning, while RSS and MPC also complete without collisions.No alternative path is needed in this case; AUTOAGENT0 can reject forward motion independently of uncertainty in the expert’s candidate scores.Source: §A.3 · p. 19, Figure 7 · p. 19

A.4 VLM BACKBONE COMPARISON

Backbone choice changes task completion and execution quality, and route success alone can conceal differences captured by driving score. Recovery success is a local measure, so it does not establish that the full route was rescued.

A.4 VLM BACKBONE COMPARISON

  • Opus 5 versus Qwen3.5-9B increases DS by 1.7 points and SR by 2.9 percentage points, while Col. falls from 0.210 to 0.145; Astra further raises DS by 2.6 points and lowers Col. to 0.125 while matching Opus’s 83.4% SR.Astra has the highest DS, but Opus 5 is the default backbone to keep ablations and comparisons directly comparable.Source: §A.4 · pp. 19–20
  • Because SR records binary route outcomes while DS incorporates completion and infraction penalties, equal SR can conceal differences in execution quality.The paper uses Opus 5 as the default backbone despite Astra’s higher DS.Source: §A.4 · p. 20
  • Astra raises Rec.-SR from Opus 5’s 67.4% to 71.0% without increasing aggregate route success, because a recovered episode may still be followed by route failure.Recovery events end after a sustained return to nominal driving, whereas route success requires completing the remaining task; the backbones may also encounter different recovery-event populations.Source: §A.4 · p. 20

A.5 SCENARIO BREAKDOWN AND GENERALIZATION

Scenario-level results show stronger gains where behavioral adaptation is needed, alongside remaining weaker groups and conditions outside demonstrated recovery capabilities. Split-level comparisons also show larger gains on generalization routes than on in-distribution routes for the listed policies.

A.5 SCENARIO BREAKDOWN AND GENERALIZATION

  • In Behavior scenarios, DS increases by 19.8 points and SR by 40.0 percentage points, the largest SR improvement among the groups.Visual–Longitudinal scenarios gain 17.0 DS points and 23.3 SR percentage points.Source: §A.5 · p. 20
  • Visual–Lateral remains the lowest-performing group despite DS and SR increases of 13.6 points and 18.0 percentage points; Robustness gains 4.3 DS points with unchanged aggregate SR.The results do not show increased successful routes in every group, and some conditions remain outside demonstrated recovery capabilities.Source: §A.5 · pp. 20–21
  • The construction blockage example calls for a verified bypass, whereas the road-image wall example calls for stopping and resuming after clearance.The standalone expert stalls at 47.9% completion in the construction case and collides in the road-image wall case.Source: §A.5 · p. 21
  • For UniAD, SparseDriveV2, and BridgeDrive, DS gains are larger on generalization than in-distribution routes: 25.2 vs. 20.9, 16.3 vs. 10.7, and 3.8 vs. 0.1 points, respectively.BridgeDrive’s generalization SR rises from 75.0% to 85.3% while its already high in-distribution performance changes little.Source: §A.5 · p. 21

B.1 MODULE-LEVEL LATENCY

The appendix profiles module latency, invocation frequency, and route-level runtime cost. Recovery search is infrequent, while adding AUTOAGENT0 increases wall-clock time per route and reduces simulated time in the measured setup.

B.1 MODULE-LEVEL LATENCY

  • Local module median latencies are 397.4 ms for nominal planning, 303.9 ms for perception inference, 78.6 ms for batch verification, and 468.6 ms for recovery search.Single-candidate verification takes 12.0 ms and the tracking controller 3.3 ms; total runtime cost also depends on invocation frequency.Source: §B.1 · p. 21, §B.2 · p. 22

B.2 INVOCATION FREQUENCY AND WAITING BEHAVIOR

  • Recovery temporal search is invoked 68 times across 11 of 12 routes, or approximately 0.56 calls per 100 control steps, far less often than nominal planning or perception inference.Nominal planning and batch verification each run 9,227 times; perception inference runs 3,017 times across 12,049 retained steps.Source: §B.2 · p. 22
  • The 60 completed recovery VLM calls in the full traces are distinct from the standalone replay requests; those traces also contain 17 stop-sign checks and seven semantic-takeover checks.The standalone replay measured 20 saved recovery contexts per model, and its scope excluded stop-sign and semantic-takeover checks.Source: §B.2 · p. 22, §B.1 · p. 22
  • Synchronous recovery requests pause the Fail2Drive simulator, so the reported safety gains do not demonstrate protection during an equivalent real-world reasoning delay.Deployment would require explicit handling of stale observations and pending decisions, plus independently running low-level safety control.Source: §B.2 · p. 23

B.3 ROUTE-LEVEL EFFICIENCY

  • AUTOAGENT0 raises median wall-clock time per route from 9.88 to 11.44 min (+15.7%) and reduces median simulated time from 44.4 to 38.9 s (−12.5%).The comparison uses the same 200 Fail2Drive routes; 19 baseline routes were truncated at 180 s of simulated time.Source: §B.3 · p. 23
  • AUTOAGENT0 is slower in wall-clock time on 132 of 200 routes, but finishes in less simulated time on 148 routes; nine routes tie at the 180 s limit.The median per-route wall-clock ratio is 1.17×; the pooled wall-clock time per simulated second is 16.61 s versus 14.85 s (+11.8%).Source: §B.3 · p. 23

C RUNTIME ARCHITECTURE AND SCENE CONTEXT REFINEMENT

The runtime updates scene context and execution feedback, verifies nominal proposals, and invokes bounded recovery search when all are rejected. It commits verified maneuvers under execution guards and falls back to braking when no trajectory is available.

C.1 RUNTIME CONTROL FLOW

  • At each decision, the runtime checks nominal proposals first and invokes bounded recovery search only if all are rejected; it commits a recovery proposal only after verification.If no trajectory is available, it applies conservative braking.Source: §C.1 · p. 24

C.2 SCENE CONTEXT REFINEMENT

  • The detector pipeline refines eligible object boxes with LiDAR and radar evidence; sensor disagreements identify candidates for inspection, not confirmed false detections.Invalid LiDAR evidence is not treated as evidence that an object is absent.Source: §C.2 · p. 25
  • Optional semantic review tracks disagreement candidates over observations and accepts a keep or drop correction only when confidence, recency, and active-track consistency conditions hold.Uncertain, malformed, or expired responses introduce no correction; accepted object lists supply obstacle evidence for subsequent verification.Source: §C.2 · p. 25

D.1 PRIMITIVE LIBRARY AND TRAJECTORY GENERATION

  • The action library contains 15 primitives whose deterministic trajectory generators use bounded parameters; available actions and ranges can depend on runtime configuration and scene.For example, swerve actions are excluded below 1 m/s; the VLM selects a primitive while the runtime generates and verifies trajectories.Source: §D.1 · p. 25

D.2 PARAMETER SEARCH AND VERIFIER-GUIDED REFINEMENT

  • Recovery search samples parameters for the selected primitive, verifies candidate trajectories, and returns rejection feedback for another selection within a bounded budget.If no candidate passes, the runtime falls back to conservative braking.Source: §D.2 · p. 25

D.3 VLM PROMPTS AND INVOCATION PROTOCOL

  • The VLM receives camera observations, route and scene context, available primitives, and prior verifier feedback to select a recovery maneuver; the runtime validates responses and handles trajectory generation.Only supplied primitive IDs are allowed, and invalid responses or exhausted invocation budgets trigger fallback.Source: §D.3 · p. 27

D.4 EXECUTION, INTERRUPTION, AND FALLBACK

  • Committed recovery trajectories are anchored in the world frame and advanced under maneuver-specific safety guards; detected hazards or stalled maneuvers can interrupt execution and trigger braking or replanning.Nominal control resumes after a maneuver only when a nominal proposal is admitted; the braking fallback lacks the same admission assurance as a verified candidate.Source: §D.4 · p. 28

E. RULE-BASED VERIFIER

  • The verifier combines collision and pedestrian-TTC gates, tiered drivable-area compliance, and soft TTC, progress, and lane-keeping terms in a PDMS-based score.Admission requires PDMS ≥ 0.43 by default; endpoint-only drivable-area and lane-keeping checks do not establish compliance at intermediate positions or continuous safety over execution.Source: §E.1 · pp. 28–29, §E.2 · p. 29

E.3 VERIFIER THRESHOLD SENSITIVITY

On 34 Fail2Drive routes, the tested threshold of 0.43 has the highest DS and SR among six values. Lower thresholds increase collisions, while stricter thresholds reduce collisions but increase timeouts.

E.3 VERIFIER THRESHOLD SENSITIVITY

  • At θ = 0.43, DS and SR are highest among the six tested thresholds; reducing θ to 0.01 raises collisions per route from 0.059 to 0.176.Increasing θ to 0.60 or 0.84 reduces collisions but raises timeouts from 2 to 8 or 12, respectively; these results support 0.43 on this subset, not its optimality elsewhere.Source: §E.3 · pp. 29–30, Table 11 · p. 30
  • Stricter admission does not monotonically improve task completion: fewer collisions can coincide with more stalled routes.The sweep uses one Base/Generalization route pair from each of 17 scenario families, with the full runtime and a 180 s simulation cap.Source: §E.3 · p. 30, Table 11 · p. 30

F.1 MODELS, SENSORS, AND HARDWARE

  • The evaluated SparseDriveV2 sensor-based configuration uses BridgeDrive detections, with perception inference every four control ticks and a maximum detection age of 1.0 s.The driving expert, detector, and configuration settings are specific to the sensor-based evaluation setup.Source: §F.1 · pp. 30–31

F.2 FAIL2DRIVE SETUP AND METRICS

This section describes the Fail2Drive route setup and metrics, alongside NavSafe-∞ evaluation conventions. Fail2Drive scores capture completion and infractions, while binary success metrics expose categorical failures.

F.2 FAIL2DRIVE SETUP AND METRICS

  • Fail2Drive contains 100 paired routes across 17 unseen long-tail scenario types, and the main result evaluates all 200 routes with a paired generalization gap.Each pair matches an in-distribution base route with a shifted route while holding start, goal, route geometry, and non-target factors matched.Source: §F.2 · pp. 31–32
  • The primary Fail2Drive driving score is route completion multiplied by infraction penalty; route success requires no disallowed infraction, and the 180 s cap makes incomplete routes scenario timeouts.The reported metrics also include collision events per route and the harmonic mean of DS and SR.Source: §F.2 · p. 32
  • NavSafe-∞ metrics average rollouts within each valid specification, then average equally across specifications retaining at least one valid rollout.The metric set includes driving efficiency, comfort, and capability-specific scores.Source: §F.3 · p. 33
  • Fail2Drive success rate gives no partial credit, exposing categorical failures that driving score can average away.Ability scores inherit the same binary criterion, so progress, efficiency, comfort, and partial penalties cannot raise them.Source: §F.3 · p. 33

F.4 ALTERNATIVE RUNTIME IMPLEMENTATION DETAILS

F.4 specifies the shared evaluation setup and alternative runtime implementations. F.5 defines recovery-event success and the driving-score gap used in evaluation.

F.4 ALTERNATIVE RUNTIME IMPLEMENTATION DETAILS

  • All conditions use the same frozen SparseDriveV2 checkpoint and adapted BridgeDrive detector; corrective proposals replace nominal trajectories only after verification and higher PDMS score.The checkpoint runs at 20 Hz; detections arrive every four control ticks, with a 0.35 score threshold and a maximum age of 1 s.Source: §F.4 · p. 33
  • Evaluation compares 80 In-Distribution/Generalization route pairs across all 17 Fail2Drive scenario families, excluding 40 calibration routes; valid driving failures remain included.All methods use the same routes and seed, with one rollout per route; infrastructure-interrupted attempts are reviewed but not counted as completed evaluations.Source: §F.4 · pp. 34–35
  • RSS proposes bounded braking for unsafe separation, MPC optimizes longitudinal acceleration under clearance and speed constraints, and the uncertainty monitor triggers deceleration or stopping from a heuristic score.The uncertainty score is not a calibrated failure probability.Source: §F.4 · p. 34
  • 2D MPC jointly optimizes steering and acceleration; AESOP uses anomaly-triggered branch MPC, while its primitive variant tracks a library primitive without AUTOAGENT0’s parameter search or verifier-guided revision.The AESOP adaptation uses finite-horizon stop regions and does not establish invariant-set safety guarantees; the primitive variant’s optimizer may modify or reject its reference.Source: §F.4 · p. 34
  • The driving-score gap is DS_ID − DS_Gen; a smaller gap can also result from worse in-distribution performance.The gap is computed from unrounded means and expressed in score points.Source: §F.4 · pp. 34–35

F.5 RECOVERY METRICS AND STATISTICAL AGGREGATION

  • Recovery success requires a verifier-admitted action followed by five seconds of verifier-approved nominal driving without renewed recovery; unknown outcomes are excluded from Rec.-SR.Routes without recovery and events without a verifier-admitted action are excluded; Rec.-SR measures sustained return to nominal planning, not independently certified geometric completion or collision-free recovery.Source: §F.5 · p. 35

Related papers

Loading 2610.18866v1…