Structured JSON from local models: validate more than syntax

A valid object can still be the wrong answer

The JSON parses. The customer ID is wrong. That is still a failed extraction, and it becomes a bigger problem if an agent uses the ID to update a live record. Check four things separately: valid JSON, the right schema, facts supported by the source, and permission to take the next action.

Begin by writing the object your application actually needs. Keep fields narrow and define which may be missing. If a source document does not contain a date, the system should return an explicit unknown or request clarification rather than invent a plausible value to satisfy a required field.

Define the contract before prompting

For a support triage example, useful fields might be a stable ticket identifier, a category from a limited set, supporting text and a proposed next step. Do not allow arbitrary tool names or destinations when the workflow needs only a draft. The schema should reflect the application’s permitted operation, not every operation a model could describe.

Ollama documents providing JSON Schema through its structured-output interface and validating the returned result with a schema library. That mechanism helps constrain format. Your application still needs field validation, record ownership checks and a response to unsupported source claims.

Preserve types deliberately

A spreadsheet export may encode identifiers with leading zeros, dates as text and empty fields as blank strings. Do not coerce every numeric-looking value into a number before you know its meaning. The CSV converter deliberately preserves strings so the destination contract can decide which transformations are appropriate.

Normalize fields only where the rule is explicit. For example, a category may be case-insensitive, but a product code may not be. Document the transformation and keep enough original evidence to investigate a mismatch. A silent normalization can make an incorrect result look valid.

Bound repair and retry behavior

If a response violates the schema, you may retry with a clear validation error, but use an attempt budget and avoid including secrets in the repair prompt. Repeated attempts should not silently broaden the allowed schema or remove the difficult constraint. A persistent failure belongs in an operator queue or a rejected-task record.

Keep extraction separate from external actions. Validate the complete object before constructing a write request. If the model returns text that asks to bypass validation, treat that text as output data. No generated field should become executable code or a privileged instruction merely because it appears inside JSON.

Build a small regression dataset

Include normal examples, missing evidence, contradictory fields, malformed source text and an attempted instruction injection. Grade both the object and the downstream state. Confirm that an invalid record cannot produce a write even when another field contains a convincing explanation.

Track schema pass rate separately from factual accuracy. A new prompt that improves parsing while making more factual errors is not an unqualified improvement. Use the evaluation calculator for sample uncertainty and the agent evaluation guide for outcome-based grading. Your release criteria should describe the workflow’s real requirements, not simply “returns JSON.”

Implementation map

Sources and limits

Ollama structured outputs. No model-specific accuracy claim or complete API-request token estimate is implied. Documentation checked October 14, 2026. Recommendations and worked examples are editorial methods, not claims of a completed client engagement.