{"id":"5b717d00-06b4-4376-b794-96044b8b120f","arxiv_id":"2412.16265","paper_version":3,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"A human-instructed driving layer that uses an LLM with a retrieval-augmented Autoware knowledge base to translate natural language into validated AutoIR configuration commands.","lead":"Autoware.Flex lets a rider give the car a normal-language driving instruction, such as 'ignore the broken traffic light and go,' and turns it into a command the Autoware self-driving software can run. The system only allows commands that pass a set of pre-written safety rules, and the authors show it working in a simulator and on a real prototype car.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Safety claim overreaches: validation rules check only module/node/param plus coarse vehicle state, not dynamic hazards (e.g., oncoming traffic in opposite lane) or the translated parameter value, so accepted instructions can be unsafe.","rationale":"The full text confirms that the load-bearing premise is the Section 4 rule base. The paper's own Section 4.1 states the rule base cannot enumerate all driving scenarios and that it only provides a baseline for unmatched instructions, while the abstract and Section 6.3 make an unqualified 'executes them safely' claim. That mismatch is the central vulnerability: the matched rules are not safety certificates. Table 3's opposite-lane rule checks only coarse state and an obstacle presence, not oncoming traffic; Algorithm 1 activates on the first match and the 10 s override persists, so the check is instantaneous rather than continuous. The additional observation that configAction is not included in validation conditions is also grounded in the paper: Section 6.1 reports 87% ConfigAction accuracy, yet the validation rules in Tables 2 and 3 list no configAction constraints, so a mistranslated parameter value would pass. None of this is an internal inconsistency in the engineering; the translation results are plausible and the real-vehicle demos are a useful existence proof. But the safety claim is significantly broader than the evidence, which is exactly why the reader's CONDITIONAL verdict is appropriate. The AWSIM oncoming-traffic test would settle whether the concern lands in the most direct way possible.","tokens_in":15331,"tokens_out":6531,"duration_ms":59746,"concrete_test":"Re-run the traffic-cone experiment of Section 6.3 in AWSIM with a second vehicle approaching in the opposite lane, and issue 'Use the opposite lane to avoid it.' The Table 3 rule (Motion State: Driving, Speed <5 m/s, Perceptions: Obstacle Detected) will match regardless of the oncoming vehicle, and Algorithm 1 will activate on the first match. If the ego vehicle moves into the oncoming vehicle's path, the 'executes them safely' claim is falsified.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The 'executes them safely' claim in the abstract depends entirely on the Section 4 rule-based validation, but that validation does not certify safety for accepted instructions. A rule consists of a search index (module/node/parameter) plus coarse current-state conditions; it does not check the translated configAction value nor dynamic hazards beyond the ego vehicle's immediate stopping condition. Table 3's opposite-lane rule requires only 'Motion State: Driving, Speed <5 m/s, Perceptions: Obstacle Detected'; it does not require the opposite lane to be clear, even though the instruction sends the vehicle into that lane. The red-light rule similarly requires only Stopped, 0 m/s, and Traffic Light Detected, with no cross-traffic check. Since Algorithm 1 returns Activated on the first condition match and the parameter override persists for the manually set 10 s timer, a vehicle can be committed to crossing an intersection or entering oncoming traffic after a single instantaneous check. The paper itself concedes in Section 4.1 that the rule base reflects typical scenarios and cannot enumerate all situations; that scope limitation directly undercuts the unqualified abstract claim. In addition, Section 6.1 reports only 87% ConfigAction translation accuracy, yet configAction is not part of the validation conditions, so translation errors within a matched rule also pass unchecked. The system is a plausible engineering integration, but the safety conclusion is broader than what the validation mechanism can support.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents Autoware.Flex, an extension of Autoware.Universe that allows users to issue natural-language driving instructions. The system uses an LLM with an ADS-specific knowledge base under a RAG architecture to translate instructions into AutoIR programs, and a rule-based validation component that checks coarse vehicle state before injecting parameter overrides into Autoware. The evaluation reports translation accuracy on a self-authored AutoIR dataset, latency measurements, two simulated scenarios, and three real-world parking-lot experiments. The abstract and Section 6.3 claim that the system effectively interprets human instructions and executes them safely.","tokens_in":15607,"tokens_out":4780,"duration_ms":39388,"significance":"If the central claims held, the paper would make a useful contribution to human-instructed AD systems: it demonstrates an end-to-end pipeline from natural language to validated Autoware parameter changes on a real vehicle, and the RAG-based translation shows a large improvement over using the raw Autoware manual (Table 1). The authors also contribute a 200-item translation dataset, which would be valuable to the community if released. However, the significance is tempered by the limited evidence: the safety argument rests on a small hand-built rule base, the evaluation uses only two simulator scenarios and three real-world qualitative experiments, and the translation ground truth was created by the same team from the same documentation that informed the knowledge base.","major_comments":[{"comment":"The safety validation checks only module, node, parameter, and coarse vehicle state; it does not check the translated configAction value or dynamic hazards. For example, the 'Use the opposite lane' rule in Table 3 requires only Motion State: Driving, Speed: <5 m/s, and Obstacle Detected, with no requirement that the opposite lane be clear; the red-light rule requires only Stopped, 0 m/s, and Traffic Light Detected, with no cross-traffic check. Algorithm 1 returns Activated on the first matching state and the parameter override persists for the manually set 10-second timer, so an accepted instruction can commit the vehicle to crossing an intersection or entering oncoming traffic. This directly undercuts the unqualified 'executes them safely' claim in the abstract. The paper itself concedes in Section 4.1 that the rule base 'reflects typical driving scenarios' and cannot enumerate all situations; this scope limitation should be reflected in the safety claim.","section":"4.1, 4.2, Table 3, Algorithm 1"},{"comment":"The translation accuracy results may overstate generalizability because the ground-truth AutoIR dataset was created by the same authors and from the same Autoware documentation used to build the knowledge base. The evaluation is therefore partly a consistency check between the LLM's output and the authors' own mapping, rather than a measure of whether the mapping is objectively correct. The dataset is not released, and no confidence intervals or per-item breakdowns are reported. A concrete test would be to have independent annotators, blind to the knowledge base, create ground-truth pairs from a different Autoware version or from recorded driving logs. In addition, the 87% ConfigAction accuracy is not reflected in the safety validation, since configAction is not among the rule conditions checked in Algorithm 1.","section":"6.1.1, 3.2.2"},{"comment":"Experimental evidence for the headline claim is thin and entirely positive: only two simulator scenarios (three paraphrases each) and three real-world parking-lot experiments are reported, with no failure cases and no quantitative safety metrics such as distances, speeds, time-to-collision, or lateral clearances. The real-world experiments are described qualitatively (e.g., 'successfully stop approximately three meters'), and the conclusion in Section 6.3 that the results 'strongly demonstrate' safe execution is disproportionate to the evidence. Additional experiments with adversarial instructions, unexpected traffic, and explicit measurement of safety margins are needed to support the general claim.","section":"6.2, 6.3"}],"minor_comments":[{"comment":"Accuracy percentages in Table 1 and the relevance-analysis results are based on 200 items; reporting exact counts and confidence intervals would make the comparisons more informative.","section":"6.1.2"},{"comment":"The speed conditions are written inconsistently as 'Speed: <5 m/s' and 'Speed: = 0 m/s'; please clarify whether 0 m/s means exactly zero or a small threshold.","section":"Tables 2 and 3"},{"comment":"Reference [21] has a typo in the year ('20222'), and the model name is written inconsistently as 'QWenVL' in Section 5 and 'Qwen-VL' in the references; please standardize.","section":"References"},{"comment":"The authors state that a traffic officer is assumed but not visually represented in the simulator; this should be acknowledged as a limitation when interpreting the scenario as validating the traffic-officer use case.","section":"6.2"},{"comment":"The implementation section would benefit from stating whether the knowledge base, dataset, and rule base are publicly available, as this affects reproducibility.","section":"5"}],"recommendation":"major_revision","confidential_remarks":"The paper is best framed as an engineering integration with a modest evaluation, not as a validated safety guarantee. The central idea is publishable if the claims are scaled back to the demonstrated scope, the dataset is released, and the validation rules are strengthened or their limits are made explicit. I would also check whether the venue's standards require more rigorous safety evidence for systems that override an ADS's default behavior."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague, here's my read on Autoware.Flex. The core thing to know: this is a genuine engineering integration—natural language instructions, translated by an LLM with RAG into a small DSL (AutoIR), then gated by a hand-built rule base before being injected into Autoware as ROS 2 parameter overrides. It works in the demonstrations they ran. But the abstract's claim that instructions are \"executed safely\" is broader than what the validation mechanism can actually certify.\n\nWhat's new and what it does well: the AutoIR language, the ADS-specific knowledge base, and the rule-based validation integrated as ROS 2 nodes are all concrete and clearly described. The translation evaluation shows a large, credible improvement over using the raw Autoware manual as the RAG knowledge base: 87% vs 32% overall accuracy. The rollback via a manual timer is a sensible safety mechanism, and the rule-matching overhead is negligible. The real-vehicle experiments, though limited, are real demonstrations, not just simulation.\n\nSoft spots, in proportion: the safety validation is the load-bearing weakness. Each rule checks only coarse state—motion state, speed, and whether some object is detected—not the value of the parameter being set, nor dynamic hazards. The red-light override rule requires only \"Stopped, 0 m/s, Traffic Light Detected\" with no cross-traffic check. The opposite-lane rule requires an obstacle detected but not that the opposite lane is clear. Algorithm 1 activates on the first match and the override persists for 10 seconds, so a translated command can commit the vehicle to a risky maneuver after a single instantaneous check. The paper itself concedes in Sec. 4.1 that the rule base cannot enumerate all scenarios; that honest limitation directly undercuts the unqualified abstract claim. Also, the 87% ConfigAction accuracy is not checked during validation, so translation errors can pass through. The evaluation dataset is small, self-authored, and unreleased, and the ground truth was built from the same Autoware documentation that shaped the knowledge base, so part of the accuracy number measures internal consistency rather than external correctness. That said, the comparison against the Autoware-manual baseline remains meaningful.\n\nWho is this for? Researchers working on human-instructed or preference-aware driving systems, and anyone building LLM-to-ADS translation pipelines. It deserves a serious referee, but the authors should be asked to release artifacts, add confidence intervals, expand the rule base and safety analysis (especially dynamic-hazard checks), and temper the safety claim. I'd engage with it, with revisions expected before acceptance.","headline":"A credible LLM+RAG-to-Autoware integration whose safety claim outruns its rule-based validation; worth refereeing, but the abstract overpromises.","tokens_in":16143,"tokens_out":1961,"would_cite":false,"duration_ms":18922,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Autoware.Flex aims to translate plain-language driver commands into validated parameter changes that a modular self-driving system can execute safely.","keywords":["Autonomous Driving System","human-instructed driving","large language model","retrieval-augmented generation","AutoIR","rule-based validation","Autoware","ROS 2"],"falsifier":"Run the red-light override scenario in the same simulator setup used in the paper, with another vehicle or pedestrian crossing the intersection on the conflicting green phase while the ego vehicle is stopped at a detected red light. If, after the human instruction is accepted, the vehicle moves into the path of the crossing road user because the matched rule does not consider cross traffic, the central claim that instructions are executed safely is false. The same test can be repeated for every rule by finding a state that satisfies the rule's conditions but where execution leads to a collision.","tokens_in":15149,"feed_emoji":"🚗","tokens_out":5740,"duration_ms":46376,"temperature":0.7,"pith_summary":"Autoware.Flex is an attempt to let a human passenger steer an existing modular self-driving system with ordinary language, rather than leaving all decisions to the vehicle. The paper argues that natural-language instructions can be translated into structured AutoIR programs that tell Autoware which module, node, and parameter to change, and that a rule-based checker can decide in real time whether executing the change is safe. The payoff, if the claim holds, is that an ADS can handle special cases it would otherwise get wrong, such as a malfunctioning traffic light, and can honor individual preferences such as cruising in a particular lane. Experiments in simulation and on a prototype vehicle are used to support the claim that the system effectively interprets human instructions and executes them safely.","feed_headline":"Plain-language commands now drive Autoware safely","feed_subtitle":"Natural-language instructions become checked parameter changes that revert automatically, tested on a real vehicle.","key_machinery":"The load-bearing mechanism is the pairing of two languages: AutoIR, a small domain-specific language that encodes a user instruction as a module, node, parameter, configuration value, and lifetime, and the validation rule base, in which each admissible AutoIR program maps to a rule with a search index and safety conditions. The conditions are deliberately limited to three observable vehicle-status groups, namely motion state, speed, and perceptions including detected obstacles and traffic lights, plus a manually set timer that forces rollback to the ADS defaults. The rule base is generated offline from a small set of simulated scenarios, organized in a tree for fast lookup, and checked against the live vehicle status every validation round until the instruction expires; algorithmically, matching a rule takes a negligible fraction of a control cycle.","core_discovery":"The central claim is that a rule-based modular autonomous driving system can accept human driving instructions written in natural language, convert them into parameter changes at selected Autoware nodes, and execute those changes only when a small set of runtime conditions is satisfied. Instruction translation is carried out by an LLM assisted by a compact, ADS-specific knowledge base through retrieval-augmented generation; the output is an AutoIR program specifying module, node, parameter, configuration value, and a timer. Execution is gated by an offline-built rule base: each rule pairs an AutoIR search index with conditions over the vehicle's motion state, speed, and perceived objects, and an instruction is activated only while its rule matches real-time vehicle status. The paper reports that all tested instructions were executed correctly in simulation and in three real-world scenarios, while native Autoware either stopped or failed to follow the requested behavior, and that accepted instructions revert to default settings when their timer expires.","pith_inferences":["An implication the paper leaves implicit is that the safety guarantee is only as strong as the rule base, and the current rules check a narrow slice of the situation; for the red-light override, for example, nothing in the stated rule verifies that cross traffic is absent before the vehicle moves.","The same translation-and-validation architecture could be applied to other modular driving stacks beyond Autoware, by rebuilding the knowledge base and rule base around a different parameter set, though the paper does not claim this.","A natural testable extension is to infer the instruction lifetime from the instruction itself rather than hard-coding ten seconds, which the paper lists as future work.","One could measure how often users issue instructions that are rejected by validation and treat rejection frequency as a signal for expanding the rule base or improving translation accuracy."],"forward_implications":["A user can instruct the vehicle to ignore a malfunctioning red light and proceed, something native Autoware cannot do, with the instruction active only while the vehicle is stopped at $0$ m/s and a traffic light is perceived.","Instructions that do not match a rule, or that are issued when conditions are not met, are ignored, so the rule set defines the envelope of acceptable human override.","Because every validated instruction carries a timer, behavior changes are temporary and the original Autoware parameters are restored automatically, limiting the duration of any override.","The rule-matching overhead is reported small enough, under one millisecond per check, that validation can run inside the normal control loop without noticeable delay.","System designers can incrementally expand the rule base to support additional instructions and scenarios, extending the safe scope over time."],"supporting_citations":[{"why":"The base open-source ADS whose modules and parameters Autoware.Flex reconfigures.","marker":"[21]"},{"why":"The simulator used to test instruction execution and to derive the validation rules.","marker":"[22]"},{"why":"The retrieval-augmented generation technique the translator uses to fetch knowledge-base entries.","marker":"[25]"},{"why":"The large language model that performs relevance analysis and AutoIR generation.","marker":"[5]"},{"why":"The prompting technique used to decide whether an utterance is a driving instruction.","marker":"[41]"},{"why":"The modular open-source ADS architecture that motivates the design of the system.","marker":"[20]"},{"why":"The middleware that connects the Flex nodes and carries the parameter-setting commands.","marker":"[27]"},{"why":"The vector search library used to retrieve relevant knowledge chunks for the LLM.","marker":"[14]"}],"fun_headline_variants":["Tell Autoware how to drive in plain words","Autoware Flex: human commands, auto-revert, real-world tested","Autoware Flex: your instructions, checked and reverted","Natural language controls Autoware with safety checks","Autoware Flex: plain language, safer driving"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole safety argument rests on a hand-built rule base that was derived from a small number of simulated scenarios and checks only motion state, speed, and perceived objects; if that rule base misses a relevant road-user situation, an accepted instruction can be unsafe.","fun_headline_variants_meta":{"raw":{"variants":["Tell Autoware how to drive in plain words","Autoware Flex: human commands, auto-revert, real-world tested","Autoware Flex: your instructions, checked and reverted","Natural language controls Autoware with safety checks","Autoware Flex: plain language, safer driving"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000849,"raw_usage":{"total_tokens":3682,"prompt_tokens":925,"completion_tokens":2757,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":541,"completion_tokens_details":{"reasoning_tokens":2675}},"tokens_in":541,"tokens_out":2757,"duration_ms":20426,"temperature":1.0,"reasoning_tokens":2675,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T11:07:48.669224+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the red-light override scenario in the same simulator setup used in the paper, with another vehicle or pedestrian crossing the intersection on the conflicting green phase while the ego vehicle is stopped at a detected red light. If, after the human instruction is accepted, the vehicle moves into the path of the crossing road user because the matched rule does not consider cross traffic, the central claim that instructions are executed safely is false. The same test can be repeated for every rule by finding a state that satisfies the rule's conditions but where execution leads to a collision.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The base open-source ADS whose modules and parameters Autoware.Flex reconfigures."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The simulator used to test instruction execution and to derive the validation rules."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The modular open-source ADS architecture that motivates the design of the system."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The middleware that connects the Flex nodes and carries the parameter-setting commands."}],"review_version":1}