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

# JSON Schema

> The machine-authoritative schema for .nika.yaml.

The canonical schema lives at:

**[https://nika.sh/schema/workflow.json](https://nika.sh/schema/workflow.json)**

It's a standard [JSON Schema draft 2020-12](https://json-schema.org/)
document. Your editor's YAML LSP can consume it directly.

## Contract version

`nika: v1`, the first line of every workflow. A **single version marker**:
the key `nika` declares "this is a Nika workflow", the value `v1` pins the
language contract version. There is no separate `schema:` or `apiVersion:`
field (the engine's internal canonical URI stays `https://nika.sh/spec/v1`
for RDF / conformance tooling, but the author never types a URL).

## Point your editor

Add the LSP modeline at the top of any `.nika.yaml` so your editor's YAML
language server consumes the JSON Schema directly:

```yaml the modeline · paste at the top of any workflow theme={"system"}
# yaml-language-server: $schema=https://nika.sh/schema/workflow.json
nika: v1
workflow: my-workflow-id
```

See [editor setup](/getting-started/editors) for per-IDE instructions.

## Local validation

```bash theme={"system"}
nika check workflow.nika.yaml   # validates against the v1 contract
nika check workflow.nika.yaml --strict   # + extra lints
```

## Versioning policy

* `v1` is the **only value for the entire lifetime** of the v1 contract.
* Minor additions (a new optional field, a new builtin) are **additive**
  and never change the marker: no `@minor` bumps, no `nika migrate` for them.
* A future `nika: v2` would be a deliberate breaking-change generation with
  its own spec, and since the `v1` envelope is frozen, that is effectively never.
* Anti-pattern: `nika: v1.0` · `nika: "1"` · `nika: 1.0`. The value is exactly `v1`.
