You will be able to write a JSON schema for the output you need and get it through a provider's structured output feature.
If your code is going to use what a model returns, the output needs the same shape every time. You get that by describing the shape exactly, as a JSON schema, and then making the model stick to it.
Priya works on a team that handles customer feedback, and she is building code that uses a model to summarise it. Her team lead wants more than a one-sentence summary. He wants the feedback sorted into a sheet with 3 columns: whether the customer was happy, the issues they raised, and a summary. He also wants to be able to filter for angry customers in Tampines on a Monday morning.
Priya's first attempt asks the model to "reply in JSON with sentiment, issues and summary". It mostly works, but the replies vary. One gives sentiment as "Negative", another as "negative", another as "mixed, leaning negative", and one wraps the whole object in an opening sentence announcing the JSON she asked for. Her code breaks on each of these. Asking in plain words gets you roughly the right output, and every variation in label case, every hedged label and every stray sentence is something your code can trip on.
JSON is a plain text format for structured data: named fields with values, grouped inside curly braces. A field looks like "sentiment": "negative". Almost every programming language can read it. A JSON schema describes what a valid JSON object looks like for your purpose: which fields it has, the type of each field, which fields are required and which values are allowed.
Priya's schema has 3 fields. Sentiment is a string that must be one of a fixed set of labels. Issues is a list of short strings. Summary is a string. All 3 are required, and no other fields are allowed.
Start by deciding which fields your code or your reader will actually use, and keep that list small. Every extra field is another thing for the model to fill in and another thing that can go wrong, so ask only for fields that will be used. Then write each field's name and type, mark which fields are required, list the allowed values, and state that no other fields are allowed.
Writing the schema forces decisions you would otherwise leave to the model. When the customer raised no issues, the issues field should be an empty list. It should not be a missing field or the word "none". How a mixed review is handled is also your decision, and the schema records it.
An enum is a field that may only hold one of a listed set of values. Priya makes sentiment an enum of positive, negative and mixed. A capitalised "Negative" or a hedged "mixed, leaning negative" can no longer appear, and her filter has exactly three cases to handle. If you took the course "Automate your work with AI and no-code tools", you met the same idea in lesson 5.2, "Make the model pick from a fixed list".
Use an enum for every field your code makes a decision on: categories, priorities, departments, yes or no flags. Your code then has a fixed, known number of cases to handle. Free text is fine for fields a person will read, such as the summary. When inputs can be ambiguous, add a fallback value such as "unclear" to the enum, so the model is never forced to pick a wrong label.
Many providers offer a structured output mode. You pass the schema with the request, and the provider constrains the reply to match it. The name varies by provider: structured outputs, a response format, JSON mode, or a tool with a fixed input schema. Read your provider's documentation for the exact name and for which schema features it supports, because support varies.
Use this mode wherever your provider offers it. It removes a class of failures: stray sentences around the JSON, missing quote marks, invented fields and labels outside the enum. Plain JSON mode, where a provider offers it, is weaker. It guarantees valid JSON but does not guarantee JSON that matches your schema, so check what your provider's mode actually promises.
A reply can match the schema perfectly and still be wrong, because the structure is guaranteed and the judgement is not. A complaint about a driver who never showed up can come back with sentiment set to positive, in flawless JSON.
Your code must still validate every reply, even with structured output switched on. Parse the reply first. Then check it against the schema with a validation library in your language. Then add checks for things a schema cannot express, such as these:
Is the summary under 25 words? Is the issues list empty when sentiment is positive but the summary mentions a refund? Does any field contain text copied from your system prompt?
Checks like these catch a share of wrong values, and some will still get through. Catching the rest is the job of test sets, covered in module 7, "Test the output before you trust it".
The habit to build is to treat the model's reply as input to your program, and to have your program check input before trusting it. Lesson 4.3, "Check every argument before you act on it", applies the same habit to tool calls, and lesson 2.3 covers what to do when validation fails.
First you need a schema to validate against, and the activity below has you write and test one for Priya's feedback summaries.
Write a JSON schema for feedback summaries with sentiment as an enum, a list of issues and a one-line summary. Then try it in a playground.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).