> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mirurobotics.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Validation

The primary purpose of schemas is to validate config instances.

## Example

Let's look at a simple example to see this in action.

The following is a toy schema written in JSON Schema.

```yaml JSON Schema expandable theme={null}
$schema: "https://json-schema.org/draft/2020-12/schema"
title: Mobility
type: object
properties:
    max_linear_speed_mps:
        type: number
        minimum: 0.1
        maximum: 5.0
        default: 1.2
    max_angular_speed_radps:
        type: number
        minimum: 0.1
        maximum: 3.0
        default: 1.0
    obstacle_avoidance_enabled:
        type: boolean
        default: true
    navigation_mode:
        type: string
        enum: [conservative, balanced, aggressive]
        default: balanced
    telemetry:
        type: object
        properties:
        upload_interval_sec:
            type: integer
            minimum: 10
            maximum: 300
            default: 60
        heartbeat_interval_sec:
            type: integer
            minimum: 1
            maximum: 60
            default: 10
        required:
        - upload_interval_sec
        - heartbeat_interval_sec
required:
- max_linear_speed_mps
- max_angular_speed_radps
- obstacle_avoidance_enabled
- navigation_mode
- telemetry
```

The schema defines what constitutes a valid config instance in several different ways:

* Names the available properties
* Organizes the configuration structure, placing some properties at the root while nesting other properties into logical groups
* Gives each property a type, such as `number`, `boolean`, etc.
* Constrains the values of each property—minimums, maximums, enumerations, etc.
* Supplies default values to properties where appropriate

Most of these constraints are optional, and many features of JSON Schema are omitted here, but this gives you a flavor of what schemas are capable of.

Say we are deploying the following config instance.

<Frame>
  ![Invalid Mobility Edit](https://assets.mirurobotics.com/docs/v04/images/devices/editor/invalid-mobility-edit.png)
</Frame>

Unbeknownst to us, the `max_angular_speed_radps` field exceeds the maximum allowed value of 3.0.

Luckily, before deployment to the device, the config instance is validated against the schema, throwing the following error:

<Frame>
  ![Invalid Mobility Error Message](https://assets.mirurobotics.com/docs/v04/images/devices/editor/invalid-mobility-err-msg.png)
</Frame>

Identifying the issue, we correct the `max_angular_speed_radps` field to use the maximum allowed value of 3.0 and deploy the config instance to the device.

<Frame>
  ![Valid Mobility Edit](https://assets.mirurobotics.com/docs/v04/images/devices/editor/valid-mobility-edit.png)
</Frame>

This time, the config instance successfully validates against the schema and is deployed to the device.

Although simple in concept, schemas are a powerful tool for preventing typos, misconfigurations, and other preventable errors.

## Empty schemas

While schemas provide significant value in production deployments, defining one from scratch can be a considerable undertaking.

Many teams find it best to begin with an empty schema—one that accepts any configuration—and gradually add constraints. This approach allows you to define the most highly valued constraints first and progressively transition to stricter and stricter schemas as needed.

Below are the empty schemas for JSON Schema and CUE, respectively.

<CodeGroup>
  ```yaml JSON Schema theme={null}
  $schema: "https://json-schema.org/draft/2020-12/schema"
  ```

  ```cue CUE theme={null}
  {}
  ```
</CodeGroup>