Rafael Costa had a folder of product reviews and a spreadsheet with empty columns. He had been asking his AI tool to summarize batches of reviews, reading the summaries, and typing the numbers into the sheet by hand. The summaries were good. The typing was the whole afternoon. What he had not tried was asking for the data itself, in the exact shape his spreadsheet expected, so that nothing between the model and the sheet required a human at all.

The Power of Structured Output

Most AI output is natural language text, and for most purposes that is what you want. But professional workflows frequently need data in specific formats: JSON for APIs, CSV for spreadsheets, XML for enterprise systems. Asking a language model to produce these formats seems strange until you try it, because we think of these tools as writing prose. They generate perfectly valid JSON, CSV or XML if you ask them clearly, and the request is no harder to make than any other.

The advantage is substantial. Instead of receiving prose that you then transform into a structured format by hand, you receive directly usable data. That single change is what makes automation possible: output feeds into your other systems without a human transformation step in the middle. A document processing workflow can extract data straight into your database. A research summary can produce structured findings that are ready for analysis the moment they arrive. This is the foundation on which AI-powered automation is built, and it is the difference between a tool that saves you writing time and one that removes a step from a process.

Generating JSON from AI

JSON, JavaScript Object Notation, is the most common structured format, and most modern APIs expect it. Getting reliable JSON out of a model comes down to three habits, and each one closes a specific gap where the model would otherwise have to guess.

Be explicit about format. Saying "Generate output in valid JSON format" is already better than saying nothing, because it rules out the prose wrapper. But naming the fields is considerably better: "Generate output as a JSON object with these fields: name (string), email (string), purchase_count (integer), last_purchase_date (string in YYYY-MM-DD format)". Notice that each field carries its type, and that the date field carries its format. Without the YYYY-MM-DD specifier you will get dates written several different ways across a batch, which is exactly the kind of inconsistency that breaks whatever consumes the output.

Provide a schema example. Show the exact structure you want rather than describing it. For the fields above, that means including a line like {"name": "John Doe", "email": "[email protected]", "purchase_count": 5, "last_purchase_date": "2026-03-01"} in the prompt. An example settles questions that a field list leaves open: whether numbers are quoted, how the date actually looks when written out, and what the key names are character for character. Models are extremely good at matching a demonstrated pattern, so demonstration is cheaper than explanation.

Specify what happens with edge cases. What if a field is missing or unknown? Should it be null, an empty string, or omitted entirely? Being explicit prevents variation between runs, and variation is what makes downstream code fail intermittently rather than obviously. An instruction as short as "If email is unknown, use null. If purchase_count is unknown, use 0." removes the ambiguity. With these three habits in place, the model produces valid JSON objects that match your schema exactly, and that output can be parsed programmatically and fed straight into your systems.

CSV Output for Data Analysis

CSV, comma-separated values, is the standard format for spreadsheets and data analysis, and it is the right target whenever the destination is a sheet rather than an application. Asking a model to extract data and format it as CSV is powerful for research, data synthesis and analysis workflows, particularly when the source material is a pile of unstructured text that nobody has time to read line by line.

The prompt looks like this: "Extract the following information from the text and format as CSV: product name, price, rating (1-5), number of reviews. Use this header row: product_name,price,rating,review_count". Two details in that prompt are doing the real work. The rating field carries its scale, (1-5), so the model does not invent a different scale halfway through the batch. And the header row is given verbatim, product_name,price,rating,review_count, which fixes both the column order and the exact machine-readable names, so that repeated runs append cleanly to the same file instead of producing a new column layout each time.

The output can be imported directly into a spreadsheet or passed on for further processing. This is where the value shows up on tasks like Rafael's: bulk extraction from documents, or synthesizing a body of research into rows you can sort and filter, without a person retyping anything in between.

Defining Clear Schemas in Prompts

The key to reliable structured output is a clear, unambiguous schema. A schema is the blueprint that defines what fields exist, what type each field is, and any constraints on the values those fields may hold. Once you are extracting anything more complicated than a flat list, writing the schema out becomes the main design task, and the prompt around it becomes almost incidental.

