Pkl Language for Operational Design Domains

• Pkl Language is a configuration-as-code medium that formally specifies ODDs using explicit grammar, typing judgments, and operational semantics.
• It integrates modularity, immutability, and serialization to support versioned, machine-checked, and traceable ODD specifications in CI pipelines.
• The language enforces constraints and provides export facilities to ensure automated validation and seamless integration into safety-critical workflows.

Pkl is a configuration-as-code language used in the formalization of Operational Design Domains (ODDs), where it serves as a typed, constraint-driven medium for specifying the intended context of automated functions that operate without direct human supervision. In the formulation presented in "Formalizing Operational Design Domains with the Pkl Language" (Skoglund et al., 2 Sep 2025), Pkl is not treated merely as a serialization syntax, but as a language with explicit grammar, typing judgments, operational semantics, and validation behavior. Its role is to support rigorous, machine-checked ODD specifications while preserving abstraction, templating, consistency, traceability, and integration into development, validation, and assessment workflows.

1. Conceptual role in ODD formalization

The paper situates Pkl in the safety evaluation of automated functions deployed in real-world environments. In that setting, a developer must justify that a function is free from unreasonable risk when operated in its intended context, and the intended context is commonly captured by an ODD. The central problem is that ODD formalization must remain flexible enough to accommodate diverse specification formats while also preserving consistency, traceability, and seamless integration into development and assessment processes (Skoglund et al., 2 Sep 2025).

Within that framing, Pkl is presented as a configuration-as-code language for formal ODD specification. Its contribution lies in combining declarative structure with validation and tooling support. This allows ODD definitions to be represented as plain-text modules that can be versioned, validated, serialized, and connected to downstream automation. A plausible implication is that Pkl functions as an intermediate formal layer between informal safety intent and executable validation infrastructure.

The paper’s evaluation criteria make this role explicit. Pkl is described as fully satisfying CC1–CC3, namely abstraction, templating, and validation, while largely satisfying SC1–SC3, namely integrity, readability, and traceability. It is also described as supporting IC1–IC2, namely taxonomy integration and test execution enrichment. This positions Pkl as a general-purpose configuration language capable of meeting core ODD formalization requirements without requiring a bespoke ODD-specific language.

2. Formal syntax, typing, and semantics

The paper gives a simplified formalization of Pkl using BNF, type judgments, and an operational semantics sketch (Skoglund et al., 2 Sep 2025). The abstract syntax is organized around modules, imports, and declarations:

• Module ::= "@ModuleInfo" "{" Meta* "}" "module" ModuleName Import* Declaration*
• Declaration ::= ConstDecl | TypeAlias | ClassDecl | InstanceDecl
• ConstDecl ::= "const" id "=" Expr
• TypeAlias ::= "typealias" id "=" TypeExpr
• ClassDecl ::= "class" id "{" FieldDecl* "}"
• InstanceDecl ::= id ":" QualifiedType "=" "new" "{" Assignment* "}"
• FieldDecl ::= id ":" TypeExpr (Constraint)? ("=" Expr)?

This grammar expresses Pkl as a modular typed language in which configuration data are structured as classes and instantiated through new { ... }. Type expressions include identifiers, primitive forms such as Float and Boolean, and disjunctive forms used for enumerations.

The typing relation is written as $\Gamma \vdash e : \tau$. The paper provides selected rules. Under (T-Float), a real number $n \in \mathbb{R}$ has type Float. Under (T-Enum), if $\tau \equiv l_1 | \dots | l_k$ and $v \in \{l_1,\dots,l_k\}$, then $\Gamma \vdash v : \tau$. Under (T-Field), an object literal is well typed if each field value has the declared field type and satisfies any attached constraint. The paper also gives the specific constraint interpretation for isBetween(a,b), where $C(v)$ holds iff $a \le v \le b$.

