The Schema That Checks the Schema

Specification scope: Core with the Validation companion specification.

A misspelled schema keyword can affect every instance checked against it. If a processor overlooks it, every document checked afterward may receive the wrong verdict.

JSON Structure can catch that error before the schema is used to validate application data. A schema document is itself an instance, checked by a meta-schema. Its root $schema identifies the language it claims to use, and a processor can test that claim before generating code or validating a business document.

Follow $schema up one layer

In a schema document, $schema identifies a meta-schema. In an application instance, $schema identifies the application schema. The keyword stays at the document root in both cases, but the referenced document plays a different role.

The following schema uses only the core vocabulary:

{
  "$schema": "https://json-structure.org/meta/core/v0/#",
  "$id": "https://example.com/schemas/device-reading",
  "name": "DeviceReadingSchema",
  "$root": "#/definitions/DeviceReading",
  "definitions": {
    "DeviceReading": {
      "name": "DeviceReading",
      "type": "object",
      "properties": {
        "deviceId": { "type": "string" },
        "sequence": { "type": "uint32" },
        "online": { "type": "boolean" }
      },
      "required": ["deviceId", "sequence", "online"],
      "additionalProperties": false
    }
  }
}

The core meta-schema checks the document above as an instance. It knows that properties must be a map, required must be an array of property names, and additionalProperties must have the form allowed on an object type. It also knows which type names belong to core.

An application instance then points at the schema one level down:

{
  "$schema": "https://example.com/schemas/device-reading",
  "deviceId": "pump-17",
  "sequence": 42,
  "online": true
}

Resolving $schema does not import the referenced document’s definitions into the current namespace. It selects the contract against which the current document is interpreted and checked.

Core does not admit every keyword

The core meta-schema at https://json-structure.org/meta/core/v0/# defines the base schema language: document structure, primitive and compound types, references, definitions, extension machinery, and the structural constraints attached to those constructs.

The extended meta-schema imports core and advertises named feature bundles for alternate names, units, import, conditional composition, and validation. A schema that needs one of those vocabularies references an appropriate meta-schema. Where that meta-schema exposes optional add-ins, the schema selects the relevant names through root-level $uses.

This separation means that minimum is not silently accepted by a core-only processor. The schema must reference a meta-schema and select the vocabulary that defines the keyword.

Bad schemas fail before bad instances

Here is a deliberately invalid schema fragment. It is valid JSON, but not a valid JSON Structure object type:

{
  "type": "object",
  "properties": [
    { "deviceId": { "type": "string" } }
  ]
}

properties must be a map from property names to property declarations. An array does not become acceptable because its contents look plausible. The meta-schema rejects the fragment at the schema layer.

Without meta-validation, the result is tool-specific. A tool may ignore the invalid declaration or fail later with a tool-specific error. Meta-validation gives one useful answer immediately: this schema document violates its declared language.

It cannot prove that the author modeled the business correctly. No meta-schema can tell us whether pump-17 ought to be a device reading. It can stop us from asking that question of a malformed schema. The resulting error points directly to the malformed schema.