LLM Structured Output

By Ai Flowi · Published 10 October 2026

LLM structured output is a model response organised into predefined fields rather than unrestricted prose. It is useful when later processing expects named values, such as a document identifier, an extracted clause and an evidence status. Matching a structure does not establish that the extracted facts are true.

Design the fields around what the source can actually support. Include a way to represent unknown information, then check both the output’s shape and the evidence behind its values. A complete-looking object should not be required when the source is incomplete.

Extraction, parsing and validation

Extraction asks a model to interpret source text and return selected information. Parsing turns a representation, such as JSON object text, into data. Structural validation checks required keys and allowed types. Semantic validation checks whether the values satisfy the task and are supported by the source.

These stages answer different questions. A parser may accept a perfectly formed object containing a fabricated clause. A supported excerpt may still arrive with a missing field. Treat malformed output and unsupported facts as separate failures so the operator knows what needs correction.

The JSON String Parser reference owns conversion of existing object text. This page concerns the earlier model-extraction contract and the checks required before using its result.

A document-evidence schema concept

Suppose a reviewer asks whether an approved document contains a notice requirement. The desired record should preserve the source identifier and the exact relevant excerpt, or explicitly report that the supplied source does not answer the question. Do not force the model to fill in a plausible notice period.

This is a conceptual output contract. It is not the native output_schema table’s import format. Decide the real required fields and allowed representations in your application, then inspect the editor’s schema controls before entering them.

Missing and unknown are different. A missing evidence_status violates this contract. An explicit unknown status can be a valid result when the source lacks the requested information. Empty text, null and omitted keys are not automatically interchangeable; choose the representation your downstream check understands.

Structured Output in AI Flowi Workflow

The Structured Output entry in the component catalogue owns the generation interface used below.

The extraction-specific decision is which fields allow a reviewer to distinguish absent evidence from a malformed response, before any record reaches downstream processing.

A proposed extraction setup

example configuration, not a recorded test

Structured Output
input_value: the synthetic document identifier and source text
system_prompt: Extract the relevant notice clause from the supplied source.
               Use unknown when evidence is absent. Preserve source wording.
schema_name: document_evidence
output_schema: configure the reviewed field contract in the editor
model: select your configured provider model

Arrange model credentials using the models and variables reference, with your own provider account, API key and separate provider billing.

The intended result is a data record suitable for inspection, not an invented extracted clause. No output from this configuration was recorded. Structured Output is documented in the catalogue; not production-tested by Ai Flowi.

How do I validate the shape and then the meaning of structured output?

1. Check the record structure. Confirm required keys, expected value types and allowed status values. Reject a response that cannot satisfy the data contract.
2. Check source identity. Confirm the identifier belongs to the supplied authorised document rather than another context.
3. Check evidence support. Locate the excerpt in the source and examine the surrounding qualifier. A real excerpt can still be interpreted too broadly.
4. Check unknown and conflict handling. Keep unresolved information visible. Do not treat unknown as a successful positive finding.
5. Permit downstream use only after acceptance. Rejected or uncertain results should stay outside the persistence or action path.

If extraction includes amounts or durations, use a deterministic calculation after verifying the extracted values and units. A numerical value can be correctly typed while referring to the wrong currency, reporting period or clause. No accuracy rate or automatic factual-validation guarantee is claimed here.

Extraction cases that a valid object can fail

Use an invented source sentence: “Archived records require notice; current records do not.” A record that extracts only “records require notice” has discarded the category boundary. The excerpt field should preserve the relevant wording, and the supported finding must name which records it concerns. Finding the shortened phrase inside the document is not enough to validate the broader conclusion.

Next supply a sentence that refers to an attached schedule but omits the schedule itself. The output should retain the unresolved question rather than infer its duration from another document or prior conversation. Keep the document identifier fixed to the packet provided. If the model returns an identifier from an earlier task, reject the record even if the extracted wording sounds plausible.

For a numerical field, supply two synthetic figures with different units, such as days in one clause and months in another. Inspect the value together with its unit, qualifying category and source locator. A downstream calculation needs that context; parsing the digits successfully cannot establish that the model chose the applicable clause. If a needed passage was truncated before generation, mark the record incomplete and repeat extraction with the reviewed source context. Do not repair the missing evidence by editing the output into a convincing object.

Route an accepted decision separately from extraction

Use the Condition interface for a proposed status gate: set key_name=evidence_status, operator="equals" and compare_value=supported only after the evidence checks above.

A record marked supported with an empty clause_excerpt contradicts the proposed evidence contract. Reject that combination before routing rather than trusting the status alone. Conversely, an unknown result with a clear unresolved_question can be structurally acceptable while remaining outside the accepted-finding branch.

Once the extraction passes its evidence checks, use the webhook-to-Sheets tutorial for destination configuration and row mapping.

Common mistakes and related concepts

Do not make every field mandatory when the source cannot supply every answer. Do not equate parseable JSON with verified evidence. Do not write uncertain results to a sheet and hope a later reviewer will notice the uncertainty.

Function calling requests an operation, while structured output organises an answer. AI agent state uses fields to record progress and unresolved work. Agent guardrails adds permission and review boundaries around downstream actions. Existing use cases provide documented starting examples with their own test scope.

Workflow usage

Plans: Go from USD8/month billed yearly (USD10 monthly), Plus from USD16 (USD20 monthly), Pro 100 from USD80 (USD100 monthly), Pro 200 from USD160 (USD200 monthly) and Pro 500 from USD400 (USD500 monthly), with 5,000 to 250,000 Flowi Tokens/month and top-ups; 1 token per node run; third-party API and model usage is not included.