Specify required fields, types, allowed states, and missing-value rules. Parse and validate the result, then apply source and business checks before allowing any downstream update.
In this guide
Define what each field means
Give every field a business meaning as well as a type. Product IDs should remain strings when their characters matter; an amount needs a currency and a known scope; a status should use defined states rather than arbitrary prose. Decide how unknown, absent, empty, and null values are handled.
JSON Schema documents properties, required fields, and additional properties as useful structural controls. A parser or schema validator can reject an unexpected shape, but an invented price can still be a valid number. Keep evidence and business validation as the next explicit checks.
What should the reviewer do with valid JSON?
Keep the existing JSON schema and filled object beside this review record. Syntax and field types answer a different question from whether a value matches the source. A deterministic validator can catch malformed output; a reviewer still needs the original quote for currency and shipping conditions.
- Write a small output contract for the next step and define required versus optional information.
- Supply that contract with the task and source material, using the host/model's supported formatting features where available.
- Parse the response and validate it with a compatible validator in your own application.
- Route invalid structure to a review or repair path that preserves the original response and error.
- Check source support, identifiers, units, ranges, and conditions even after structural validation passes.
- Update the destination after the required checks and any approval, retaining the output version and evidence.
| Check | Filled example | Decision |
|---|---|---|
| Shape | Required currency field exists | Schema check can pass |
| Evidence | Source says EUR; output says USD | Reject factual value even if schema passes |
| Missing term | shipping_scope: null; question retained | Ask supplier; do not replace null with free shipping |
A small schema can expose a missing state
This original teaching schema describes a review record rather than a purchase action. It requires a string item ID, a status, and evidence references. The amount can remain null when it is unknown. Configure and test a validator appropriate to your environment before using a schema in a live workflow.
{
"type": "object",
"properties": {
"item_id": {"type": "string"},
"status": {"enum": ["needs_review", "checked"]},
"amount": {"type": ["number", "null"]},
"evidence_ids": {"type": "array", "items": {"type": "string"}}
},
"required": ["item_id", "status", "amount", "evidence_ids"],
"additionalProperties": false
}Test invalid and misleading cases
- A required key is missing or a key has been renamed.
- An identifier becomes numeric and loses meaningful characters.
- Unknown data is replaced with an apparently valid value.
- A response has the right fields but cites evidence for a different item.
- A valid record still contains an unresolved commercial condition.
Valid structure still needs a business decision
In a authored practice quote record, item_id is Q-B and amount is 1640. The JSON can be structurally valid while the amount represents goods for a 200-unit minimum, not the buyer's 120-unit order. Currency and cost scope must therefore remain in the broader business record before any comparison.
Keep a business rule that checked status requires the relevant evidence review. The schema above does not establish that relationship by itself. Define additional validation or a reviewer decision instead of assuming a label emitted by a model proves the work was done.
This record matches the example shape but stays needs_review: the amount is USD goods cost at 200 units. Keep the currency, quantity, and cost scope in the source-linked business table before approving any comparison.
{
"item_id": "Q-B",
"status": "needs_review",
"amount": 1640,
"evidence_ids": [
"quote-b.pdf:page-1"
]
}Keep rejected output available for diagnosis
Save the error, source/input version, and proposed repair. Repeated structural failures may call for a clearer contract; repeated factual failures may call for better evidence or a smaller task. Keep both categories visible in the run review.