
01
A better model was not the whole problem
In this fictional engagement, Harbor Mobility was preparing a supervised shuttle pilot across two urban routes. The perception model performed well on a curated dataset, but the engineering team could not connect that result to the situations a vehicle would encounter on a wet evening, at a busy crossing, or during a construction diversion.
The initial backlog mixed ordinary software defects with safety-relevant observations. Reviewers relied on clips selected by individual engineers, so repeated failures were easy to miss. We framed the work around an operational design domain: the specific routes, conditions, speeds, and supervision arrangements in which the pilot would be evaluated.
02
Build a scenario inventory before expanding the pilot
The first workstream organized recorded journeys into conditions rather than folders. Each scenario carried route context, lighting, weather, object visibility, and the expected behavior. Rare situations were deliberately retained in the evaluation set instead of disappearing into aggregate averages.
A separate regression suite replayed the same cases after every model or planning change. Simulation supplemented recorded evidence, but it did not replace controlled physical testing. A simulator can expose failures in a known model of the world; it cannot establish that every assumption about the real world is correct.
- Define the pilot boundaries and explicit conditions that require a safe stop.
- Version datasets, labels, evaluation code, and model artifacts together.
- Route safety-relevant observations to reviewers with named ownership.
- Keep physical verification and human supervision separate from ordinary release automation.
03
Connect engineering changes to release decisions
We introduced a release review with three distinct questions: did the change improve the intended behavior, did it regress another scenario, and is there enough evidence to operate within the pilot boundaries? A higher average detection score did not automatically answer any of those questions.
Reviewers received a compact evidence pack: the change description, affected scenarios, evaluation results, unresolved exceptions, and the rollback procedure. A model remained eligible for investigation without being eligible for deployment. That distinction gave engineers room to experiment without widening the pilot prematurely.
04
Illustrative results from a 12-week program
The invented figures below describe what the scenario team measured. They compare the same evaluation workflow before and after tooling changes; they are not a public-road safety certification or a real customer report.
| Workflow measure | Scenario baseline | Scenario outcome |
|---|---|---|
| Review time for a regression batch | 2.5 working days | 0.8 working days |
| Recorded cases with complete context | 61% | 96% |
| Manual preparation of release evidence | 9 hours per release | 3 hours per release |
| Pilot operating scope | Two supervised routes | Unchanged |
05
What an engineering leader can take away
Treat evaluation as a product with users, interfaces, and ownership. The work is valuable even when a pilot does not expand, because it makes uncertainty visible and shortens the path from an observation to a reproducible engineering task.
For China-based teams working with global partners, this also requires clear data-location decisions and a shared vocabulary for scenario review. Route recordings, vehicle identifiers, and location traces should not be copied between environments casually. A well-structured evidence workflow makes collaboration possible without assuming that every team can access every dataset.