SCENIC: Probabilistic Scenario Language

• Scenic is a domain-specific probabilistic programming language that defines scenarios as distributions over scenes and dynamic agent behaviors.
• It uses object-oriented specifiers and declarative constraints to model complex, safety-critical environments for simulation and verification.
• Scenic employs specialized sampling and pruning techniques to generate realistic scenarios that support both 2D and advanced 3D simulation frameworks.

Scenic is a domain-specific probabilistic programming language for specifying scenarios as distributions over scenes and, in later formulations, over the behaviors of their agents over time. It was introduced for the design and analysis of perception systems and cyber-physical systems, especially autonomous driving and robotics, where the central task is not to hand-author a single environment but to define a structured distribution of plausible, constrained, and often safety-critical environments from which concrete scenes can be sampled (Fremont et al., 2018, Fremont et al., 2020). Subsequent work extended Scenic from largely 2D scene generation to 3D environment modeling, dynamic interactive simulation, falsification, reinforcement-learning environment generation, and compositional probabilistic verification (Vin et al., 2023, Viswanadha et al., 2021, Azad et al., 2021, Vin et al., 4 Nov 2025).

1. Probabilistic scenario language

Scenic’s central semantic claim is that a program defines a scenario as a distribution rather than a single deterministic world. In the foundational formulation, a scenario is a distribution over scenes, where a scene is an assignment of values to global parameters and to the properties of all objects in the world. In the dynamic formulation, a scenario also includes the behaviors of agents over time, so that sampling produces not only an initial scene but a concrete executable situation (Fremont et al., 2018, Fremont et al., 2020).

This distinction yields a small but important vocabulary. A scene is a snapshot of the environment at a point in time. An abstract scenario is a probabilistic model over scenes and behaviors. A concrete scenario is one sampled instantiation that can be executed in a simulator. In verification-oriented work, the sampled parameters induced by a Scenic program constitute a semantic feature space that can be searched by external falsification procedures (Viswanadha et al., 2021).

The language was motivated by three recurring problems in machine-learning-based cyber-physical systems: testing under specific operating conditions, training on rare or difficult cases, and debugging failures by generalizing a single counterexample into a family of related scenes. The Scenic papers frame all three as problems of distribution design: the objective is not merely to generate data, but to generate the right distribution of data, with explicit control over geometry, uncertainty, and constraints (Fremont et al., 2018, Fremont et al., 2020).

A common misconception is to treat Scenic as a static scene layout tool. The later language definition is explicitly broader: it describes “scenarios that are distributions over scenes and the behaviors of their agents over time,” which makes Scenic not only a declarative scene generator but also a temporal environment model (Fremont et al., 2020).

2. Objects, specifiers, and declarative constraints

Scenic is object-oriented. Programs are built from classes, object instances, properties, and domain-specific world models. The primitive types include booleans, scalars, vectors, headings, vector fields, and regions. Objects inherit defaults from classes, and those defaults may themselves depend on other properties; for example, a Car can default to a random point on the road and a heading aligned with the local road direction (Fremont et al., 2018, Fremont et al., 2020).

Its most distinctive language mechanism is specifier-based object construction. Instead of a monolithic constructor, Scenic lets object descriptions be assembled from composable phrases such as at, offset by, left of, right of, ahead of, behind, facing, toward, away from, visible, following, and relative to. The semantics is dependency-aware: Scenic resolves the properties implied by specifiers, adds defaults where necessary, constructs a dependency graph, and evaluates specifiers in topological order. If multiple non-optional specifiers assign the same property, or if dependencies cycle, the scenario is ill-formed (Fremont et al., 2018, Fremont et al., 2020).

The geometric operators are formalized explicitly. Representative definitions include

$V_1 \text{ offset by } V_2 = V_1 + V_2,$

$$V_1 \text{ offset along } H \text{ by } V_2 = V_1 + \text{rotate}(V_2, H),$$

and the visibility predicate

$$P \text{ can see } O \iff \text{visibleRegion}(P)\cap \text{boundingBox}(O)\neq\emptyset.$$

For an OrientedPoint, the visible region is a sector parameterized by viewDistance, heading, and viewAngle; for a Point, it is a disc (Fremont et al., 2018).

Uncertainty is attached directly to expressions and properties. The language includes built-in distributions such as Uniform, Discrete, Normal, and, in the later definition, TruncatedNormal, together with resample(D) for an independent draw from a distribution. Because later expressions can depend on earlier sampled values, Scenic supports structured correlations rather than only independent randomization (Fremont et al., 2020).

Constraints are declarative. A hard requirement,

require B

filters out any execution for which $B$ is false. A soft requirement, $$V_1 \text{ offset along } H \text{ by } V_2 = V_1 + \text{rotate}(V_2, H),$$0 is enforced as a hard requirement with probability $p$ and ignored otherwise, guaranteeing that $B$ holds with probability at least $p$ in the induced distribution. Scenic also provides default hard constraints: objects must lie within the workspace, objects must not intersect, and objects must be visible from the ego object unless visibility is disabled (Fremont et al., 2018, Fremont et al., 2020).

