The pipeline

When a reply arrives, it goes through four steps. If any step fails, you know which one, and you have a message that says why.

Step 1: extract. Find the JSON inside the text. The function extract_json removes a code fence if there is one, finds the first {, and then walks forward counting braces until the object closes. It ignores braces that are inside quoted text. For example, in Sure! {"a": "x } y"} thanks the brace inside "x } y" does not end the object, and the function returns {"a": "x } y"}. If the object never closes, the reply was probably cut off, and the function says so.

Step 2: tidy. light_repair removes one harmless slip: a comma just before a closing brace or bracket. It does nothing else, on purpose. Do not be tempted to repair more. Turning "urgent" into "high" for the model hides the model's mistake, and a wrong value that looks valid is much worse than an error you can see.

Step 3: parse. Python's json.loads turns the text into a dictionary. If the text is not valid JSON, it reports the position of the problem, and we put that position into the error message.

Step 4: validate. The Ticket class checks every field. We turn Pydantic's error into one clear sentence per problem, for example:

JSON did not match the schema: field 'priority': Input should be 'low', 'normal' or 'high'.

Each failure also gets a kind: no_json, truncated, bad_json or schema. The message is written so that it can be sent straight back to the model.

What code can fix, and what the model must fix

The eight mistakes in the picture are the ones the example code tests. Prose around the JSON, a code fence and a trailing comma are fixed by the code for free. A wrong enum value, a wrong type, a missing field, a cut-off reply and a refusal all mean the content is wrong or absent, so only the model can produce it again.