On November 2, the Autoware Foundation announced Autoware 2.0 with AI and hybrid stacks alongside rule-based modules. Its generator–selector architecture allows multiple trajectory generators and selection of the output to use. This is a software release, not certification of safe autonomous operation on every road.
From a package to a workspace
We examined the public aw-index-cli documentation. It describes composing a .repos file by selecting packages, repositories, tags or a Reference Design. Under schema v4, declared dependencies on other registered packages are included recursively. Unknown names and dependency cycles produce errors rather than silently yielding an empty configuration.
That matters when comparing implementations. Selecting an AI planning module should also make its supporting components visible. Otherwise, a change could affect more than the single library a developer thought was being replaced. This is our engineering interpretation of the mechanism, not a defect discovered in the release.
The check command compares the composed file with the registry and its latest compatibility checks. It does not conduct a road test on a team's behalf. The boundary is useful: a compatible software workspace and dependable vehicle behavior are different outcomes, requiring different evidence.
What the index shows
The public Autoware Index showed ROS Jazzy entries with registered versions, statuses and compatibility histories. Its interface supports selecting components and producing an importable file. These are inspectable records about specific software components. They are not a general certificate for every possible combination, nor proof of sensor or braking performance.
For example, a team comparing two planners for a campus vehicle could preserve the same recorded inputs and acceptance criteria. It could record exact versions and why the selector preferred one output. A difference in behavior could then be traced to a particular decision instead of automatically being attributed to a supposedly smarter model. This is a proposed evaluation method, not a demonstration SIExpo performed.
The announcement's Reference Design combines a deployment profile with a recommended software configuration. The practical question is whether another team can reconstruct the system that was actually evaluated. A project name alone does not identify the parameters, hardware and operating conditions used in an assessment.
The boundary of the announcement
Our editorial reading is that the important change concerns comparing different approaches within a traceable shared environment. It does not remove the need to examine behavior with incomplete inputs, delayed observations or unsuitable trajectories. Those checks must be defined for the actual task and the authorized test environment.
SIExpo read the announcement, registry and documentation, but did not install the stack or operate a vehicle with it. Open components make examination possible; they do not establish the result of that examination in advance.
Editorial verification: 2026-11-02T17:07:21.522703+00:00 (UTC; Europe/Sofia is UTC+02:00).
