Validation and Retry Loops

Programmatically validating structured output against a schema and re-prompting with the specific error, not a generic retry.

Prompt Engineering·Lesson 5 of 6·8 min

Even with prefill and schema-constrained output, structured responses can still fail validation: a required field missing, a value out of range, a type mismatch after JSON parsing succeeds. Validation/retry loops handle this failure mode programmatically instead of hoping the first response is correct.

The pattern

The loop is: generate a response, validate it against the schema (or business rules) in code, and if validation fails, send a new request that includes the specific validation error and asks the model to correct it — not just "try again." A generic retry with no information about what was wrong tends to reproduce the same mistake, because nothing about the input or the model's reasoning has changed; the model has no new information to act on. Including the exact validator error (for example, "field 'severity' must be one of low/medium/high, got 'urgent'") gives the model something concrete to fix, and works far more reliably.

A well-built loop also caps the number of retries (commonly 2-3) and has a defined fallback path when validation keeps failing — surfacing to a human, logging for review, or falling back to a safer default — rather than retrying indefinitely.

Where this fits with other techniques

Validation/retry is not a replacement for schema-constrained output or prefill; it is a second layer on top of them. Constrained output and prefill reduce the rate of malformed responses; validation/retry catches the ones that still get through, including cases where the JSON is syntactically valid but semantically wrong (a number out of a valid range, an enum value that doesn't exist, a date in the past for a field that must be in the future). Schema constraints alone typically cannot express those business-rule-level constraints, so code-level validation is still required even with a perfect schema mechanism.

Exam trap A scenario shows a retry loop where, on validation failure, the code simply re-sends the exact same prompt again (sometimes with a slightly higher temperature, hoping for a different sample). This is presented as a fix for occasional malformed output. The correct critique: this is a generic retry with no error feedback, and while it may occasionally succeed by chance, it does not reliably converge, especially if the mistake is systematic (e.g., the model consistently misunderstands a field's constraint). The right fix is to include the specific validation error text in the retry prompt.

An API integration asks Claude to produce a JSON object with a discount_percent field that must be between 0 and 50. On one run the model returns 75. A generic retry ("please try again, make sure the output is valid") has no guarantee of avoiding the same value or a similarly out-of-range one. The correct approach: the validator catches the range violation, and the retry prompt explicitly states "discount_percent must be between 0 and 50; you returned 75, which is out of range — provide a corrected value." This directly tells the model what was wrong and what constraint to satisfy, which converges far more reliably than an unspecific retry.

Where to put retry logic in the message history

A retry is a new turn in the conversation, not a replacement of the previous one: the failed assistant response and the validation error both get appended as additional messages (assistant turn with the bad output, user turn with the specific error and a request to correct it), and the corrected response comes back as the next assistant turn. This preserves full context for debugging and lets the model see its own prior attempt alongside the correction, which is generally more effective than silently discarding the failed attempt and re-asking from scratch with no memory of what went wrong.

Retry loops and cost

Every retry is a full additional API call, so a validation/retry loop is not free, and an exam scenario may ask you to weigh it against the alternative of investing more in the initial prompt (better schema, more few-shot examples, prefill) to reduce how often retries are needed in the first place. The two are complementary, not competing: a well-designed initial prompt lowers the retry rate, and the retry loop exists to catch the remaining tail of failures, particularly ones caused by ambiguous or unusual inputs where no amount of upfront example curation covers every edge case.

Retry loops vs. multi-pass review

Don't confuse a validation/retry loop with a multi-pass review setup. A retry loop reacts to an objective, programmatic failure (schema violation, out-of-range value) and asks for a targeted correction. Multi-pass review is a separate, independent evaluation of otherwise valid output, checking for qualities a schema can't check — tone, correctness of reasoning, completeness — using a second call rather than code-level validation. A single system can reasonably use both: validate structurally with a retry loop, then send passing output through a separate review call for qualitative checks.

Try it

Build a small validation/retry loop around a structured-output call: define a schema with at least one business-rule constraint a JSON schema can't express (e.g., a numeric range or a cross-field consistency rule), validate the response in code, and on failure re-prompt including the exact validator error message as a new user turn appended after the failed assistant turn. Compare convergence rate against a version that just resends the same prompt on failure, over 10 forced-failure test cases, and cap both at 3 retries with a logged fallback on exhaustion.