Shipping Strict JSON Before Friday’s Berlin Release

Field trips EN2026-10-28

What strict JSON means for Friday’s release

Imagine your Berlin team is building a support-ticket router. A model reads each ticket and must return a category, urgency level, and short summary. If it replies with a friendly sentence around the data, your parser can fail. If it leaves a quote unescaped or adds a trailing comma, the same thing happens.

Strict JSON means the model response can be parsed as JSON and follows the shape your application expects. It is not merely “please answer in JSON.” That instruction can improve results, but it does not guarantee valid syntax, required fields, correct data types, or the absence of extra text.

The difference between a JSON request and a JSON response

Many developers first confuse the format of the API request with the format of the model’s answer. Your request is usually JSON because the HTTP API expects JSON. The generated content is a separate piece of text inside the response. That content may contain JSON, but it is still produced by a language model unless you apply stronger controls.

A reliable workflow treats the model output as untrusted input. Parse it, validate it against a schema, and only then pass it to business logic. Never send fields to a database, billing system, or automation step simply because they look correct.

Define the output shape before writing the prompt

Start with a small contract. For the ticket router, you might require an object with these fields: category as a string, urgency as one of low, medium, or high, and summary as a string with no more than 200 characters.

Decide what should happen when information is missing. Should the model use an “unknown” value, return null, or reject the ticket? Also decide whether additional fields are allowed. An explicit contract prevents a common failure: the model returns useful-looking data that your code was never designed to handle.

Use stable field names such as category, urgency, and summary.
Specify data types and allowed values.
State whether fields are required.
Set limits for lengths, arrays, and numeric ranges.
Reject unexpected properties when your validator supports that rule.

Use native structured output when the model supports it

The strongest option is an API feature that accepts a JSON schema or a JSON response mode. The API then constrains generation more directly than a prompt alone. Exact parameter names vary between providers and SDKs, so check the documentation for the model and endpoint you are using.

When working with GPT-6.1 Sol or Claude Sonnet 5.5, keep the requested schema focused. A small schema is easier for the model to satisfy and easier for your application to validate. If your provider offers tool or function calling, that can also provide a structured argument object, but you should still validate the arguments before using them.

Write a prompt that removes avoidable ambiguity

Prompting remains useful even with schema enforcement. Tell the model what the fields mean, not just what they are called. Say that urgency should reflect the customer’s immediate business impact, rather than asking for a general opinion. Tell it to return no commentary outside the requested object.

Include one or two representative input examples only when they clarify a difficult rule. Avoid placing several competing formats in the same prompt. Instructions such as “return JSON, explain your reasoning, and include a helpful note” create competing goals and often produce extra text.

Validate, repair, and retry without hiding errors

After receiving the response, first locate the expected output field, then parse it with your language’s JSON parser. Next, validate the parsed value against your schema. Syntax validation answers “is this JSON?” Schema validation answers “is this the JSON my application needs?” You need both.

If parsing or validation fails, record the provider response and request ID, then retry with a short correction message. Explain the exact failure, such as “urgency must be high, medium, or low.” Limit retries to one or two attempts. A failed result should become a visible application error or a human review task, not an endless loop.

Set a timeout and a maximum output size.
Log validation failures without storing sensitive user content unnecessarily.
Track failure rates by model, prompt version, and schema version.
Test empty input, long input, multilingual text, and adversarial instructions.

Make RelayVano part of a portable model setup

If you want one OpenAI-compatible entry point while testing different providers, RelayVano offers pay-as-you-go access to models through https://api.relayvano.com. That makes it practical to keep your application’s request, parsing, and validation pipeline consistent while you compare model behavior.

Sign up for RelayVano, choose a model that fits your workload, and begin with a small test set before moving the integration into production. The safest design is not the model that never makes a mistake; it is the system that detects mistakes before they become actions.