Structured AI output: what a valid JSON response does not prove

A valid JSON response can still contain the wrong facts. Separate three checks: whether the data parses, whether it meets the schema and whether its contents are supported by evidence and suitable for the task.

JSON Schema documents types, required properties and other validation keywords. Those tools can constrain structure and values. They do not independently establish that a reported event, source or measurement exists.

Give structure and evidence their own entries in the review record. Parsing and schema checks describe how the response is formed; source checks address the content. Keeping the outcomes together makes it clear which parts of the task have been checked.

Follow a fictional record

Imagine an invented record:

{"city":"Example City","temperature":18,"unit":"C"}

It may parse successfully. A schema could require those fields, make temperature numeric and restrict unit to a specified set. The record could still be unrelated to any real observation. An allowed number is not a verified measurement.

Assign each check its job

Keep the rules tied to the intended task. A schema that accepts empty strings, for example, may permit a technically valid record that remains unusable for your purpose.

Test rejection as well as acceptance

Prepare examples with missing fields, unexpected types and values that violate your intended requirements. Also include a structurally valid but factually unsupported example so the review process distinguishes those failure modes.

Record structure and factual verification as separate checks, with the outcome of each. The useful outcome is a known route for accepting, rejecting or escalating each kind of problem before another system acts on the data.

Give each validation layer a concrete example

Consider this fictional response:

{"place":"Example Harbour","temperature":18,"unit":"C"}

Parsing asks whether this is valid JSON. A schema can then require place and unit to be strings and temperature to be a number. It can also define which properties must be present and whether additional properties are allowed. JSON Schema’s object documentation explains those structural controls.

Evidence review asks a different question: which observation supports the temperature, where and when was it made, and does it answer the requested task? The fictional record deliberately provides no real weather measurement.

Try a small schema against the record

This example schema gives the fictional response a precise structural contract:

{
  "type": "object",
  "properties": {
    "place": {"type": "string"},
    "temperature": {"type": "number"},
    "unit": {"enum": ["C"]}
  },
  "required": ["place", "temperature", "unit"],
  "additionalProperties": false
}

The example record fits these constraints. Removing place, changing the temperature to a string or adding an undeclared property would fail a different part of this contract. None of those tests establishes a real temperature reading. JSON Schema’s object reference explains the required-property and additional-property controls used here.

Define what happens when evidence is missing

For a data-entry workflow, agree whether the system should return an explicit unknown state, an error or a record awaiting review. Keep that decision consistent with the schema. An unknown value and a numeric zero represent different information and need deliberate handling.

Use a small acceptance set: a valid supported record, malformed JSON, a missing required field, a wrong type and a structurally valid record lacking support. State the expected handling for each before evaluating results. This makes the checking process inspectable and gives downstream code a clear contract for incomplete information, as well as successful responses.

A fictional temperature record can illustrate the distinction. The numeric field can be checked against the schema, while place, time and supporting evidence are reviewed separately. This example gives each check a defined job within the complete assessment.

Sources consulted

• JSON Schema reference — JSON Schema; consulted 3 November 2026.

• Object validation reference — JSON Schema; checked 4 November 2026 for required properties and additional-property controls.