AI JSON, Forms, and Extraction: A Four-Gate Trust Checklist
A better prompt will not make structured output safe; use four gates: schema validity, field-level accuracy, confidence calibration, and a fallback that keeps users out of trouble.
| By | Prompt & Product — Newsroom |
|---|---|
| Filed | 10 September 2026 |
| Read | 3 MIN |

The prompt is not the product
When an AI fills a form, the user sees a name, a date, a phone number, and a button. If the model guesses, the product has made a decision. Structured output evals need to behave like a release gate, not a vibe check.
The first failure is shape: a trailing comma, a missing brace, a field that should be a number but is a string. These failures are easy to catch, and they should stop the release before anyone argues about meaning.
Valid JSON is not correct JSON. A form can be perfectly typed and still wrong: the street number is in the city field, the date is in the wrong century, the extracted amount is missing a decimal. Data extraction accuracy needs field-level checks, not just a green parse icon.
In WordLift's early testing, adding structured data made GPT-5 snippets more consistent and more contextually relevant. That is useful evidence that structure helps, not proof that every field is right.
Ship only after four gates pass
Keep the checklist short enough that a designer can run it in a review. Each gate should answer a question a user would ask after the fact: Did it parse? Did it mean what it said? Did it know what it did not know? What happens when it is wrong?
- Gate 1: Schema validity. Run a sample response through a parser and schema check; reject it if either fails. In Promptfoo, the is-json assertion can verify that an LLM response is valid JSON and can also validate that response against a supplied JSON schema. Promptfoo's transform directive can parse JSON output before assertions run, so testers do not need to repeat JSON.parse in every assertion.
- Gate 2: Field-level accuracy. Give each required field at least one custom check, such as format, range, or allowed value. Promptfoo's javascript assertion type allows testers to run custom JavaScript checks against individual fields in a JSON response.
- Gate 3: Confidence calibration. Document the confidence threshold, the labeled examples used to set it, and the review path for weak records. A designer should be able to point to the threshold in the release notes.
- Gate 4: Safe fallback. Send a low-confidence sample through the flow and confirm it reaches review, not auto-save.
Calibration needs a small labeled set. WordLift's two-step process yielded 97 URL records with annotated key fields. WordLift applied a Gemini 2.5 Pro-powered LLM-as-a-Judge method, a model-scored review, to extract three main metrics from its URL dataset. The tool matters less than the measured gap between what the model says and what a person confirms.
The gates are ordered because each one changes the next question: schema failure makes field accuracy meaningless, unmeasured field accuracy makes confidence a guess, and uncalibrated confidence lets the review queue miss the records that need it.
The fallback is where trust is built
Low confidence is a state the interface must own, not a bug to hide. A user who sees needs review understands the system has limits. A user who discovers a wrong phone number in a saved record learns the opposite. The redesign starts by making the uncertain record visually distinct: a badge, a muted border, a field-level note that says which value is weak.
If a model truncates source text, the product must not pretend the record is complete. GPT-5 has an internal wordlim directive that dynamically limits the amount of webpage text that can be included in a generated answer.
The correction flow should preserve the model's useful work. If the street address is right but the ZIP code is wrong, the human should fix one field, not re-enter the whole form. The product earns trust when the system admits uncertainty, the user keeps control, and the data path remains auditable.
For extraction features, the safest default is a draft, not a commit. The model proposes; the product verifies; the user approves. A confidence threshold that is too high drowns the team in review; one that is too low ships errors. Put that threshold in the spec, and revisit it when the acceptable error rate changes.