How Autonomous Trucking Companies Are Building Safety Cases for Commercial Deployment

The commercial autonomous trucking industry crossed a threshold in 2024 and 2025 that passenger AV programs have not yet reached at scale: revenue-generating, driverless freight operations on public highways. Aurora launched driverless commercial operations on Texas corridors in April 2024. Kodiak, Torc, and Waabi are each at different stages of the same transition. That threshold changes the nature of safety cases fundamentally. A safety case built to support supervised testing is a different artifact than one built to justify removing the human from the cab entirely.

What distinguishes the autonomous trucking safety challenge from passenger AVs is not primarily the vehicle — it is the operational domain. Long-haul trucking operates in an ODD that is geographically vast, meteorologically variable, structurally heterogeneous, and temporally extended in ways that urban robotaxi operations simply are not. A robotaxi ODD in Phoenix is bounded, mapped in detail, and climatically benign. A freight corridor from Dallas to El Paso crosses weather systems, construction-heavy infrastructure, and road geometry that can change week to week. Building a credible safety case for that environment requires a different approach to scenario libraries, ODD parameterization, and requirement-to-capability mapping than anything the robotaxi sector has had to develop.

The Regulatory Gap That Forces Self-Definition

Aviation has DO-178C for software, DO-254 for hardware, ARP4761 for safety assessment, and a certification authority — the FAA — that reviews and approves. The autonomous trucking industry has none of this. FMCSA regulates commercial motor vehicles but has no established technical standard for autonomous driving systems. The AV-DRIVE Act and various NHTSA voluntary guidance documents create a policy framework, but not a sufficiency standard. State regulations — Texas, Arizona, Arkansas, Ohio — vary in what they require companies to demonstrate before permitting driverless operation.

This regulatory gap is both a freedom and a burden. Companies can define their own sufficiency criteria for safety arguments, which means they can move faster than a prescriptive certification regime would allow. It also means they must convince themselves, and eventually their regulators and customers, that those criteria are the right ones. There is no external authority to audit the logic of the safety case and declare it sound. Aurora’s Safety Case Framework, published publicly, is the clearest example of a company trying to fill that gap with structure: it explicitly addresses the argument pattern, the evidence types, and the conditions under which the company considers the case sufficient to support driverless deployment. But it is Aurora’s definition of sufficiency, not a regulator’s.

Kodiak and Torc have taken different approaches to public disclosure. Waabi, which was still in pre-commercial testing as of mid-2026, has published research on scenario generation and simulation coverage but has not published a structured safety case document comparable to Aurora’s. This variation in transparency makes cross-company comparison difficult and makes industry-level learning slower than it should be.

ODD Parameterization for Long-Haul: The Combinatorial Problem

An ODD is not a geographic boundary. It is a multi-dimensional specification that includes road type, speed range, weather conditions, lighting conditions, traffic density, infrastructure quality, and operational time constraints — among other parameters. For long-haul trucking, parameterizing the ODD honestly creates a combinatorial space that is difficult to state without understating it.

Consider a Dallas-to-El Paso corridor. The road geometry varies from divided urban freeway to two-lane rural connector approaches. Weather includes clear Texas sun, high-crosswind desert conditions, and winter ice events at elevation. Construction zones appear and move on timescales of weeks. Traffic includes mixed commercial and passenger vehicle traffic, oversize load convoys, and agricultural equipment crossings. The truck itself may be operating at maximum gross vehicle weight with a trailer that changes its handling dynamics substantially. A fully enumerated ODD for that corridor, done rigorously, runs to hundreds of parameter combinations.

The industry’s practical response has been to constrain the initial ODD aggressively and expand it incrementally. Aurora’s initial driverless operations were restricted to specific highway segments, daylight hours, and weather windows below defined precipitation thresholds. This is the right engineering decision, but it creates a tension with commercial pressure: customers want freight moved in rain and at night, and competitors will expand their ODDs faster if the safety case does not keep pace.

The harder ODD management challenge is construction zones. A construction zone is not a static feature that can be mapped once and treated as a known condition. It is a dynamic, frequently reconfigured environment with temporary signage, variable lane configurations, reduced shoulders, and human flaggers whose behavior is governed by informal protocol rather than traffic law. Every autonomous trucking program tracks construction zone handling as a capability boundary. The question — how do you know when your system is good enough to include active construction zones in the ODD? — does not have an obvious answer that maps to test miles or simulation hours alone.

How Scenario Libraries Are Being Built

The strongest safety arguments in this sector are built around scenario coverage rather than around aggregate statistics like miles driven or disengagements per mile. Coverage-based arguments start with a structured taxonomy of the scenarios the system can encounter within its ODD, and then demonstrate that the system has been tested — in simulation, closed-course, and public road conditions — against a representative and sufficiently challenging sample of that taxonomy.

Aurora’s approach, as described in their public documentation, uses a hierarchical scenario taxonomy that organizes scenarios by functional category (cut-ins, merges, emergency vehicle responses, construction zone events) and by parameter variation within each category. The scenario library is linked to test execution records and simulation batch results. This structure — taxonomy to test to evidence — is recognizable to anyone who has built a safety case in aviation or defense systems. It is also significantly more rigorous than what most robotaxi programs published at comparable stages.

The weakest version of scenario-based argumentation, which some programs have used, is a count of unique scenario types encountered in naturalistic driving data. Encounter count is not coverage. A system that has encountered 10,000 cut-in events in naturalistic data has not necessarily been tested against the most challenging 5% of that distribution. The distinction between encountered and systematically evaluated against defined challenge criteria is the difference between a data-rich but argumentatively weak safety case and one that would survive engineering scrutiny.