A schema with nesting looks like this: "Generate JSON with this structure: { customer: { name (string), email (string), phone (string) }, order: { order_id (integer), total_amount (number with 2 decimals), items: [{ name (string), quantity (integer), price (number) }] } }". This specifies three things at once: the object structure, the type of every field, and the nesting, including that items is an array of objects rather than a single one. It also pins precision where precision matters, with total_amount declared as a number with 2 decimals. Given this, the model generates JSON that matches the structure exactly.

You can go further and state validation requirements inside the schema itself: "email must be a valid email format", "phone must be 10 digits", "price must be greater than zero". The model will respect these constraints, which does two useful things. It improves the output directly, and it forces you to decide what your rules actually are before the data arrives rather than discovering them later when something rejects a row. Constraints you can state in a prompt are also constraints you can check for afterwards, which is the subject of the next section.

Handling Formatting Errors

Sometimes the output is almost valid: a trailing comma, a missing field, a number that arrived as a string. Almost valid is worse than obviously wrong, because it passes a glance and fails a parser. Four techniques minimize it, and they compound, so use them together on anything that runs unattended.

• Give explicit examples of valid output. Show what a correct result looks like, and show several examples if your data has variations, so the model has a pattern to match rather than a description to interpret.
• Add validation instructions. Include something like "Double-check that the JSON is valid before sending it" or "Verify all required fields are present and in the correct format", which prompts a check before the answer is produced rather than after you have already consumed it.
• Add error recovery instructions. "If you cannot generate valid output, explain why instead of generating invalid output." This is the single most valuable line in a production prompt, because it converts silent garbage into a readable message and prevents malformed data from breaking downstream systems.
• Test before deployment. When structured output goes into production, always validate the first few outputs against your schema exactly, field by field, rather than assuming that a correct-looking first result means the pipeline is sound.

The order matters. Examples and schema precision prevent most errors, validation instructions catch a portion of the rest, error recovery contains the failures that survive, and testing tells you which category you are actually in. A pipeline with all four is one you can leave running; a pipeline with none of them is one you will be debugging from the far end, where the symptom is a broken report rather than a malformed field.

Anti-Patterns

• Asking for "JSON" and nothing else. Requesting the format without naming the fields, their types and their key names leaves every structural decision to the model, so two runs produce two different shapes.
• Describing the schema instead of showing it. A field list answers fewer questions than one line of example output, which settles key names, quoting and date formatting at a stroke.
• Leaving unknown values undefined. If you have not said whether a missing email should be null, an empty string, or omitted, you will get all three across a batch.
• Omitting format specifiers. Dates without YYYY-MM-DD, ratings without their (1-5) scale, and amounts without a decimal precision are common sources of inconsistency.
• Letting the header row float. Not giving the exact CSV header means column names and column order can change between runs, so files that should append cleanly do not.
• Accepting invalid output silently. Without an error recovery instruction, a model that cannot comply will often produce something malformed rather than saying so, and the failure surfaces much later.
• Going to production on one good result. A single valid output proves the prompt can work, not that it works reliably.

Practice Prompts

Adapt the bracketed sections. The first two are the workhorses; the rest harden a prompt that already produces roughly the right thing.

• "Extract the following information from the text and format as JSON matching this schema: [YOUR SCHEMA]. Here is an example of valid output: [EXAMPLE]"
• "Extract the following information from the text and format as CSV: [fields, with scales and units]. Use this header row: [exact_header_row]"
• "Generate output as a JSON object with these fields: name (string), email (string), purchase_count (integer), last_purchase_date (string in YYYY-MM-DD format)."
• "If a field is unknown, use null. If a count is unknown, use 0. Do not omit fields."
• "Double-check that the JSON is valid before sending it, and verify all required fields are present and in the correct format."
• "If you cannot generate valid output, explain why instead of generating invalid output."
• "Here is my schema and a few sample records: [schema and records]. Identify any field where the type, format or handling of missing values is ambiguous."

Reflection

Build one small pipeline end to end rather than reading about several. Choose a text source you already deal with: customer emails, research papers, product reviews, or meeting notes. Decide what structured data would actually be valuable to pull out of it, which is a harder question than it sounds, because the temptation is to extract everything rather than the few fields you would genuinely use. Then design a clear JSON or CSV schema for those fields, giving each one a type and, where relevant, a format or a scale.

