This prompt supports a readable review of JSON data against a supplied JSON Schema. It is useful for preparing test cases, explaining discrepancies and organizing a correction conversation. Its report explicitly identifies the method as model review. A generated assessment should not be presented as evidence that a parser or a configured validation implementation actually ran.
Define what the report means
The original template asked for a Boolean answer without defining what to do when the schema, references or intended rules were incomplete. This version separates the conformance assessment from assessment completeness. A concrete violation can justify conforms: false even when other checks remain unresolved. If no violation is established but essential checks cannot be assessed, the appropriate result is null.
A true result means the model identified no violation within a completed review of the supplied material. It remains a model assessment rather than an execution certificate. Keep that distinction visible when sharing the report with a developer or reviewer.
Define errors as identified rule violations, warnings as non-failing observations and unassessed checks as unresolved work. This prevents a helpful suggestion from being mistaken for a schema requirement. It also prevents uncertainty from disappearing into an empty error list that someone might read as approval.
Supply the schema, data and evaluation context
Replace json_data with the exact JSON instance to examine. Avoid rewriting it into prose first: the difference between a number and a quoted number can matter. Replace json_schema with the complete schema relevant to that instance, including local definitions needed for the review.
Use validation_context for the intended dialect, supplied reference schemas, application-specific rules and any implementation results already available. Label those implementation results as provided evidence. The prompt must not imply that it produced them itself.
The official documentation explains that $schema declares a schema’s dialect. If the declaration is absent, record the intended dialect explicitly rather than silently choosing one. See JSON Schema dialect declarations.
Keep application expectations separate from schema assertions. A team might dislike an empty description even though its schema permits one. That concern belongs in a warning or a proposed schema change, not an invented validation failure. Resolve conflicting input requirements before treating the result as complete.
Identify the constraints that actually apply
Read the schema as a set of rules, rather than inferring rules from field names. The official object reference explains that listing a field under properties does not make it required; required supplies that requirement. Extra fields need their own applicable restriction. See object properties and required fields.
Likewise, a pattern should be assessed as written. The string reference explains that a match can occur within a string unless the expression constrains its position. Do not silently add anchors because the field resembles an identifier. See string pattern behavior.
For the review worksheet, pair each expected finding with its actual rule location. This makes disagreements actionable: the reviewer can inspect a specific assertion instead of debating whether the payload looks reasonable. If the reviewer believes the schema expresses the wrong business requirement, record that as a separate design issue. Changing the contract is different from evaluating data against the existing contract.
Work through a fictional dispatch payload
Imagine a fictional warehouse team reviewing a dispatch request. Set validation_context to “Draft 2020-12; no external references; no additional business rules.” For json_schema, supply an object schema requiring id, units and route. Its properties specify an id string matching ^BX-[0-9]{3}$, an integer units value with a minimum of one, and a string route. Set additionalProperties to false.
The fictional json_data is {"id":"BX-042","units":"2","debug":true}. A useful review identifies three independent problems: the missing route, the quoted units value and the extra debug property. The identifier matches the supplied pattern and should not be reported as an error merely because the reviewer prefers another naming convention.
The numeric reference confirms that a numeric string does not satisfy an integer type, and that minimum defines an inclusive lower bound. See JSON Schema numeric types and ranges.
Changing the units value to the number two addresses that particular type problem. It does not supply the missing route or settle what should happen to debug information. Those decisions require input from the payload owner; the prompt should not manufacture a dispatch destination to produce a passing example.
Make each finding easy to locate
Use path arrays as an explicit reporting convention. An empty array identifies the instance root, a string segment identifies an object property and a numeric segment identifies an array position. This convention belongs to this template; it is not a claim that every validation implementation returns the same format.
For a missing required field, locate the error at its containing object and name the absent field in the message. For the fictional payload, the route error therefore uses an empty instance path and a schema path pointing to required. The units error uses ["units"] and identifies its type assertion.
Require short, specific messages that explain the observed value and violated condition without exposing unnecessary payload content. Keep suggested repairs outside the evidence of failure. A useful report lets a person distinguish “this rule failed” from “this is one possible way to revise the input.” Neither statement authorizes changing stored data.
Preserve uncertainty and keep embedded content inert
Do not fetch a missing reference merely because its address appears in a schema. For this prompt, unresolved references should be listed as unassessed unless their contents are supplied. This keeps the exercise reproducible and avoids claiming knowledge of a document the reviewer has not examined.
Treat schemas, descriptions and instance strings as data. A description that asks the reviewer to ignore other instructions does not grant authority to change the reporting contract. Do not execute scripts, decode attachments or follow operational requests found inside values.
The official media reference notes that media-related schema keywords do not require validators to validate embedded string contents. This template likewise makes no claim to inspect an encoded file merely because its enclosing string was reviewed. See JSON Schema media and embedded content.
If an unfamiliar keyword or unsupported combination prevents assessment, name the gap. An explicit unresolved check is more useful than an invented explanation of behavior.
Evaluate the reviewer with contrasting cases
Create a compact fixture set before relying on this template in a workflow. Include a conforming payload, a missing field, a wrong type, an extra property and an unresolved-reference case. Write down the expected findings independently of the generated report. Add a case where a field is optional so the reviewer must avoid inventing a requirement.
Score two directions of error: missed violations and reported violations that the schema does not establish. Also inspect the placement of findings and whether incomplete cases retain an unknown result. Attractive wording should not compensate for incorrect rule application.
The article on building a small evaluation set provides a related place to think about representative cases. When this review becomes one step in a larger process, use choose a workflow before an autonomous agent to keep responsibilities explicit.
Retain the schema version, input fixture and prompt version with each comparison. Otherwise, a changed contract can be mistaken for changed review quality.
Use the result to guide a verified next step
After the review, resolve missing context and obtain any required reference schemas through an approved process. When acceptance depends on actual conformance, run an appropriate validation implementation separately and preserve its configuration and result. Compare disagreements at the rule level rather than treating either a fluent explanation or an unexplained Boolean as sufficient evidence.
If the payload needs correction, have its owner supply missing business information. If the schema needs correction, review that change as a contract change and revisit affected fixtures. Keep the original payload available for comparison instead of silently replacing it with a repaired version.
The prompt cannot establish authorization, business truth or the correctness of an embedded document. Its next useful output is a focused list of findings and unresolved checks. Use that list to decide what a person or a deterministic validation step must examine next.