How do you validate and repair structured LLM output at runtime?
480 views
76 of 83
1
The problem
Question presented to candidate:
"We extract invoices with an LLM and write them straight into our billing database. Even with strict JSON output we occasionally store a total that does not add up or a customer id that does not exist. Design the runtime layer that validates the model's output and repairs it, and tell me when you would stop trying."
What a strong answer should cover:
Layers of validation in order: stop reason (refusal, max_tokens truncation), parse, schema (types, enums, required keys), semantic rules (cross-field arithmetic, ranges, dates) and referential checks (does this id exist, does this user own it)
A repair ladder from cheap to expensive: deterministic local fixes that never invent values (strip code fences, trailing commas), then a re-ask that sends the previous output plus precise, path-named errors, then a deterministic fallback (review queue, safe default, partial result flagged)
Bounding: one or two re-asks at most, because a value the model cannot know (a missing id) will only be re-invented; never accept on timeout and never auto-close truncated JSON
Treating the output as untrusted input: validation is also a security boundary, since injected content can steer field values
Metrics: first-pass validity, repair rate, fallback rate and errors per field, used both to fix the schema or prompt and as an early drift alarm after a model or prompt change
Clarifying questions expected:
Does the provider support strict schema output for this model, so shape errors are already gone and the layer can focus on meaning?
What is the cost of a wrong record compared with a delayed one (that sets how quickly we fall back to a human)?
Can the model be given the lookup it needs (for example a customer-search tool) instead of being asked to recall ids?
Code / implementation expected: Yes โ a validate-then-repair loop with a retry bound and a fallback, using Zod, Pydantic or hand-written checks.
validation
structured-output
repair-loop
reliability
2
Try it yourself
Sketch your approach before you read the solution. That is what the interview tests.
Stuck? Get a hint.
A short nudge toward the approach. It will not give the answer away.
3
Solution
Target Audience: Engineers putting LLM output into systems of record (databases, billing, tickets) who need a runtime layer that catches bad output and fixes what can be fixed.
Difficulty: Hard
Verified with: Node 22.22.0 and Python 3.12.3 (two programs: the validate-repair-fallback pipeline and the truncation demo). Library and provider behaviour is cited inline with the source, checked October 2026.
How to read this doc: Every idea is explained in plain language first, then tagged with ๐ Interview term: so you also learn the words an interviewer expects. All program output shown was produced by actually running the examples; the Verified section quotes it in full.
1. Why This Even Matters โ A Story First
A bank does not trust a cheque because it is printed on the right paper. A clerk checks it in layers. Is it a cheque at all, or a torn half? Are all the
The solution is hidden so you can try first
17 min read ยท 12 sections
4
Read the code
Validate, repair locally, re-ask with errors, fall back: an invoice pipeline