Structured AI Outputs: Check the Business Rule Before You Act

Imagine a small print studio that uses AI to turn customer emails into quote requests. The assistant returns a customer reference, a product code, a quantity and a finish. Every field is present. The quantity is a whole number, and the finish is spelled exactly as the software expects. There is just one problem: the selected finish is unavailable for that product. The proposed quote is tidy enough for the software to read and wrong enough to promise something the studio cannot make.

This is where a structured output earns its place and reaches its limit. A predictable response makes it easier for software to read what the AI proposes. Before the proposal becomes an email, an order or a reservation, the business still has to check whether its own rules allow it.

Separate format, evidence and permission

A schema describes what data should look like. The JSON Schema project’s object guide shows how to name properties, specify their types and require selected fields. A studio might require a product code and an integer quantity, for example. OpenAI’s August 2024 introduction to Structured Outputs makes a related distinction: a model can follow the supplied structure while still getting a value wrong. A correctly typed quantity can still be the wrong quantity.

A well-designed schema can express some rules, such as which finish names are accepted. The difficult rules often depend on information outside the response. Whether a finish is available for a particular product this week depends on the current catalogue. Whether the customer actually asked for it depends on their message. Whether the studio may send a quote automatically depends on the workflow’s approval policy. Those questions have different sources of evidence.

• Format: Is the quantity an integer, and are the required fields present?
• Evidence: Did the customer ask for this quantity and finish, and does the current catalogue allow that combination?
• Permission: Is this workflow allowed to send the quote, or does someone have to approve it first?

Keep these checks distinct in the workflow even if the same person owns all three. A missing field can often be corrected by asking for a better extraction. A catalogue conflict calls for a different product or finish. A missing approval means the action must wait. If the system labels every case ‘invalid’, the person resolving it has to rediscover which decision was never made.

Keep the decision next to the facts that support it

Return to the print studio. Suppose the email says, ‘Could you quote for 50 A3 prints in gloss, or 75 if the price works?’ A structured response containing quantity: 75 could satisfy the format and pass the catalogue check. It would still flatten a conditional request into a firm choice. The safer design is to preserve both quantities as alternatives, or ask a human to interpret the message before a single quote is prepared.

For a small pilot, require the assistant to retain the relevant part of the request alongside its proposed values. Give staff access to the original message as well, so they can verify that the excerpt is accurate and includes any qualification. Use the catalogue to check which combinations can be offered and its pricing rules to calculate the result. The AI can suggest which record to consult; the business should decide which record it trusts.

Check facts that can change as close as practical to the point of action. A quote drafted on Monday may be approved on Thursday, after the finish has been withdrawn. If the catalogue cannot be reached, leave the quote waiting for a check rather than assuming Monday’s answer still holds. An explicit reason such as ‘catalogue unavailable’ gives the next person something they can act on.

Test with plausible wrong answers

A demo with complete, straightforward emails will tell you whether the pieces fit together. It will not tell you how the workflow behaves when a proposal looks ordinary but violates a rule. Before you switch on automatic sending, run a few invented requests through the same process as a real order. Decide what should happen in each case before you see the output.

• Correct format, wrong combination. Use a real product code and a recognised finish that the product does not support. Expect a clear reason and no outgoing quote.
• Correct combination, ambiguous request. Supply two quantities with a condition. Expect alternatives or a request for clarification, rather than a guessed commitment.
• Correct proposal, stale information. Change the catalogue after drafting. Expect the final check to notice the change and send the quote back for review.
• Correct proposal, missing approval. Use a case that requires sign-off. Expect a saved proposal with no message sent until an authorised person approves it.

Check what happened outside the report as well as what the screen says. If a quote is marked as blocked, verify that the customer received no email and no reservation was made. If your workflow also reserves stock or books production time, plan separately for what to do when one action succeeds and another fails. The MaryChuks guide on recovering from partial workflow failures covers that next step.

Start with one consequential rule you can explain to a colleague. Write down its source, when it is checked and what happens if the system cannot verify it. Then try an example that obeys the schema but breaks the rule. If the proposal stops before it becomes a promise, you have tested something a neatly formatted response could never prove on its own.

Sources

• OpenAI, Introducing Structured Outputs in the API, 6 August 2024.
• JSON Schema, Understanding JSON Schema: Object, reference documentation.