Structured outputsTutorial8 min

Design structured outputs for proposal intake

A guide to turning messy tender or proposal documents into validated fields that operators can approve.

Real workflow example

A tender PDF includes eligibility rules, required certifications, deadline, evaluation criteria, and submission format across 40 pages. A normal summary is too vague for bid/no-bid decisions.

Use structured output with separate sections for facts, risks, missing evidence, and recommendation. Facts include deadline, buyer, sector, required documents, and eligibility. Risks include short deadline, missing ISO certificate, and ambiguous consortium rule.

The proposal manager can filter tenders by eligibility, see what evidence is missing, and decide whether to pursue without reading the entire document first.

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.

List the fields operators need to decide whether the opportunity is worth pursuing.
Split fields into facts, interpretations, risks, and required follow-up.
Define strict enums for statuses and risk levels, and avoid open-ended labels where filters matter.
Render schema output as a review form with source snippets and confidence notes.
Reject or quarantine outputs that fail validation instead of silently writing partial records.

Useful extraction shape

type ProposalIntake = {
  buyer: string;
  deadline: string;
  requiredDocuments: string[];
  eligibility: { status: "eligible" | "unclear" | "not_eligible"; evidence: string[] };
  risks: Array<{ level: "low" | "medium" | "high"; reason: string; evidence?: string }>;
  missingEvidence: string[];
};

Field notes

A schema is a product decision: it decides what the team can review, filter, and automate.
Keep extracted facts separate from model judgments such as risk, fit, or priority.
Make missing evidence a first-class output rather than letting the model guess.

Mistakes to avoid

Do not mix extracted facts and recommendations in the same field.
Do not allow open-ended status labels if the UI needs filters.
Do not accept a recommendation without evidence references.

Ready checklist

Required fields are genuinely required
Enums match UI filters
Missing evidence path exists
Reviewer can edit extracted fields
Database writes happen only after validation

Practical note

Design the schema from the review screen backwards. If a field is not useful for a decision, it probably should not be extracted.

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