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 example

Example: extract a tender into a qualification record

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.

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[];
};

Tutorial path

How to implement it

Step 01

List the fields operators need to decide whether the opportunity is worth pursuing.

Step 02

Split fields into facts, interpretations, risks, and required follow-up.

Step 03

Define strict enums for statuses and risk levels, and avoid open-ended labels where filters matter.

Step 04

Render schema output as a review form with source snippets and confidence notes.

Step 05

Reject or quarantine outputs that fail validation instead of silently writing partial records.

Checklist

Ready when these are true

Required fields are genuinely required

Enums match UI filters

Missing evidence path exists

Reviewer can edit extracted fields

Database writes happen only after validation

Field notes

What matters in practice

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.

Avoid these mistakes

Common failure modes

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.

Practical tip

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

Apply this to a build