Why does the model return JSON wrapped in extra text when I asked for JSON?

It wraps the JSON because a request for a shape is text in the prompt, not a constraint on the next token; the model can still emit a sentence before the opening brace or a code fence around it. The reliable cure is a strict validator and exactly one repair attempt that hands back the broken reply with the specific complaint, not a firmer request for cleanliness.

An instruction such as 'Reply with exactly this shape and nothing else' narrows the distribution of possible replies, but it does not set the probability of a wrapper to zero. Models are trained on conversations where an answer is introduced, so 'Here is the JSON you asked for:' is a plausible continuation even when the instruction says not to introduce it. A code fence is another wrapper of the same kind. The specification should still be given, and it should be a named shape with one filled example, because the example settles details that a field description leaves open: whether a missing identifier is null or an empty string, whether numbers are quoted, and whether the summary is a sentence or a phrase. But the example is doing two jobs, and only one of them is specification. It also makes the desired output more likely, which is not the same as making it certain.

Let $p$ be the share of answers that arrive broken and $F$ the share you are willing to leave broken. A repair pass has to fix $r = 1 - F/p$ of them. At $p=0.04$ and $F=0.008$, $F/p = 0.008/0.04 = 0.2$, so $r = 1 - 0.2 = 0.8$: one retry has to recover eighty per cent of the broken replies. That is the regime where a single retry with the specific complaint is worth building. At $p=0.20$ the same tolerance gives $F/p = 0.008/0.20 = 0.04$ and $r = 1 - 0.04 = 0.96$, so the retry would have to recover ninety six per cent. No ordinary retry does that, and the answer is to simplify the shape rather than to ask again more firmly. Complexity matters because every field and every optional branch is another way to be wrong. In the illustrative curves used for this calculation, a flat record breaks at about $0.004f$ and a nested shape with optional fields at about $0.004f(1+0.18f)$. At $f=6$ fields the flat rate is $0.024$, or 2.4 per cent, and the nested rate is $0.024$ times $2.08$, which is $0.04992$, or 4.992 per cent. At $f=12$ the flat rate is $0.048$, or 4.8 per cent, and the nested rate is $0.048$ times $3.16$, which is $0.15168$, or 15.168 per cent. The gap is the finding: the same information arranged with optional nested parts fails much more often. If a nested shape is genuinely needed, the usual repair is two calls, each asking for a flat part, rather than one call asking more insistently for the nested whole.

The natural guess is that a firmer instruction, or a regular expression that strips everything outside the first brace and the last, is enough. The firmer instruction is not useless, but it changes the break rate rather than eliminating it, and the arithmetic above is about what remains. The loose parse is the dangerous one. If the reply has no urgency field and the parser fills in three, or if it finds the word billing somewhere in a rambling sentence and calls that the category, the program has converted a visible failure into an invisible wrong answer. That is worse than a failed request because it looks like success and enters the rest of the system as data. A wrapper can be removed safely only when the removal is part of a strict parse that still checks the fields and the allowed values. If the parse has to guess, it has stopped validating and started inventing.

The mechanism stops being enough when $p$ is high enough that $r$ approaches one. At $p=0.20$ the repair would need to fix ninety six per cent of failures, which is beyond a single retry; the right move is a simpler shape, or two flat calls, not a longer complaint. It also stops being a content check. A reply can be perfectly formed and still be wrong: the category can be one of the allowed words and be the wrong category, the urgency can be a whole number from one to five and be badly judged, and an identifier can match the expected pattern exactly while referring to an order that does not exist. Any field that refers to something real has to be checked against the real records before it is used. Validating the shape catches a missing field and a value outside the allowed set; checking fields against the records catches an identifier that does not exist; a sample read by a person is what catches a plausible but wrong category. Those are separate checks with separate costs, and the structural check gives the most false comfort on the identifier case because the shape is exactly right.