Waabi’s published research on simulation-based scenario generation is notable because it addresses the coverage problem from a different direction: using generative methods to construct challenging scenarios that extend beyond the naturalistic distribution. The argument is that if your system can handle adversarially constructed variants of scenarios in the tail of the distribution, the safety case for the nominal distribution is stronger. This approach has genuine merit, but it introduces its own argument burden — you must demonstrate that your simulation environment is sufficiently realistic that performance in simulation predicts performance in physical operation.

Disengagement Analysis: Lagging Indicator, Leading Indicator

Disengagement reporting — required in California under the CPCN framework, voluntarily published by some programs — is the most public-facing metric in autonomous vehicle safety. It is also, by itself, a weak basis for safety argumentation.

The problem with disengagement rate as a safety metric is that it measures the outcome of a human-in-the-loop system, not the capability of the autonomous system in isolation. A disengagement that occurs because a safety driver intervened preemptively — in a situation the system might have handled correctly — is counted the same as a disengagement that occurs because the system was genuinely at capability boundary. Disaggregating these requires a richer classification scheme than most programs publish.

What disengagement data does well, when properly classified, is generate a near-miss taxonomy. A near-miss taxonomy — a structured record of situations where the system approached a capability boundary without crossing it — is a leading indicator of where the ODD definition needs tightening or where system capability needs to improve. The autonomous trucking programs that are doing this rigorously are classifying every disengagement event against a defined taxonomy of root cause categories, linking those categories to specific ODD parameters, and using the analysis to drive both system development priorities and ODD boundary decisions.

Torc has been relatively transparent about using disengagement analysis as an ODD management input, describing how disengagement trends by road type and weather condition inform their decisions about which ODD expansions to pursue and in what sequence. This is the right use of the data.

Requirements Management: Where the Industry Lags

Comparing autonomous trucking requirements management to aviation is uncomfortable for anyone who has worked in both domains. Aviation safety-critical systems are developed against explicitly traced requirements hierarchies: system requirements derived from safety objectives, subsystem requirements derived from system requirements, software requirements derived from subsystem requirements, with test coverage mapped to requirements at every level. The traceability chain is not optional; it is a certification artifact.

Autonomous trucking programs are not building to that standard, and the honest explanation is partly that the regulatory regime does not require it and partly that the development cadence of machine learning-based systems makes traditional requirements traceability structurally awkward. A neural network perception component does not have requirements in the same sense that a flight control law has requirements. You can specify performance requirements — false positive rate below X, detection range above Y under Z conditions — but the internal logic of the component is not decomposable into traceable sub-requirements.

The better programs have found a middle path: they maintain rigorous requirements traceability for the system architecture and for the non-ML components (planning logic, safety monitors, actuator interfaces), and they substitute structured performance evaluation frameworks for requirements traceability on the ML components. This is pragmatic and probably the right approach given the technology, but it means the overall traceability discipline is weaker than aviation.

Where autonomous trucking programs compare more favorably is in the rigor of their hazard analysis. FMEA-style analysis of the sensor suite, functional HAZOP of the planning system, and interface failure mode analysis are well-established practices in these programs. Aurora’s published safety documentation references STPA (System-Theoretic Process Analysis) — an approach that originated in aerospace and that handles software-intensive systems better than traditional FMEA. STPA’s adoption in autonomous trucking represents a genuine import of aviation-grade methodology.

Tools like Flow Engineering have become relevant in this context because the traceability problem in autonomous trucking is not just about depth — linking requirements to tests — but about breadth: connecting ODD parameters to hazard scenarios to system requirements to capability evidence across a graph that can contain thousands of nodes. Document-based requirements management tools, which most of the industry inherited from their early development phases, do not handle that graph structure well. The programs that are managing this most effectively have moved toward model-based or graph-native approaches that can represent the relationships between ODD conditions, derived hazards, design requirements, and verification evidence as a connected structure rather than a set of linked documents.

Honest Assessment: Where the Industry Stands

The autonomous trucking industry is further along in safety case construction than its public reputation suggests, and less far along than the most optimistic company presentations imply.

The structural progress is real: the leading programs have published explicit safety frameworks, built scenario libraries with systematic taxonomies, and adopted hazard analysis methods that would be recognizable to aerospace safety engineers. They have also made genuinely conservative ODD decisions — restricting initial driverless operations to conditions where the safety case is strongest, rather than claiming competence across the full operational domain from day one.

The gaps are also real. Requirements traceability lacks the rigor of aviation. The absence of a regulator with the technical authority and mandate to review safety cases creates a collective action problem — there is limited incentive for any individual company to invest in safety case rigor beyond what is needed to satisfy customers and state permitting authorities. And the ODD expansion challenge — particularly for construction zones and adverse weather — remains unsolved in the sense that no program has demonstrated a systematic, evidence-backed method for deciding when a new ODD boundary is safe to cross.

The comparison to aviation is ultimately a goal more than a benchmark. Aviation achieved its current safety record over seventy years of operational learning, incident investigation, and iterative standard development. Autonomous trucking is doing something harder — deploying novel systems at scale with no equivalent institutional history — and it is doing it in a decade. The programs that will earn long-term commercial viability are the ones building safety cases rigorous enough to survive the scrutiny that inevitably follows the first serious incident. Building that rigor now, before it is required, is the defining engineering discipline of this industry phase.