Schema-Valid AI Output: What the JSON Guarantee Leaves Unchecked

Understand what the provider constrains

Structured output moves format control beyond a request to please return JSON. Amazon Bedrock's documentation, checked on October 20, 2026, describes validating a submitted schema against its supported Draft 2020-12 subset and compiling a grammar to constrain the response. The guarantee is tied to that supported schema and the selected model and API.

The mechanism limits the permitted response form. A required integer field cannot be satisfied by a string simply because the string sounds like a number. It does not follow that every permitted integer is the correct quantity for the buyer's order.

Google's documentation explicitly retains application value validation and handling for schema-compliant outputs that are wrong in meaning. Buyers still need an explanation of how the application establishes a usable answer.

References: [A1][G1]

Separate parsing, schema assertions, business rules and source context

Parsing asks whether text can be read as JSON. A JSON object containing a quantity written as the string ten can pass that step. Parsing alone does not ask whether the application requires a number, whether a field is missing or whether an unexpected field is present.

Schema assertion asks whether the parsed value meets the declared rules. JSON Schema uses properties to describe fields, required to demand their presence and additionalProperties to control extra fields. Declaring a property does not automatically make it required. The exact assertions matter more than the phrase valid JSON.

Business validation asks whether values satisfy the task's rules, including relationships between fields. For an order, that could mean calculating the expected total from the accepted quantity and price under the agreed treatment of discounts, tax and rounding.

Source and permission checks ask whether those values refer to the relevant authoritative record and whether the intended use is allowed. A calculation can be internally consistent while describing someone else's order. These questions can be handled by different components; the purchase needs to identify which component owns each answer.

References: [J1]

Follow three fictional outputs through one declared schema

Consider an invented order-extraction task. The schema declares one object with exactly four fields: order_id is a string, quantity is an integer, unit_price is a number and total is a number. All four are required, and additionalProperties is false. There are no other constraints: no allowed order identifiers, numeric bounds or rule connecting the total to the other values.

For this example, the authoritative order for the current buyer is A104: ten items at seven invented price units per item, with a total of seventy price units. There are no discounts, tax or rounding adjustments. Another customer has order B207 with the same quantities and prices. These are stipulated records and fabricated candidate outputs, not observations from a named model or a Leviathan test.

The first candidate contains order_id A104, quantity as the string ten, unit_price 7 and total 70. It can be written as parseable JSON, but fails this schema because quantity is not an integer. A friendly-looking word does not satisfy the chosen field type.

The second candidate contains order_id A104, quantity 10, unit_price 7 and total 7. It satisfies all the stated field rules, yet contradicts the stipulated calculation: 10 items multiplied by 7 price units per item equals 70 price units. No assertion in this schema compares those fields, so its structural result cannot establish arithmetic consistency.

The third candidate contains order_id B207, quantity 10, unit_price 7 and total 70. It satisfies the schema and the arithmetic. It still fails the current buyer's task because it identifies the other customer's order. The application needs the expected order and customer context to detect that mismatch. Neither the field types nor the multiplication supplies that context.

References: [J1]

Use stronger constraints without assigning them unwritten meaning

The example's limits belong to its declared schema. They do not prove that every schema checks only types. Richer constraints can narrow acceptable values where the selected implementation supports them. Google documents numeric bounds, for example, while also warning that it supports a subset of JSON Schema. An implementation offer should identify the actual assertions accepted by its chosen provider rather than assume the entire specification is available.

An enum restricts a field to listed choices. If a classifier permits hardware and software, returning hardware can satisfy that constraint while still misclassifying the supplied document. The allowed vocabulary and the correct selection from it are separate questions. Likewise, a description telling the model how to calculate a total does not, by itself, establish an enforced arithmetic check.

An explicit unknown or null representation can preserve uncertainty when the supported schema and application contract allow it. The receiving application must define whether that value pauses the task, requests information or goes to review. Missing, null, an empty string and zero should not silently become interchangeable. Allowing null for quantity would change the fictional schema above; its current integer requirement does not permit that result.

References: [G1][J2]

Compare a format-only offer with a complete offer for the task

A format-only offer delivers responses conforming to an agreed supported schema. That can be useful when the receiving application already supplies the remaining checks. Its demonstration should establish the promised structure; its scope should identify where the application takes responsibility for the values.

An offer complete for the declared extraction task also assigns the calculation, authoritative-record comparison, customer context and any permission decision needed before downstream use. It explains what happens to a response that fails a check or remains unresolved, and distinguishes those cases from a failed request or incomplete response. A structurally valid record should not be counted as an accepted order merely because it reached the receiving software.

Use the fictional order cases to make the comparison concrete. Ask the proposed implementation owner to show which component would identify the string quantity, the incorrect total and the other customer's identifier, and what disposition each would receive. For the third case, ask where the expected customer and order come from. If that source is unavailable, the result remains unresolved.

The useful deliverable is a traceable decision: the candidate record, the applicable rule or source, the check result and the resulting handling. The buyer can then compare a narrowly defined formatting component with a complete application outcome without treating them as equivalent purchases.

Keep tool structure separate from authority and execution

The same distinction applies when a model proposes a tool call. Bedrock describes strict tool use as enforcing the defined tool names and input schema. A well-shaped tool request does not itself establish permission to perform the action.

For example, a permitted string field containing a recipient address does not show that the recipient may receive the referenced order. The host application needs the relevant permission decision. A correctly structured call also does not establish that execution succeeded or that a returned value is true. Those conclusions depend on execution evidence and the relevant source, rather than the shape of the proposed arguments.

References: [A1]

Connect a separate equipment need to the physical deployment scope

The related GPU benchmark and prefill/decode guides address hardware and serving decisions that can accompany an AI application. Their evidence answers different purchase questions from whether an extracted record is correct.

If the project also requires physical GPU equipment installation, Leviathan's Complete Physical Infrastructure Deployment service provides the relevant scoping discussion. Use the linked project inquiry with the selected equipment, destination, required connections and physical handoff. The service owns agreed physical delivery; it does not establish a model, application-implementation or cloud capability. Software assurance remains with the appointed application provider.

References: [L1]