---
title: 'SCENIC: Probabilistic Scenario Language'
url: https://www.emergentmind.com/topics/scenic
type: topic
---

# SCENIC: Probabilistic Scenario Language

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 [1809.09310] [2010.06580]. 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 [2307.03325] [2107.04164] [2106.10365] [2511.02164].

## 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 [1809.09310] [2010.06580].

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 [2108.13796].

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 [1809.09310] [2010.06580].

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 [2010.06580].

## 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 [1809.09310] [2010.06580].

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 [1809.09310] [2010.06580].

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 [1809.09310].

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 [2010.06580].

Constraints are declarative. A hard requirement,
```scenic
require B
```
filters out any execution for which \(B\) is false. A soft requirement,
```scenic
require[p] B
```
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 [1809.09310] [2010.06580].

## 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 [2010.06580].

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 [2106.10365] [2010.06580].

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 [2107.04164] [2108.13796].

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 [2107.04164].

## 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 [1809.09310] [2010.06580].

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` [2307.03325].

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 [2307.03325].

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 [2307.03325].

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 [2307.03325].

## 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 [2108.13796].

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 [2107.04164].

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 [2110.14870].

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 [2104.08625]. **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 [2106.10365].

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 [2108.13796] [2104.08625].

## 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 [2405.03709]. 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 [2602.20644].

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** [2511.02164].

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 [2110.11403]. 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 [2412.15664]. 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** [2508.17058]. 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 [2604.15128].

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.

Source: https://www.emergentmind.com/topics/scenic