Frame the ticket triage schema gate experiment

Success is not “I followed the tutorial.” Success is producing evidence that: invalid model JSON is rejected; valid payloads pass a schema gate. The accepted input is narrow on purpose: ticket text and a JSON schema for triage fields. That narrowness is what lets you inspect every field and prevents a toy demo from being narrated as a production system.

Record the baseline you must beat: free-text model reply without schema validation. If the finished artifact cannot beat that baseline on the fixture below, stop and revise the claim before writing more code.

export const acceptance = {
  project: "a ticket triage endpoint that returns a validated category, priority, summary, and confidence",
  invariant: "the application schema is the final authority even when the provider claims schema compliance",
  expected: "\u201cCharged twice\u201d becomes billing/high with a short summary; extra keys are rejected.",
} as const;

Expected evidence: “Charged twice” becomes billing/high with a short summary; extra keys are rejected.. Treat the printout as a claim about this fixture, not as proof that the toolchain merely started.

For the ticket triage JSON endpoint, a decorative win often looks like a clean run that never checks schema pass rate; repair attempts; final reject count. Write the metric down now so later pages cannot redefine success after the fact. Also note the operational threat you will eventually gate on: logging full ticket PII in triage debug dumps.

For structured-output-lab, write the claim on a sticky note in this exact shape: “Given ticket text and a JSON schema for triage fields, the ticket triage schema gate will …”. Fill the ellipsis with the observable part of: invalid model JSON is rejected; valid payloads pass a schema gate. Tape the baseline beside it: free-text model reply without schema validation. If someone later replaces your metric with a vibe check, the sticky note is how you push back.

Also sketch the one-sentence user story: a person uses this output to return validated category, priority, summary, and confidence for a support ticket. If that sentence needs a dashboard, a model zoo, or five services, the lab scope is too wide—shrink the fixture (sample ticket + triage schema) until the story fits on one screen.

Decide now whether live network calls are allowed on page 1. For this lab they usually are not; inventory and contracts should run offline against sample ticket + triage schema. Note the metric you will eventually require (schema pass rate; repair attempts; final reject count) so page 4 cannot invent a softer target. The characteristic failure to keep in mind is accepting extra fields that change routing, or string priority 'high' vs enum.

At the experiment brief stage for structured-output-lab, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about sample ticket + triage schema that later pages inherit without redefining success. Keep that fixture small enough to inspect by hand, keep outputs copy-pasteable as text, and refuse to narrate this baseline as if it were a production SLA: free-text model reply without schema validation.

For this page specifically, success looks like a falsifiable claim and baseline written before coding while still centering the user decision to return validated category, priority, summary, and confidence for a support ticket. If you cannot point to a file, command, or assertion that proves that for the ticket triage schema gate, stay on this page instead of advancing.

Glossary: tool · Glossary: structured output · Cheatsheet: production ops signals

Next