Validate, retry with the error and know when not to retry

The extraction tool already guarantees valid JSON. But the invoice total says 1,250.00 and the line items add up to 1,200.00. The schema does not see it; your code has to. The question is what to do when validation fails.

Validate in code

Consistency rules (line items add up to the total, dates fall within the period, a percentage is between 0 and 1) are deterministic checks: they belong in code, not in the prompt. That way they hold the same every time and produce a specific error.

A schema design trick helps the model leave the clue itself:

• extract calculated_total (the sum of the line items) next to stated_total (what the document says) and flag the difference;
• add a conflict_detected boolean when the source contradicts itself (two different issue dates on two pages).

The retry that corrects

A retry with error feedback sends the model three things:

1. the original document (so it can check against the source);
2. the failed extraction;
3. the specific error: which field, which rule it breaks and which value arrived. For example: “Field vat_rate must be a number from 0 to 1; received ‘21%’. Return the fixed field.”

“Be more accurate” or repeating the same request does not tell it what to fix. If the data may be missing, say so in the same message: “if the date is not in the document, return null”. Otherwise the retry pushes the model to invent.

When retrying does not help

Failure	Retry with feedback?
Format differs from the schema (04/03/26 instead of 2026-03-04)	Yes
Badly built structure, value in the wrong field	Yes
Line items do not match the total because of a misreading	Yes
The data is not in the document (contract with no due date)	No: record it as missing
The data is in another document that was not provided (an annex)	No: the input is missing, not the correction
API timeout	Retry with backoff and the same input, no feedback

A retry cannot create information the source does not have. Insisting until you get a value only produces an invented value.

Cap and exit

Set a small retry cap. Once it is exhausted, the document goes to human review with the errors attached. If something must not move forward without validation (a claim that failed twice is never auto-approved), it is blocked by a code gate that reads the validation status, not by an instruction to the model.

Measure the loop: first-attempt pass rate and pass rate after retry, per error type and over time. If almost all second attempts are caused by the same field, the problem is its description or the format instruction: fix it and measure again.

The loop in code review

In a CI review, the feedback loop is a different one: developers dismiss findings and nobody knows why. If each finding carries a detected_pattern field with the code construct that triggered it, you can group the dismissals. For example, you find that one pattern accounts for 61% of dismissals, almost all in test files, even though it is valuable in production code. The fix is an explicit criterion for that context, with examples, and measuring again; not switching off the whole category.

The typical traps

• Retrying without the document or without the specific error.
• Retrying for data that does not exist in the source.
• Putting the totals rules in the prompt instead of a validator.
• Retries with no cap, or that silently let the document through when they fail.

On the exam

Ask yourself where the missing information is. If it is in the document and came out wrong, retry with document, failed output and error. If it is not there, null or human review. If the scenario talks about dismissals that cannot be grouped, the answer is detected_pattern.