ValidationTutorial6 min

Validate OpenAI model output before writing to the database

A safe implementation pattern for keeping AI output useful without letting invalid data pollute production records.

Real workflow example

An extraction returns a deadline, buyer, score, and recommendation, but the deadline is not a valid ISO date and the recommendation references a missing certificate.

Parse the model output with a schema. If validation fails, create a review task containing the raw response id, validation errors, and the source tender. Do not write to the final assessment table.

Bad output becomes visible work instead of corrupt production data. The operator can repair the record and the team can improve the prompt or source parser.

Implementation approach

This guide is anchored in OpenAI structured outputs guide. Use the official API behavior as the boundary, then design the surrounding product state so the feature can be reviewed, retried, and improved.

Define a schema that mirrors the fields your UI and database can actually support.
Parse model output into that schema and fail closed when required fields are missing.
Write valid results into a draft or review table before finalizing production state.
Show validation errors to an operator when the model cannot complete the record safely.
Track rejection reasons so the prompt, source data, or schema can improve.

Fail closed before write

const parsed = TenderFitSchema.safeParse(modelOutput);

if (!parsed.success) {
  await db.reviewTask.create({
    data: {
      type: "ai_validation_failed",
      sourceId: tender.id,
      errors: parsed.error.flatten(),
    },
  });
  return { status: "needs_human_review" };
}

await db.tenderAssessment.create({ data: parsed.data });

Field notes

Structured output is the start of reliability, not the end of it.
Application validation should run before database writes, emails, notifications, or status changes.
Rejected output still has value when it becomes a review task.

Mistakes to avoid

Do not coerce critical dates, amounts, or statuses silently.
Do not write partial records into the final table without an explicit draft state.
Do not treat structured output as a replacement for application validation.

Ready checklist

Schema validation before write
Draft state for AI output
Operator review for rejects
No silent coercion of critical fields
Metrics for validation failures

Practical note

A validation failure is product signal. Track it as a queue item, not just an exception.

Use this as an implementation constraint, not just advice. The interface, server code, and validation path should make the same behavior true.

Apply this to a build