Autonomous vehicle data triage helps AV teams expand into new cities by identifying geographic coverage gaps, prioritizing safety-critical and underrepresented scenarios, and routing them to annotation, simulation, validation, mapping, or engineering workflows. A territory gap matrix and ranked scenario queue turn unfamiliar local conditions into measurable, actionable deployment-readiness decisions.
Autonomous vehicle (AV) companies are increasingly testing and deploying their driving systems across unfamiliar cities. For instance, Zoox expanded its testing footprint to 10 U.S. markets, selecting Dallas and Phoenix for conditions that differ from those in dense metros like San Francisco, such as extreme heat, dust, high-speed roads, complex road networks, and distinct weather patterns.
Similarly, Wayve’s AI-500 Roadshow tested a single driving model across 506 cities, 219 (43%) of which had no prior local data and another 67% with limited training coverage.
Such expansions create coverage challenges that do not arise in the same way when scaling within familiar cities.
While existing models may already have strong coverage of common road elements and driving interactions, their distribution can change greatly across territories. New markets bring unfamiliar intersection geometries, signal placements, local yielding behavior, weather, or infrastructure.
So, the first question for AV data teams stepping into new territories is not how much local data to collect and label, but which differences expose meaningful gaps in model coverage.
Geographic autonomous vehicle data triage answers that question. It turns differences in new territories into measurable coverage gaps, defines and identifies representative scenarios, and routes them to training, validation, simulation, mapping, or engineering investigation.
This article will explain how geographic coverage gaps become prioritized scenarios, actionable triage decisions, and measurable readiness for deployment in a new operational domain.
Why New Operational Design Domain Creates a Coverage Problem Before a Data Collection Problem
Geographic expansion creates a mismatch between where the autonomous driving system (ADS) is expected to operate and the conditions its existing data and validation already support. ISO 34503 defines an operational design domain (ODD) as the static and dynamic operating conditions within which an ADS is designed to function. ASAM OpenODD 1.0 makes the expansion problem more explicit by distinguishing the ODD from the target operational domain (TOD): the conditions expected in the deployment area. A TOD can contain conditions outside the ADS’s defined ODD.
For a new territory, the question is whether the target-domain conditions fall inside, near the boundary of, or beyond the evidence already supporting the system’s ODD. The following types of coverage gaps can emerge:
- Attribute gaps: Conditions with little or no existing evidence, such as a region-specific traffic control or extreme environmental condition.
- Range gaps: Familiar attributes appearing outside validated ranges, such as higher traffic density, temperature, rainfall intensity, or operating speed.
- Combination gaps: Individually familiar conditions occurring together in an underrepresented scenario, such as heavy rain + faded markings + night or a multilane roundabout + cyclists + aggressive merging.
ASAM OpenODD models these operating conditions through structured taxonomy attributes and explicit inclusion and exclusion conditions. It also supports comparing the current operational domain (COD) against the ODD boundary. This makes coverage a condition-level problem rather than a question of whether the system has previously collected data in that city.
Collecting local mileage without identifying these gaps upfront can increase dataset volume without increasing useful ODD coverage. Common intersections, clear-weather driving, and already-represented interactions can dominate the incoming data while low-frequency or boundary conditions remain poorly represented.
Build a Territory Gap Matrix Before Deciding What Gets Labeled
Once attribute, range, and combination gaps are identified, they need to be converted into scenario definitions that the data pipeline can search, measure, and route. A territory gap matrix records each scenario’s existing evidence, expected local exposure, affected autonomy function, evidence gap, and required action.
For each gap, map the relevant scenario attributes against the evidence already available across training, validation, simulation, and regression datasets. Useful dimensions include road topology, traffic control type, actor mix, interaction patterns, weather, illumination, traffic density, sensor quality, and localization context.
Next, profile the target territory using high-definition (HD) maps, route reconnaissance, unlabeled pilot logs, local traffic knowledge, infrastructure inventories, and early supervised drives. Use these sources to characterize the conditions associated with each identified gap and estimate local exposure.
For example, detecting a traffic sign with a different design is primarily a perception issue.
Encountering a familiar road configuration where local drivers follow different yielding patterns may instead create prediction or planning uncertainty. A new construction configuration may require map updates, perception labels, simulation, or all three.
A working gap matrix looks like this:
| Scenario | Existing coverage | Local exposure | Affected function | Initial action |
|---|---|---|---|---|
| Multilane roundabout + cyclists | Low | High | Prediction and planning | Collect + evaluate |
| Extreme heat + highway operation | Limited | High | Sensor and system validation | Test + validate |
| New sign design | Low | Medium | Perception | Annotate |
| Familiar intersection + normal traffic | High | High | Perception, prediction and planning | Sample only |
| Temporary construction + lane shift | Low | High | Perception, map, planning | Annotate + simulate |
The output is a city-specific scenario taxonomy that gives the AV data pipeline explicit targets for querying incoming logs, grouping related events, measuring accumulated evidence, and routing scenarios downstream.
If your expansion program is already generating local pilot data but the team cannot consistently convert it into scenario definitions, evidence gaps, and downstream actions, iMerit’s triage services support event classification, scenario tagging, data selection, root cause analysis, sensor data review, and workflow routing.
How Autonomous Vehicle Data Triage Turns Geographic Gaps Into a Scenario-Priority Queue
Once the territory gap matrix defines the scenarios and their evidence gaps, autonomous vehicle data triage ranks them by operational priority. The objective is to determine which gaps need action before deployment, which can be addressed as local evidence grows, and which are already sufficiently covered.
Priority is assigned using the following signals:
- Coverage gap: How well is the scenario represented in current training, validation, simulation, and regression datasets?
- Local prevalence: How often is the scenario expected in the new territory?
- Safety criticality: What is the consequence if perception, prediction, localization, or planning fails?
- ODD boundary exposure: Does the scenario introduce an unsupported attribute, exceed a validated range, or combine conditions with limited existing evidence?
- Model evidence: Do pilot drives show uncertainty, interventions, trajectory errors, localization issues, or repeated failures?
- Expected learning value: Will additional data, annotation, testing, or simulation close a known capability gap?
Each scenario is scored against these signals and assigned a priority tier based on its combined coverage, exposure, safety, and model-performance profile. This aligns with ISO 34505:2025, which describes scenario evaluation using factors such as frequency, criticality, complexity, operational-domain coverage, and test priority.
| Priority tier | Typical criteria | Routing |
|---|---|---|
| Launch-critical | High local exposure + weak coverage + high safety impact | Immediate collection, annotation, validation, or engineering review |
| High-value adaptation | Geographic coverage gap + measurable model weakness | Targeted annotation, simulation, or model evaluation |
| Coverage-building | Limited representation but no current performance failure | Add selectively to training and regression datasets |
| Low priority | Strong existing coverage + stable model performance | Sample, defer, or exclude |
The queue changes as more local evidence arrives. Early priorities rely on ODD boundary exposure, existing coverage, expected local prevalence, and safety criticality. As supervised and autonomous testing generates local evidence, interventions, model uncertainty, planning errors, localization failures, and regression results move scenarios up or down the queue.
Each queued scenario then receives a defined next action. Perception gaps move to annotation. Localization gaps trigger HD-map review. Rare but safety-critical interactions move into simulation. Cross-stack failures move to engineering investigation.
The final output is a ranked, routable scenario queue that shows what to address first, what evidence is still missing, and which downstream workflow owns the next action.
How iMerit Supports City-Specific Triage for New Operational Domains
A city-specific triage program needs to identify which incoming scenarios matter, prioritize them by training and safety value, and route them to the right downstream action. iMerit brings scenario-based prioritization, domain-expert review, structured escalation, and multi-sensor validation into that workflow.
City-specific scenario taxonomy development.
Local road structures, signage, traffic behavior, environmental conditions, and road-user interactions can be organized into consistent scenario definitions for triage. iMerit also supports HD-mapping workflows around road rules, traffic signs, road conditions, semantic mapping, and issue triage for re-drives or map updates.Scenario-based prioritization.
Candidate data is reviewed against the territory gap matrix so rare, safety-relevant, or weakly represented scenarios are surfaced before expensive annotation begins.Geographically informed expert review.
iMerit provides a domain-specialized autonomous mobility workforce trained across road rules, GIS and mapping, semantic segmentation, LiDAR, and project-specific requirements.Expert escalation.
iMerit’s tiered triage framework separates operational, technical, and engineering triage. High-volume intake and validation can remain at Tier 1. Perception, localization, and scenario-level anomalies move into technical investigation, and complex disengagements or system-level failures move to engineering analysis.Multi-sensor consistency.
High-priority geographic scenarios combine camera, LiDAR, radar, map, and vehicle context. iMerit supports synchronized multi-sensor annotation and validation for perception, localization, mapping, and trajectory-related workflows.
Conclusion
Expanding an AV program into a new territory creates a coverage problem. Teams first need to identify which ODD attributes and scenario combinations differ from the environments their models already understand. A strong autonomous vehicle data triage program should produce a territory gap matrix, a ranked scenario queue, explicit downstream routing decisions, measurable coverage targets, and a feedback loop that updates priorities as local evidence accumulates. Scenario mining and annotation then become targeted tools inside the program rather than default destinations for every new-city log.
Planning expansion into a new operational domain? Talk to iMerit’s autonomous mobility experts to build a city-specific triage workflow that prioritizes the scenarios your models need most.
