Structured output when thirty runs must merge

After school on Friday, Ms Wong pasted thirty-two first-pass comments on Secondary 4 biology lab reports into a spreadsheet. Seven runs had an extra "overall" column. Five put improvements as bullet points instead of cells. Three opened with "here are my comments". The content was broadly fine; aligning columns took ninety minutes. "The AI understands biology," she told the panel. "I never told it what the columns were."

Structured output is the step from "write me a paragraph" to "process thirty pieces I can merge". This is lesson 15 in module four; the next lesson applies the same field discipline to images and audio.

---

Every run chooses a format again

Without an output specification, each generation decides afresh how best to present something — a virtue in prose, a disaster when merging data. "List strengths and improvements in a table" may yield two columns one run and three the next.

Structured output moves presentation into your specification: column names, order, cell length limits, closed lists of permitted values, and "output the table only, with no text before or after".

Table specs for people

Markdown tables suit panel meetings, observation records and copying into Google Sheets. The point is not tidiness. It is that run thirty-one still lines up:

Role: you are a first-pass assistant for [subject] lab reports.
Task: assess the report below and output a single table.
Output format: a markdown table with these columns in this order — student reference, clarity of hypothesis (1-5), data recording (1-5), logic of conclusion (1-5), one strength (one sentence), one improvement (one sentence), teacher verification needed (yes/no).
Constraints: output the table only, with no text before or after; do not add, remove or reorder columns; no cell longer than twenty-five words; scores are whole numbers from 1 to 5. Where you cannot judge, leave the score blank and set teacher verification needed to "yes". Do not rewrite the student's report.
Report: [paste content]

A verification column is a safety design: when unsure, the model has somewhere honest to go instead of inventing a number — the same logic as authorising "not found" in grounded prompts with citations.

Close the list of permitted values

For columns such as category, severity or yes/no, list permitted values and a fixed "other" for anything that will not fit. Otherwise "unclear concept" on one run and "understanding gap" on the next become two categories in your statistics.

Drifting columns are harder to repair than wrong wording — you will fix a bad comment, but a wrong column layout makes you rerun thirty pieces.

JSON for systems

JSON is stricter than a table: field names, casing and types must be settled in advance. Teachers in a chat interface can get far with a prompt plus one complete example. Schools wiring output into admin systems should also use provider structured output (see sources), where the API guarantees conformance rather than luck.

Role: you are a marking service that emits JSON and does not converse.
Task: mark the student response against the rubric and output one JSON object.
Output format: output exactly this structure, with field names and casing matching exactly:
{
  "student_ref": "string",
  "criteria": [
    { "name": "string", "score": integer 1-5, "evidence": "one sentence quoted from the student", "comment": "40 words maximum" }
  ],
  "total": integer,
  "needs_teacher_review": true or false,
  "review_reason": "string, or \"none\" when false"
}
Constraints: output JSON only, with no text before or after; do not omit fields — use agreed empty values; evidence must be the student's own words, not rewritten. Set needs_teacher_review to true when evidence is too thin.
Rubric: [paste]
Student response: [paste]

When the same data needs both a meeting table and a file: ask for JSON first, then convert to a table without changing any value.

Commentary wrapped around JSON

Even with "JSON only", an opening line slips through. Easiest first: one complete worked example; itemise forbidden openings, closings, headings and markdown fences; switch to API structured output. The first two usually suffice in chat; the third is mandatory when wiring into a system.

Where this goes wrong

• Writing only "present this as a table". Columns differ every run and merging becomes manual alignment. Self-check: could a colleague tell how many columns and their names without reading the content?
• Dropping a field when there is no value. Downstream code breaks on one missing key. Self-check: do you require an agreed empty string or null while keeping the structure complete?
• A tidy format with no verification column. Errors hide behind neat rows. Self-check: when unsure, does the model have "teacher verification needed" to fill? Do the constraints say when it must be "yes"?

Try it once

Time: 10–15 minutes.

Do this: Pick a batch task you actually run — observation notes, student feedback, open survey answers. Run once with "organise this in a table". Then rewrite using the table template above with fixed column names, order, permitted values and teacher verification, on the same input.

Deliver: Both outputs. List which format rules the second added, and estimate how many minutes you would save aligning the second versus the first in a spreadsheet.

Done when: The second paste lands in a sheet without column drift, and at least one cell is marked for teacher verification because the model was unsure — showing the verification column is doing work.