What Is JSON Schema Validation?
JSON Schema validation is the act of checking a JSON document against a schema — itself a JSON document — that declares which types, which members and which value constraints are permitted. A validator takes the two, applies each keyword the schema contains to the part of the instance that keyword addresses, and reports either that no declared rule was broken or precisely which ones were, and where.
What the keywords do, and what the defaults quietly permit
Keywords fall into three groups, and confusing them is where most of the surprises come from. Assertions constrain a value directly: type, enum, required, minimum, maxLength, pattern. Applicators constrain nothing themselves; they apply other schemas to parts of the instance — properties to named members, items to array elements, allOf, anyOf, oneOf and the if/then/else trio to the instance as a whole. Annotations assert nothing whatsoever: title, description, default and examples exist to be read by tooling and by people, and a validator passes a document that contradicts every one of them.
Two defaults account for most documents that pass when their author expected a rejection. Listing a member under properties does not make it mandatory — that is what the separate required list is for, and it holds names rather than constraints. And unless additionalProperties is set to false, or the members are accounted for some other way, a document may carry any number of keys the schema never mentions; they are unconstrained rather than forbidden. A schema naming three fields is, by default, a schema about those three fields and silent about the rest of the object.
The third default is subtler and it defeats more schemas than either. An applicator only applies where the instance is of the kind it addresses. properties says nothing about a string, items says nothing about an object, minimum says nothing about a value that is not a number — and in each case the outcome is a pass, not a failure. A constraint is therefore only load-bearing when it is paired with a type that forces the instance into the kind the constraint knows how to inspect. Without that pairing, the wrong kind of value walks past every keyword written for the right kind.
| Keyword | What it actually does |
|---|---|
| properties | Applies a subschema to the named members that are present. It requires none of them. |
| required | Lists the member names that must be present. It says nothing about their values; the subschemas do that. |
| additionalProperties | Governs members the schema does not account for. Left unset, unknown members are permitted and unconstrained. |
| format | In the recent drafts an annotation by default. Whether it is asserted is a validator setting rather than a property of the schema. |
| description | Nothing at all. It is an annotation, and a document contradicting it is valid. |
| oneOf | Requires exactly one branch to validate. Where two branches overlap, a document matching both is rejected, which is rarely what the author meant. |
Every row is a place where a schema is read as prose and behaves as a specification, and the specification decides. The quickest way to establish which reading a schema has is to hand the validator a document that ought to be rejected and confirm that it is — a schema is only as strict as the rejections somebody has actually observed.
Drafts, and what a passing validation does not establish
JSON Schema is versioned into drafts, and a schema declares which one it is written against with the $schema keyword. The vocabulary moved between them: definitions became $defs, and the array keywords were reorganised so that positional entries are declared with prefixItems while items governs the remainder. A validator implementing one draft and handed a schema written for another does not usually complain; it ignores the keywords it does not recognise, and ignoring a keyword means not asserting it. Schema and validator therefore have to agree on the dialect, and that agreement is the first thing to check when a validator accepts something it plainly should not.
What a pass means is narrow, and worth stating exactly: no rule this schema declared was broken by this document. It is not a statement that the document is correct, that its values are true, that its numbers are the intended numbers, or that whatever produced it was working. A validator has no view of any of that. It compares a document against a declaration and reports on the comparison, so every property nobody declared is a property nobody checked.
Failure reporting is where validators differ most, and the difference is practical rather than cosmetic. A useful report names the failing keyword and points at the failing node with a path into the document, which makes the repair mechanical. Combinators are the hard case: when a document fails anyOf, every branch failed, and the complete report is the union of every branch's errors — accurate, long, and rarely pointing at the branch the author had in mind. Schemas that discriminate on a member value before branching produce reports that name the branch instead, which is a design decision taken for the sake of the errors rather than for the sake of the validation.
How the Registry classifies a payload validation task
Validating every tool response against a declared schema and rejecting the payloads that fail is filed as a code modification task in this registry's classification. What the task produces is source — a schema file, a validation step, a rejection path — and the classification follows the artefact rather than the payloads that will one day travel through it.
The Registry's canonical brief for this entry is filed as:
Validate every tool response against a declared JSON Schema and reject any payload that fails the check.
Submitted for assessment it is
classified as Code modification, and its wording is hashed once — to
c0a4aab2fe9d93ec…, the first sixteen of sixty-four hexadecimal
characters — with the wording itself never stored. The hash is what the derivation
reads.
That class's own page is /tasks/code.
Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.
What this page does not claim about json schema validation
Which draft a given validator implements, which formats it asserts rather than annotates, and how it reports a combinator failure are properties of that library and are stated in its own documentation rather than restated here. The canonical brief above fixes an operation and no library. This registry validates nothing on an operator's behalf, holds no schema of theirs, and has compared no validator against another.
The Registry does not run this task, does not inspect any system's output for it, and validates no assessment it issues against what afterwards happens. What it does is compute — from a published method, for one submitted task and one submitted configuration — a verdict and a recommended execution window. It computes neither on this page.
Questions about json schema validation
- What is JSON Schema validation?
- It is the process of checking a JSON document against a schema that declares permitted types, required members and value constraints. A validator applies each keyword to the part of the document it addresses and reports whether any declared rule was broken, and where.
- Does a schema reject fields it does not mention?
- Not by default. Members the schema does not account for are permitted and left unconstrained unless additionalProperties is set to false or the members are covered another way. A schema naming three fields is silent about a fourth rather than opposed to it.
- Does listing a property make it required?
- No. The properties keyword attaches a subschema to a member when that member is present. Making it mandatory is a separate declaration, the required list, which holds member names and says nothing about their values.
- Is the format keyword enforced?
- In the recent drafts it is an annotation by default, so a validator may report a malformed email address as valid unless format assertion has been switched on. Whether it is enforced is a property of the validator configuration rather than of the schema.
- What does a passing validation prove?
- That the document broke no rule the schema declared. It is not evidence that the values are correct, that they were read from the right place, or that anything the schema does not mention is in order.
Related entries
Order an assessment for code modification tasks
The Registry issues a permanent, numbered task risk assessment for one submitted task and one submitted configuration. EUR 1.90 Standard, EUR 4.90 Extended, EUR 14.90 Full Chart, which adds the permanent chart. Assessments from EUR 1.90; machine-readable at /pricing.json.