Write the extraction prompt in the form "Extract the following information from the text and format as JSON matching this schema: [YOUR SCHEMA]. Here is an example of valid output: [EXAMPLE]", then feed it your source text and inspect what comes back. Does it produce valid structured output, field for field? Where it does not, resist the urge to fix the output by hand; fix the schema or the example instead, and run it again. Refine until it works reliably across several different inputs, including one awkward one, because reliability across variation is the only version of "working" that automation can use.

Glossary

• Structured output: model output produced directly in a machine-readable format such as JSON, CSV or XML rather than in prose.
• JSON (JavaScript Object Notation): the most common structured format, used by most modern APIs, supporting typed fields and nested objects and arrays.
• CSV (comma-separated values): the standard flat, tabular format for spreadsheets and data analysis.
• Schema: the blueprint defining what fields exist, what type each one is, and what constraints apply to their values.
• Format specifier: an instruction fixing how a value is written, such as a date given as YYYY-MM-DD, a rating on a (1-5) scale, or an amount as a number with 2 decimals.
• Header row: the exact first line of a CSV, such as product_name,price,rating,review_count, which fixes column names and order.
• Validation requirement: a rule stated in the schema, such as a valid email format or a phone of 10 digits, that the output must satisfy.
• Error recovery instruction: a standing instruction to explain the problem rather than emit invalid output when the model cannot comply.

Related Lessons

• System Prompts & Persona Design covers output format specifications at the level of a whole conversation, so a schema does not have to be restated in every message.
• Few-Shot Learning & Examples explains why a demonstrated example of valid output outperforms a description of it.
• Iterative Refinement is the method for tightening a schema that is producing almost-valid results.
• Prompt Libraries & Version Control is where a working extraction prompt should live once you have built it, since schemas are exactly the kind of asset worth reusing.
• Anatomy of an Effective Prompt covers the surrounding components that make the extraction instruction land.

Closing

Structured output engineering unlocks the integration potential of these tools. By specifying clear schemas in your prompts you let the model generate data in formats that feed directly into your other systems, which transforms AI from something that produces prose you then process by hand into something that produces data you can automate with. The investment in designing clear schemas pays dividends across many later applications: once you have engineered one good JSON extraction prompt, you can adapt it for similar tasks rather than starting over. Structured output is the bridge between a model's language capabilities and your organization's data systems.

Key Takeaways

• Language models generate valid JSON, CSV and XML reliably when asked clearly, which removes the manual transformation step between AI output and your systems.
• Name the fields and their types, do not just ask for the format. Add format specifiers such as YYYY-MM-DD wherever a value could be written more than one way.
• Show an example of valid output. It settles key names, quoting and formatting more efficiently than any description.
• Decide explicitly what happens to unknown values, whether null, empty or omitted, before the first batch runs.
• For CSV, supply the exact header row so column names and order stay stable across runs.
• State validation rules in the schema, such as a valid email format or a 10 digit phone, and precision such as 2 decimals.
• Include an error recovery instruction so failures arrive as explanations rather than as malformed data, and validate the first outputs in production field by field.

Frequently Asked Questions

Why give a schema example when I have already listed the fields and types? Because a field list leaves genuine ambiguity that an example resolves instantly: whether numbers are quoted, exactly how a date is rendered, and the precise spelling of each key. Models match demonstrated patterns very effectively, so one line such as {"name": "John Doe", "email": "[email protected]", "purchase_count": 5, "last_purchase_date": "2026-03-01"} does more work than a paragraph of description.

Should I use JSON or CSV? Follow the destination. JSON is the right choice when the data is going into an API or application code, especially if records nest, since it carries types and nested arrays naturally. CSV is the right choice when the data is going into a spreadsheet or an analysis tool and the shape is flat and tabular. XML is what you use when an enterprise system on the other side expects it.

What do I do about output that is almost valid? Treat it as a schema problem rather than a cleanup problem. Add explicit examples of valid output, add validation instructions asking the model to check before sending, and add an error recovery instruction so it explains itself rather than emitting something malformed. Then re-test, because a near-miss that you fix by hand once will recur on every run you are not watching.

How much testing is enough before I automate with this? Validate the first few outputs against your schema exactly, and make sure your test inputs include the awkward cases: a record with a missing field, an unusually long one, something outside the expected range. A prompt that succeeds only on clean inputs will fail quietly the first time real data arrives.