The operational semantics are summarized through an evaluator $E$ that runs in a sandbox. Evaluating a module together with its imports and instances yields either a fully resolved, immutable object graph or a type-constraint violation error. On success, the object graph can be serialized to JSON, YAML, and other formats. On failure, the evaluator reports the first violated constraint together with a location back-pointer. This treatment gives Pkl a semantics centered on deterministic resolution and early rejection of invalid configurations.

3. Core constructs and validation facilities

Pkl’s core language features are presented as mechanisms directly relevant to ODD specification (Skoglund et al., 2 Sep 2025). Modules and imports divide an ODD definition into reusable pieces such as scenery, environment, and dynamic elements. A module also declares a minimum Pkl version, which enables toolchain alignment.

Classes define record-like structures whose fields may have default values. The paper expresses this as class C { f₁:τ₁=default₁; … }. Instantiation through new { ... } therefore requires overriding only those fields that do not have defaults. This allows template-like reuse while keeping instance specifications concise.

Enumerations and type aliases provide restricted symbolic domains. The example typealias Direction = "right" | "left" is characterized as yielding an algebraic datatype for travel direction. In the ODD context, such definitions constrain allowable values for semantically important categorical attributes.

Validation is driven jointly by typing rules and user-supplied constraints. The formal constraint rule is given as:

$$\frac{\Gamma \vdash e : \tau \qquad C(e)=\text{true}}{\Gamma \vdash e : \tau\{C\}}$$

The example Float(isBetween(0, limit)) is valid only if $\Gamma \vdash v : \text{Float}$ and $n \in \mathbb{R}$0; otherwise evaluation fails with the error "Type constraint violated." Violation reporting includes the file and line of the constraint and the offending value. The paper’s description that these checks are enforced at “compile time,” that is, configuration-validation time, indicates that the language is intended to surface domain violations before downstream deployment or assessment steps.

The language also includes collections: Listings as ordered lists and Mappings as key-indexed structures. These are used to group probabilistic or scenario entries. This suggests that Pkl’s formalism is intended not only for scalar parameterization but also for structured scenario sets.

4. Integrity, immutability, and serialization behavior

A notable property emphasized in the paper is immutability: once a value is bound, it cannot be mutated (Skoglund et al., 2 Sep 2025). In the ODD setting, this is presented as preserving integrity. The significance is practical as well as formal. Immutable configuration objects reduce the risk that operational assumptions are altered implicitly after validation, and they support the paper’s claim that integrity-related criteria are largely satisfied.

Serialization is equally central. Successful evaluation produces a resolved object graph that can be exported to JSON, YAML, and related formats. The paper presents this as an enabling mechanism for downstream test-case generators and scenario managers. In effect, Pkl serves as the authoritative source specification, while exports provide interoperability with external tooling.

The paper also notes graphical export via PlantUML. That feature is used to preserve human readability for safety-case reviews. This matters because ODDs occupy a dual role: they must be machine-readable and automatically validated, but they must also remain inspectable in assurance contexts. The combination of formal validation, immutable resolution, and export facilities therefore underwrites the paper’s argument that Pkl balances configuration simplicity with the expressiveness needed for safety-critical domains.

A common misconception in configuration practice is to equate machine-readable structure with sufficient formal rigor. The paper’s presentation argues against that equivalence by stressing typing, constraints, and explicit evaluator behavior, rather than serialization alone. This suggests that, in the ODD domain, a JSON or YAML file without a comparable validation model would not provide the same assurance properties.

5. Integration into development, validation, and assessment workflows

The paper places substantial emphasis on Pkl’s integration into automation-centric workflows (Skoglund et al., 2 Sep 2025). Because Pkl modules are plain text, they integrate with Git and other software configuration management systems. Changes to ODD parameters are visible in diffs, and rationale and approval can be recorded alongside those changes. This is presented as part of the traceability story rather than as a mere convenience.

For DevOps and toolchain automation, the command-line tool pkl eval can run in CI pipelines to reject invalid ODD changes. Export to JSON or YAML then feeds downstream test-case generators or scenario managers. This creates a workflow in which ODD changes can be validated as part of routine continuous integration and then propagated automatically into test infrastructure.

