What is the difference between text-based scenario descriptions and domain-specific simulation code in autonomous vehicle testing?

Why the Difference Matters in Testing

In autonomous vehicle testing, the difference between a scenario description and simulation code is the difference between expressing a safety intent and executing a test. Text-based scenarios are useful for reviewing whether the intended driving story is complete, but they leave room for interpretation. Simulation code removes that ambiguity by binding the scenario to concrete parameters, actors, timing, sensor assumptions, and expected outcomes inside the test harness.

This matters because safety validation depends on repeatability. A natural-language scenario can be shared quickly across engineering, safety, and product teams, but it is not enough to prove that two runs are equivalent or that a regression test will behave the same way after a simulator update. Code is what makes the test machine-executable, versionable, and auditable. That also means the quality of the code becomes part of the safety argument, not just the quality of the written scenario.

Practitioners often discover that a scenario looked clear in review, yet produced inconsistent results once different engineers interpreted the same words differently.

How It Works in Practice

A text-based scenario description usually captures the driving intent at a high level: where the ego vehicle is, what other actors are present, what hazard should emerge, and what a safe system response should look like. It is the planning artefact. It helps teams agree on coverage, discuss edge cases, and trace the reason a test exists. It is especially useful early in test design, when the team is still deciding what to validate and how strict the expected behaviour should be.

Domain-specific simulation code takes that description and turns it into something a simulator can execute without ambiguity. That typically means defining coordinates, lane geometry, actor trajectories, object speeds, trigger conditions, weather or visibility settings, sensor inputs, and pass or fail assertions. The executable form makes it possible to run the same case repeatedly, vary one parameter at a time, and generate comparable evidence across releases.

• Text scenarios answer, "What should happen?"
• Simulation code answers, "What exactly will the simulator do?"
• Text is easier to review; code is easier to automate.
• Text can be broader; code must be precise enough to run.

In practice, strong testing programmes keep both layers because they serve different audiences. Product and safety reviewers need the readable intent, while simulation engineers need executable detail. When the same scenario is reused across multiple simulators or test stacks, the code layer also becomes the place where environment-specific assumptions are encoded and controlled. That makes traceability important: the written scenario should clearly map to the executable artefact so reviewers can see what was preserved, simplified, or approximated.

These controls tend to break down when teams treat the description as if it were already a test case, because the simulator still needs unambiguous logic before it can produce trustworthy results.

Common Variations and Edge Cases

Tighter simulation fidelity often increases authoring effort, so teams have to balance readability against executable precision. In early concept validation, a looser text scenario may be enough to align stakeholders, while later-stage safety testing usually needs much stricter code-level definitions.

The main edge cases appear when the scenario is partly symbolic or partially parameterised. For example, a scenario may describe "heavy traffic" or "low visibility" in prose, but the simulator still needs thresholds or distributions to reproduce those conditions. Another common variation is scenario reuse across tools: the same plain-language intent may be mapped into different simulator languages, each with its own syntax, supported objects, and fidelity limits. Best practice is evolving here, because there is no universal standard for how much semantic detail must be preserved between description and executable model.

Teams also need to distinguish between coverage and realism. A clean scenario catalogue can look comprehensive while still failing to encode the precise conditions that matter for hazard detection or fallback behaviour. Conversely, overfitting every case into complex simulation code can make the library harder to maintain and harder to audit.

For that reason, the right answer is usually not to choose one format over the other, but to use text for shared intent and code for test execution, with a clear trace from one to the other.

Practitioner Guidance

What to prioritise: Preserve the link between the human-readable scenario and the executable simulation artefact. If that trace is weak, reviewers may approve a scenario that the simulator cannot reproduce faithfully, or miss a mismatch between intent and implementation.

What to verify: Check that the simulation code fixes the details that prose leaves open, especially actor timing, speed, placement, environmental conditions, and pass or fail criteria. If two engineers can implement the same text differently, the scenario is still too ambiguous for reliable automated testing.

What good looks like: The written scenario is concise enough for safety and product review, while the simulation code is deterministic enough for regression testing and comparable results across versions. The best programmes treat the prose as the contract and the code as the executable proof.

Practitioner takeaway: Use text to align on intent, but use simulation code to earn trust in the result, because automated safety testing fails when the story is clear but the executable model is not.

Related resources from NHI Mgmt Group

• What is the difference between synthetic data generation and simulation based testing for AI agents?
• What is the difference between a code assistant and an autonomous code factory?
• What is the difference between task-based and autonomous AI agent identity risk?
• What is the difference between context-aware assistance and autonomous code execution?