Part 3 — Evaluation Foundations

Why valid JSON is not semantic correctness

Valid is not correct·Evaluation·6 min read

The single most important lesson in applied LLM evaluation, stated plainly and proven with this project's own data: constrained decoding guarantees the shape of an answer, never its meaning. A schema pass is a syntax check masquerading as a quality check — and mistaking one for the other is the field's most common, most expensive error.

If you take one idea from this entire book, take this one. Constrained decoding and schema validation can guarantee that every output is well-formed — parses, has the right fields, the right types, the allowed values. They guarantee nothing about whether the output is right. Valid JSON is a syntax check wearing the costume of a correctness check, and the whole reason the evaluation half of this book exists is that the two are constantly, disastrously confused.

What you will understand by the end

  • The two independent boundaries every structured output crosses: syntax and meaning.
  • Why constrained decoding solves the first and can't touch the second.
  • Why the mistake is so seductive — a schema pass feels like success.
  • The rule that follows: never let a validity check stand in for a correctness check.

Two boundaries, not one

A structured output has to clear two entirely separate bars before it's useful:

   model output
      │
      ├─▶ SYNTAX boundary   — does it parse? right fields, types, allowed values?   ✅ guaranteed by constrained decoding
      │
      └─▶ MEANING boundary  — does it say the RIGHT thing for this input?           ❓ guaranteed by nothing

Constrained decoding (from Prompts, schemas and structured outputs) forces the first boundary: the model can only emit tokens that keep the output schema-valid, so 100% of outputs parse. That is genuinely useful — it removes a whole class of integration bugs. But it operates entirely on shape. It has no view of whether the well-formed object means what the request needed.

Key idea

Structure and meaning are independent axes. Constraining structure moves you along one axis and not one inch along the other. A model can emit perfectly valid JSON — right fields, right types — that selects the wrong metric, the wrong filter, the wrong label. Valid ≠ correct.

The proof, in this project's own numbers

This is not a theoretical worry. It is the headline finding sitting in the dashboard:

Observed evidence

Across the six systems in this project, every single output was 100% schema-compliant JSON — every field validated, every value in range. Yet their semantic accuracy ranged from 45.5% to 95.5%. Structure was completely solved and told you nothing about which system was trustworthy: two systems with identical 100% validity were 50 points apart on meaning. See 100% valid sitting on top of a 50-point correctness gap →

One trial makes it concrete. For "Revenue by region last quarter", the correct answer is a breakdown of all regions. A raw model returned this — flawless JSON, wrong meaning:

{ "pattern_id": "top_n_by_metric",
  "metric": "revenue", "dimensions": ["region"],
  "sort": [{ "field": "revenue", "direction": "desc" }],
  "limit": 10 }

It heard "by region" as a ranking (top-10 by revenue) instead of a breakdown. The schema validator is delighted: every field is present and legal. The user gets the wrong rows. No amount of structural checking would ever catch this — only a check against what the answer should mean does. (See the same trial from the system side in The model is only one component.)

Why the trap is so seductive

The error is common precisely because a schema pass feels like success. The output is green, it parsed, it dropped cleanly into the next stage — every signal your tooling shows you says "good." The validity check is right there, cheap and automatic; the correctness check is somewhere else, harder, and easy to skip. So teams ship "100% valid" dashboards and quietly have no idea what their semantic accuracy is.

Watch out

A green "100% schema-valid" metric is not a quality metric, and treating it as one is how "our outputs are all valid" hides "half our outputs are wrong." Validity belongs on your dashboard — as a syntax health signal, next to and never in place of a separate semantic-correctness metric. If you can only show one number, it must be the correctness one.

The rule

Everything in Part 4 converges to a single operating rule: a validity check and a correctness check are different measurements, and you must run both. Constrained decoding earns you the syntax boundary for free — take it, it removes real bugs. Then evaluate meaning separately, against ground truth, with a scoring method that encodes the contract. Never let the first stand in for the second.

Mental model

Two independent boundaries: syntax (does it parse?) and meaning (is it right?). Constrained decoding guarantees syntax and says nothing about meaning. In this project, 100% valid JSON sat on top of 45–95% correctness. Measure validity if you like — but never call it quality, and always measure meaning separately.

Common mistakes

  • Reporting validity as accuracy. "100% schema-valid" is a syntax rate; it can coexist with 45% correct, as it did here.
  • Stopping at the schema check. A parse pass is the start of evaluation, not the end; the semantic check is the one that matters.
  • Assuming constrained decoding improved correctness. It improved validity; correctness is untouched and must be measured.
  • Only showing the green number. A dashboard of validity with no correctness metric is actively misleading.

Practical guidance

  • Always pair a validity check with a separate semantic-correctness check against ground truth; the second is the one you gate on.
  • Keep constrained decoding — it's free syntax-boundary insurance — but treat its 100% as a health signal, not a quality signal.
  • On dashboards, put validity and correctness side by side and labelled, so no one reads one as the other.
  • When correctness is hard to measure, that's a reason to invest in ground truth and scoring — not a reason to fall back on validity.

Summary

  • Every structured output crosses two independent boundaries: syntax (parses/validates) and meaning (is right).
  • Constrained decoding guarantees syntax and nothing about meaning — valid ≠ correct.
  • This project proves it: 100% valid JSON across all six systems, 45.5%–95.5% semantic accuracy.
  • Run both checks; gate on correctness, and never let a validity pass masquerade as quality.

Knowledge check

A team reports "we hit 100% structured-output compliance this quarter." Your one question back — and why?

"What's your semantic accuracy?" 100% compliance is a syntax rate — every output parses — and is fully compatible with a large fraction of those outputs being wrong (in this project, 100% valid coexisted with as low as 45.5% correct). The compliance number says the pipeline won't choke on malformed output; it says nothing about whether the answers mean the right thing, which is the number that actually decides quality.

Does adding constrained decoding to a system improve its accuracy?

It improves validity, not correctness. Constrained decoding guarantees the output is schema-shaped, eliminating parse/format failures — a real reliability win. But it operates only on structure; the model can still emit valid JSON that selects the wrong thing. Accuracy is a separate, semantic property you must measure against ground truth; a validity guarantee moves it by zero.

Related chapters