The paper also connects Pkl to safety-case construction. Each ODD parameter can be traced back to a requirement ID, fulfilling ISO 26262–8 attributes such as unique ID, status, and ownership. In addition, automated impact analysis is described: a change in an ODD constraint automatically highlights affected test suites. This linkage between formal specification and test impact is one of the paper’s strongest claims regarding operational usefulness.

Future work is described in two directions. First, embedding ODD definitions into simulation frameworks would allow on-the-fly conformance checks during scenario execution. Second, projected extensions would support comparison of two ODD instances for coverage gaps. These are not reported as implemented results, but they indicate how Pkl-based formalization might evolve from static validation toward runtime conformance and comparative coverage analysis.

6. Automotive ODD example

The paper illustrates the approach with an automotive ODD assembled from reusable templates (Skoglund et al., 2 Sep 2025). The top-level template is defined as:

$n \in \mathbb{R}$1

This example exhibits modular composition. The ODD is factored into scenery, environment, and dynamic elements, each imported from a separate template. The @ModuleInfo block records the minimum Pkl version as "0.25.1".

A more detailed subcomponent is the drivable-area specification:

$n \in \mathbb{R}$2

This fragment shows several of the language mechanisms discussed earlier. speed_limit_global is a constant. Direction_of_travel is an enumeration-like type alias. Lane_dimensions uses a constrained float with a default value. Drivable_area_lane_specification combines structured fields, categorical restrictions, numeric constraints, and a Boolean default.

An ODD instance is then created by overriding a subset of the template:

$n \in \mathbb{R}$3

The corresponding rendered JSON excerpt is:

$n \in \mathbb{R}$4

The example also includes a constraint violation:

$n \in \mathbb{R}$5

According to the paper, this end-to-end example illustrates abstraction, templating, validation, and serialization. More specifically, classes isolate lane-specific rules, reusable modules separate scenery, environment, and dynamics, constraints enforce numeric ranges and enumerations, and JSON export enables consumption by test tools.

7. Evaluation, comparison, and scope

The paper compares Pkl-based ODD formalization with natural-language ODDs such as ISO 34503 and BSI PAS 1883, and with early ASAM OpenODD concepts (Skoglund et al., 2 Sep 2025). Against natural-language ODDs, Pkl is said to provide machine-readability and automatic validation, thereby eliminating ambiguous textual descriptions. Templates and imports are said to cut duplication and ease collaborative editing.

Against early ASAM OpenODD concepts, Pkl’s mature implementation is emphasized. The paper identifies a command-line tool, a library, and build plugins as evidence of immediate DevOps integration. Graphical export via PlantUML is additionally noted as a way to preserve human readability during safety-case reviews.

The evaluation is framed in terms of criteria fulfilment rather than benchmark metrics. CC1–CC3 are fully satisfied; SC1–SC3 are largely satisfied; IC1–IC2 are supported. The paper attributes integrity to immutability, readability to tree diagrams, and traceability to external SCM integration. It attributes taxonomy integration and test execution enrichment to modular imports and JSON/YAML outputs for scenario generators.

The concluding position is that Pkl strikes a balance between configuration simplicity and the expressiveness needed for safety-critical domains. Its formal foundations—grammar, typing, and constraints—are described as guaranteeing consistency, while its tooling—evaluation, exports, and diagramming—streamlines assessment. The paper also explicitly notes that no turnkey ODD-specific language yet exists, and presents Pkl as evidence that a general-purpose configuration language can meet all core ODD formalization requirements with minimal extensions.

This suggests a bounded but significant interpretation of Pkl’s scope in the paper. It is not introduced as a universal formal method for safety assurance in general; rather, it is demonstrated as a practical, formalized configuration language that can encode ODDs with enough rigor to support validation, traceability, and automation in safety-critical development contexts.