Measure whether the ticket triage schema gate works

Translate the claim into assertions or a tiny eval harness. The metric to protect is: schema pass rate; repair attempts; final reject count. Always record the denominator (how many cases) beside any rate. A percentage without a denominator is marketing, not measurement.

const parsed = OutputSchema.safeParse(raw);
if (!parsed.success) {
  throw new ContractError("invalid_output", parsed.error.issues.map(i => ({
    path: i.path.join("."), code: i.code
  })));
}
return parsed.data;

Expected evidence: “Charged twice” becomes billing/high with a short summary; extra keys are rejected.. A passing assertion proves only the behavior it names; broader usefulness still needs the chapter’s full limits.

Be explicit: beating the baseline (free-text model reply without schema validation) on this fixture does not prove behavior under accepting extra fields that change routing, or string priority 'high' vs enum. Label observations separately from conclusions so the next page inherits honest evidence about the ticket triage schema gate.

Compute schema pass rate; repair attempts; final reject count with the denominator written beside the rate every time. For this chapter, the evaluation set is intentionally tiny; that is allowed only if you say so in the evidence. Compare against free-text model reply without schema validation before celebrating.

Add one negative case aimed at accepting extra fields that change routing, or string priority 'high' vs enum. A suite with only happy cases cannot protect the ticket triage schema gate when the characteristic failure appears in review.

If a check is expensive or flaky, shrink it until it is deterministic on sample ticket + triage schema. Flaky green builds teach the team to ignore gates. Record what this page does not prove so security-ops and mastery-ship inherit honest limits.

At the evaluation 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 metrics with explicit denominators and a negative case 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

Previous · Next