UpdatedAug 6, 2026

Reliable Structured LLM Output

Question Variations

"What should happen when JSON parses but violates business rules?"
"Why is a schema not sufficient validation?"
"How would you use LLM invoice extraction without allowing uncertain output to trigger a payment?"

Why This Is Asked

This tests whether a candidate can turn probabilistic model output into a safe systems boundary. Interviewers assess schema constraints, independent business validation, failure handling, and human-review thresholds.

Key Concepts

Schema: Request machine-readable output with explicit types and enums.
Validation: Validate syntactic and business rules outside the model.
Recovery: Retry bounded repair attempts, then route uncertain cases for review.
Separation: Extraction output is a proposal, not authorization to execute.

Question Variations

“What should happen when JSON parses but violates business rules?”
“Why is a schema not sufficient validation?”
“How would you use LLM invoice extraction without allowing uncertain output to trigger a payment?”

Answers by Technology

+ Add Variant

System DesignImprove this answer ✏️

Expected Answer

I use schema-constrained output to reduce parsing failures, but treat it only as a proposal. Application code validates types, ranges, required relationships, supplier identity, and authorization before any payment action. A malformed result gets a bounded repair retry; an ambiguous or low-confidence invoice goes to review. This separates probabilistic extraction from deterministic financial control.

Why It Matters

Valid JSON can still contain an incorrect account or amount.

Common Mistakes

Trusting parsed JSON: Parsing is not business validation.
Executing without review thresholds: Uncertain model output becomes financial loss.

Follow-up Questions

What follows failed validation? (Answer: Repair retry or human review.)
Why separate execution? (Answer: The model is not an authorization system.)