Why a JSON Schema check says “not fully checked”

{
  "id": "A-1042",
  "customer": "Ada Lovelace",
  "items": [
    { "sku": "PEN-01", "quantity": 2, "price": 3.5 },
    { "sku": "PAD-02", "quantity": 0, "price": 7 }
  ],
  "total": "18.00"
}

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "required": ["id", "items", "total"],
  "properties": {
    "id": { "type": "string" },
    "customer": { "type": "string" },
    "items": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "sku": { "type": "string" },
          "quantity": { "type": "integer", "minimum": 1 },
          "price": { "type": "number" }
        }
      }
    },
    "total": { "type": "number" }
  }
}

Invalid · 2 errors

$.items[1].quantity  minimum  Must be at least 1.
$.total  type  Expected a number, found a string.

Schema is the fourth of the editor’s modes, and the second one that holds two documents. The left pane is the thing being checked and the right is the set of rules it has to satisfy. Those two roles never swap: whatever is on the right is read as a schema, and the verdict is always about the document on the left.

The order above puts the offending path first, then the keyword that rejected it, then the sentence the engine wrote. Two failures in a seven-line order is a small example on purpose — the useful thing to learn here is not that a string is not a number, but what the editor does with that finding and what it does when it cannot reach one.

Four verdicts, and why there are four

Most validators answer with two words, and that is the design flaw this one was built to avoid. The band shows one of four:

• Valid — every rule in the schema was applied and the document satisfied all of them.
• Invalid — a rule was applied and the document failed it. The count beside the word is how many failures there were.
• Not fully checked — the rules that were applied all passed, and some of the schema could not be applied at all.
• Schema error — the right-hand document is not a usable schema, so nothing could be checked against it.

The third is the one that earns its place. A schema can contain a keyword from a later draft, a format this engine declines to interpret, or a reference to another document somewhere on the network — and an engine that silently skipped those would report a clean bill of health on a document it had barely inspected. Folding that into Valid would be a lie of omission; folding it into Invalid would be a lie about the document. So it is its own answer, and it names what went unapplied.

That is the whole reasoning, and it is worth internalising before you trust any verdict: a pass means the rules that ran passed, and this editor is unusual in telling you when some did not run.

What is marked, and where

Failures are marked on the document, because that is what failed. Whatever the left pane is showing — text, tree, table or graph — the offending values carry a mark, so the errors are findable without switching to Code first.

Unapplied keywords are marked on the schema, because that is what could not be used. Keeping the two kinds of mark on opposite sides is what makes them readable at a glance: a mark on the right is never something wrong with your data, and a mark on the left is never something the engine declined to do.

Validate opens a panel listing what was found. Each row names a path and what failed there, and selecting one jumps to that value in whichever view the pane is showing — which is the fastest route from “two errors” to the second one, on a document where scrolling would not find it.

When it declines to run at all

Two refusals come from the editor rather than from the engine, and both say what is missing instead of going quiet. With nothing in the right pane, the verdict reads No schema yet. — there is no rule to check against, which is not the same as a document that passed. With a left pane that will not parse, it reads The document does not parse — nothing to validate., and the thing to do is fix the document first; that is what Repair is for.

A refusal is never silence. A validator that showed nothing when it had not run would be indistinguishable from one that had run and found nothing, and those are opposite outcomes.

Validation runs as you type, until it costs too much

Ordinarily the check re-runs by itself whenever either pane changes, so the verdict is current without anything being pressed. A slow run changes that: past a small time budget the editor stops re-running automatically, says that it has, and leaves Validate to be pressed when you want a fresh answer.

The limit is on time taken, not on how large the document is, and the difference matters. A modest document against a schema full of combinators can take longer than a large one against a simple schema, so a size limit would demote the wrong cases and let the expensive ones through.

While a re-run is due, the previous verdict stays on the band and dims rather than being replaced by a word like “working”. An answer that is one keystroke out of date is more useful than no answer at all, and the dimming is what says which it is.

Getting a schema to start from

If you have a document and no schema, Generate will draft one from it and hand it straight to this mode — its Validate with this step fills the right pane for you to tighten by hand. A drafted schema describes the example you gave it, so it is a starting point rather than a specification, and narrowing it is where the real work is. A JSON Schema, and checking the next file works through one from start to finish.

Pressing New clears the document and keeps the schema, which is the asymmetry the mode is for: checking a series of documents against one set of rules is the common case, and retyping the rules each time would be absurd.

For the longer article on the validator itself — the draft it targets, what it supports and how it behaves on large schemas — see the JSON Schema validator page, which opens in this same mode with its own writeup below it. Open the editor to check a document of your own, or read How to compare JSON files and see what changed for the other two-document mode.