JSON schema inspector

Models are good at producing something that looks like the shape you asked for. A field comes back as a string instead of a number, a nested object is flattened, a required array is missing because the model had nothing to put in it. None of that is visible in a chat transcript and all of it fails quietly the first time a consumer reads the value.

The inspector makes the difference visible: the tree shows exactly what came back, and the validation panel shows where it departs from the schema you pasted beside it.

Parsing, first — malformed JSON is reported with the parser's own message, since everything downstream depends on it. Then the schema subset a workflow usually declares: type on every property (including integer against number), required fields per object, nested properties, array items, and additionalProperties set to false for keys that should not exist.

Each finding carries its path, so a missing title inside the second finding reads findings[1].title rather than a vague complaint about the document.

This validates shape, not meaning. Ranges, formats, enumerations and cross-field rules are outside what it enforces here, and a schema-compliant payload can still describe the wrong thing entirely. Use it to stop the cheap failures — the null where a list belongs, the key that changed spelling between runs — and keep the content review elsewhere.