Enums with 'other' for Extensibility
Add an 'other' value plus a detail field.
The Problem with a Closed Enum
Enums are the backbone of clean structured output. When you constrain a field to a fixed set of values — like category being one of billing, technical, or account — the model can't drift into free-form strings, and downstream code can branch with confidence.
But a closed enum has a hidden failure mode: the real world produces inputs your list never anticipated. When a ticket doesn't fit any allowed value, the model is forced to pick the least wrong option. That's a silent misclassification, and it corrupts everything built on top of it.
The Extensibility Pattern: 'other' + detail
The architect-grade fix is the extensibility pattern: add an "other" value to the enum, plus a free-text detail field the model fills in when it selects other.
This gives you two wins at once:
- The model has an honest escape hatch instead of a forced bad fit.
- You capture what the unexpected case actually was — raw signal you can mine to grow the enum later.
It turns the gap in your taxonomy into a logged, inspectable data point instead of a corrupted record.
All lessons in this course
- tool_use for Guaranteed Structure
- Designing a JSON Schema
- Required vs Optional/Nullable Fields
- Enums with 'other' for Extensibility