You will be able to define a JSON schema for the output you need and use a provider's structured output feature to get it.
Priya's team lead wanted more than a sentence. He wanted the feedback sorted into a sheet, with one column for whether the customer was happy or not, one for the issues raised and one for the summary, so he could filter for angry customers in Tampines on a Monday morning. Priya's first attempt asked the model to "reply in JSON with sentiment, issues and summary". It mostly worked. Then one reply called the sentiment "Negative", another "negative", another "mixed, leaning negative", and one wrapped the whole object in a sentence that began "Here is the JSON you asked for". Her code broke on each of them.
Code needs output that has the same shape every time. That means describing the shape exactly, and then making the model stick to it.
JSON is a plain text format for structured data: named fields with values, such as `"sentiment": "negative"`, grouped inside curly braces. Almost every programming language can read it. A JSON schema is a description of what a valid JSON object looks like for your purpose: which fields it has, what type each field is, which fields are required and what values are allowed.
For Priya's summaries, the schema says three things in plain words. There is a field called sentiment, which is a string and must be one of a fixed set of labels. There is a field called issues, which is a list of short strings. There is a field called summary, which is a string. All three are required, and no other fields are allowed.
Writing that down forces decisions you would otherwise leave to the model. What should issues be when the customer raised none? An empty list, not a missing field and not the word "none". What happens with a mixed review? You decide, and the schema says so.
An enum is a field that may only hold one of a listed set of values. Priya's sentiment field became an enum with three values: positive, negative and mixed. Now the model cannot return "Negative" with a capital letter or "mixed, leaning negative", and her filter has exactly three cases to handle.
Use an enum for every field your code makes a decision on: categories, priorities, departments, yes or no flags. Free text is fine for fields a person will read, like the summary. If you took 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. Add a fallback value such as unclear when inputs can be ambiguous, so the model is never forced to pick a wrong label.
Many providers offer a structured output mode. You pass your schema with the request, and the provider constrains the model's reply so it matches the schema. Depending on the provider it may be called 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.
Where it is available, use it. It removes a whole class of failures: stray sentences around the JSON, missing quote marks, invented fields and labels outside your enum. Plain JSON mode, where offered, is weaker. It guarantees valid JSON, but not that the JSON matches your schema, so check what your provider's mode actually promises.
Keep the schema small. Every field you add is another thing the model has to fill in and another thing that can go wrong. Ask only for fields your code or your reader will use.
Here is the trap. A reply that matches the schema perfectly can still be wrong. A complaint about a driver who never showed up can come back with sentiment set to positive, in flawless JSON. The structure is guaranteed. The judgement is not.
So your code still validates every reply, even with structured output switched on. Parse it, check it against the schema with a validation library in your language, and then add checks for the things a schema cannot express. Is the summary under 25 words? Is the issues list empty when the sentiment is positive and the summary mentions a refund? Does any field contain text copied from your system prompt?
These checks catch a share of wrong values, but not all of them. Catching the rest is the job of the test sets in module 7, Test the output before you trust it. For now, the habit to build is that the model's reply is input to your program, and your program checks input before trusting it. Lesson 4.3, Check every argument before you act on it, applies the same habit to tool calls.
Lesson 2.3 deals with 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 test it in a playground.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).