Skip to main content
A config schema defines the structure, types, and constraints of a config instance. It serves as a contract between code and configuration, ensuring that config instances are valid before being deployed to devices.

​
Properties

​
string
The schema language used to define the schema.Allowed values:
  • jsonschema
  • cue
  • opaque
​
enum
The file format used to define the schema.Config schemas support the following file formats:Note that a schema’s format does not need to match the format of the config instance it validates. For example, a YAML-formatted JSON Schema can validate a JSON-formatted config instance.Allowed values:
  • cue
  • json
  • yaml
​
string
The raw schema definition, written in the specified schema language.The exact contents of a schema file is preserved in Miru, including any comments, whitespace, and formatting.
​
string
A hash of the canonicalized schema content.Digests are computed by converting schemas to a canonical format—a format that ignores whitespace, comments, and other non-semantic differences—and then hashing the result. This is useful for comparing schemas and detecting duplicates.Examples: sha256:45YeoJJ2btBnAKQztAEXEjHsqyyQfC1z1Mw3LLM4xMUy
​
InstanceSlot[]
The valid file system destinations that config instances for this schema are written to.Typically a schema defines only a single required slot. However, schemas may define several instance slots when the same validation applies to several different config instances in a release.See Instance slots for fields, constraints, and default behavior.
​
string
The file format that config instances (for this schema) are deployed as on the device.Consult the file formats section below for the supported formats for each schema language.Examples: json, yaml, xml, text
​
Config Type
The config type to which the schema belongs.Examples: Mobility, Safety Features, Perception

​
Schema languages

Config schemas are defined using a schema language—a formal language for describing the structure, constraints, and data types of a configuration. Miru supports:
  • JSON Schema (draft 2020-12)
  • CUE
  • Opaque (metadata-only schemas that regard all config instances as valid)
For more information on schema languages, visit the languages section of this guide.

​
File formats

Config schemas support the following file formats: Note that a schema’s format does not need to match the format of the config instance it validates. For example, a YAML-formatted JSON Schema can validate a JSON-formatted config instance.

​
Schema annotations

Annotations are a convenient way to store metadata with your schemas, such as the schema’s config type and where its config instances are written on the device. Most annotations are optional, but some are required for Miru to process the schemas correctly. For the full list of annotations and their syntax in each schema language, visit the annotations section of this guide.

​
Immutability

Config schemas are immutable. A schema is created once as part of a release and never edited in place. To change what a config type accepts, you must create a new schema, release it, and deploy it to your devices.

​
Git provenance

Schemas are defined as files in your Git repository and created by releasing them via the CLI. Each schema records the Git commits it was released from — the commit itself and the schema file’s paths relative to the repository root — so any schema in Miru can be traced back to the exact lines that defined it.
Last modified on September 23, 2026