3. Dynamic scenarios, behaviors, and temporal structure

The dynamic extension of Scenic lifts the language from static scene generation to interactive simulation. Objects may have behaviors, which are coroutine-like programs issuing actions over time. At each simulation step, Scenic advances all behaviors, sends their actions to the simulator, receives the updated world state, and continues until termination (Fremont et al., 2020).

A key mechanism is try/interrupt, which supports prioritized, context-sensitive behavior. The default behavior runs in the try block; when an interrupt condition becomes true, the default behavior pauses, the interrupt behavior executes, and control can then resume. This makes layered policies concise: lane following can be augmented with obstacle avoidance, braking, or emergency maneuvers without rewriting the base behavior (Azad et al., 2021, Fremont et al., 2020).

Scenic also supports require always, require eventually, monitors, preconditions, invariants, and scenario composition. Scenarios can be composed in parallel or sequence, can invoke sub-scenarios opportunistically, and can terminate via explicit temporal conditions. In later falsification work, simulator connections are described as bidirectional, so that Scenic behaviors can react to the evolving state of the simulation rather than only to the initial scene (Viswanadha et al., 2021, Viswanadha et al., 2021).

This dynamic formulation is what made Scenic useful as the front end for verification loops. In the VerifAI integration, a Scenic program defines a distribution over semantic feature vectors—semantic attributes such as position, orientation, velocity, color, and model for all objects and agents—and these vectors become the search space for falsification. Scenic thus supplies the structured, semantic environment model, while the falsifier supplies the search strategy over that model (Viswanadha et al., 2021).

4. Sampling, pruning, and the transition to Scenic 3.0

Although Scenic is a probabilistic programming language, its implementation has emphasized domain-specific sampling rather than generic inference. The foundational system uses rejection sampling together with geometric pruning. If an object must lie inside a region $C$, the sampler can restrict its center to an eroded region such as

$R \cap \operatorname{erode}(C,\text{minRadius}),$

thereby avoiding samples that would inevitably violate containment. Similar pruning rules are defined for orientation constraints, minimum-width constraints, and reachability constraints (Fremont et al., 2018, Fremont et al., 2020).

The initial language was largely 2D and relied on box-based geometry. Scenic 3.0 was introduced specifically to remove these limitations. It adds native 3D syntax with yaw, pitch, roll, and parentOrientation; distinguishes facing toward from facing directly toward; introduces base points and topSurface for more accurate object placement; and generalizes objects from bounding boxes to explicit shape properties, including MeshShape (Vin et al., 2023).

The 3D revision also introduces modifying specifiers and a priority system, so that multiple spatial constraints can contribute to the same property without collapsing into ambiguity. The paper’s examples show below and on cooperating: one specifier establishes a relative position, and another projects that position onto a surface. This is intended to make common 3D constructions—such as placing a chair below an object but on the floor—expressible without manual geometric repair (Vin et al., 2023).

Visibility was likewise overhauled. Scenic 2 used a simple bounding-box visibility heuristic that ignored occlusion. Scenic 3 replaces this with a ray tracing-based visibility system that accounts for occlusion, supports complex 3D shapes, and can model standard camera frusta as well as wrap-around sensor regions such as those of LiDAR. Temporal expressiveness was also extended from require always and require eventually to arbitrary LTL formulas under RV-LTL semantics, and the parser was rewritten from a formal PEG grammar using Pegen (Vin et al., 2023).

These changes were motivated by concrete failure cases of the earlier language: a robot vacuum under a table, a chair tucked beneath furniture, and driving scenes in which occlusion must be modeled accurately. The Scenic 3.0 paper also notes that exact mesh operations can be expensive, and reports heuristics yielding 10x–1000x speedups in scene sampling (Vin et al., 2023).

5. Verification, simulation, and environment generation

Scenic has been used extensively as a scenario layer for simulation-based verification. In the IEEE AV Test Challenge work, Scenic encoded NHTSA-style driving situations for Apollo 6.0 in LG SVL, while VerifAI searched the resulting semantic feature space for counterexamples. The framework monitored metrics including distance, time-to-collision, made progress, and lane violation, and reported failures such as Apollo getting stuck at stop signs, ignoring pedestrians, and colliding in vehicle-following scenarios (Viswanadha et al., 2021).

A later integration extended Scenic and VerifAI in two directions. First, it enabled full support for Scenic’s dynamic features and interactive behaviors through bidirectional simulator connections. Second, it parallelized the falsification pipeline using Ray, instantiating multiple simulator instances and multiple server connections. Using 5 worker processes, the paper reports up to about 5× speedup and more typically 3–5× speedup in the number of completed simulations in a fixed time. The same work introduced multi-objective falsification using rulebooks, and on a four-way-intersection benchmark reported falsifying 4 of 5 objectives in serial and all 5 objectives in parallel under two ordered rulebooks, compared with weaker results under no preference ordering (Viswanadha et al., 2021).

Scenic has also been used to test learned behavior prediction. A scenario-based platform for CARLA evaluated LaneGCN using a library of 25 Scenic programs covering highways, intersections, roundabouts, bypassing, merging, unprotected left turns, and near-collision behavior. On the paper’s parallel benchmark for one scenario, average speedups were 1.51× with 2 workers and 3.09× with 5 workers; the reported scenario diversity remained around 0.53 ± 0.08 while harder scenarios produced higher counterexample rates (Indaheng et al., 2021).

Beyond falsification, Scenic has served as an environment-generation front end for other simulators. GzScenic bridges Scenic to Gazebo by generating Scenic models from Gazebo models, invoking Scenic to sample a concrete scene, and then translating the result into Gazebo .world and model files. The paper emphasizes that GzScenic inherits Scenic’s then-current 2D restriction, but reports that among the 283 models packaged with Gazebo, only 12 used unsupported collision geometries (Afzal et al., 2021). Scenic4RL performs a comparable role for Google Research Football, where Scenic programs define MDP initial-state distributions, non-RL agent behaviors, rewards, and termination conditions. The released package is described as containing 32 scenarios and 5 stochastic policies, though the wrapper imposes a measured 2.99× slowdown relative to native GRF on a 20K-timestep benchmark (Azad et al., 2021).

Taken together, these papers establish Scenic as a reusable environment-modeling layer rather than a simulator in its own right: Scenic specifies and samples the world model, while CARLA, LG SVL, Gazebo, Webots, or GRF execute the resulting concrete scenario (Viswanadha et al., 2021, Afzal et al., 2021).

6. Program synthesis, verification layers, and other uses of the name

Scenic has increasingly become a target language for automated scenario synthesis. ScenarioNL converts autonomous-vehicle crash reports into Scenic programs through a multi-step pipeline involving OCR, Tree-of-Thought object identification, uncertainty estimation, constrained Scenic code generation with LMQL, retrieval, compiler feedback, and CARLA simulation. On its reported evaluation, ScenarioNL achieved 90 syntactically correct outputs, compared with lower correctness for direct prompting baselines, and obtained Accuracy 4.1, Relevance 4.5, Expressiveness 4.2, and ARE 4.3, at an inference time of 109.860 seconds per program (Elmaaroufi et al., 2024). The work’s principal conclusion is that ordinary prompting is insufficient for a low-resource DSL such as Scenic, and that compiler-guided decomposition is necessary.

A related 2026 pipeline inserts an Extended Scenic DSL between multimodal crash-report interpretation and executable Scenic rendering. Using GPT-4o mini on 100 sampled NHTSA CIREN cases, the paper reports 99% overall accuracy across DSL subcomponents, including 100% for environment, 100% for road network, 98% for oracle, and 97% for actors. It then renders the validated DSL into Scenic with topology-aware templates and executes the results in CARLA with Autoware, reporting 2,000 randomized instantiations per scenario that consistently triggered intended violations such as opposite-lane crossing and red-light running (Safa et al., 24 Feb 2026).

Scenic has also become the substrate for higher-level probabilistic verification. ScenicProver builds on Scenic to support compositional system descriptions, assume-guarantee contracts in LTLf modulo theories with arbitrary Scenic expressions, testing-based evidence, Lean 4 proofs, imported assumptions, and assurance-case generation. In its automatic emergency braking case study, the paper reports 94.59% correctness with 99.8% confidence under the compositional method, versus 91.55% correctness for naive monolithic testing with the same budget, and states that ScenicProver can produce a stronger result in 15 minutes than naive monolithic testing can provide in 8 hours (Vin et al., 4 Nov 2025).

The name SCENIC is also used by several unrelated systems and should not be conflated with the probabilistic scenario language. In machine learning infrastructure, Scenic is an open-source JAX library from Google for computer vision research and beyond, organized around reusable dataset_lib, model_lib, train_lib, and common_lib components and a BaseModel abstraction built on JAX and Flax (Dehghani et al., 2021). In human motion synthesis, SCENIC denotes Scene-aware Semantic Navigation with Instruction-guided Control, a diffusion model for scene-adaptive, text-controlled human motion that reports Penetration 1.57 cm, Contact distance 4.51 cm, Position 1.38 cm, Rotation 0.0376 rad, FID 1.680, and 75.6% user preference (Zhang et al., 2024). In human-computer interaction, SCENIC is a location-based system for children during car rides, evaluated with 7 families and 10 children, and reporting a post-study recall increase from 0.9 to 3.9 with p < .001 (Chen et al., 23 Aug 2025). In datacenter systems, SCENIC stands for Stream Computation-Enhanced SmartNIC, an open-source SmartNIC implementing a 200G datapath with offloaded TCP/IP and RDMA, direct GPU and SSD access, and use cases such as network-to-GPU hash-based partitioning with a reported 6.7× latency improvement over a CPU baseline (Ramhorst et al., 16 Apr 2026).

The resulting terminological landscape is therefore bifurcated. In cyber-physical systems, robotics, simulation, and falsification, Scenic denotes a probabilistic scenario language and its surrounding toolchain. In several other subfields, SCENIC is simply a reused system name.