Wartości enum z „other” na potrzeby rozszerzalności

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 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.

Here is a classification tool for a support agent. Notice the enum includes "other", and there's a companion category_detail string for the open case.

Because structured output via tool_use + JSON Schema enforces the enum, the model literally cannot return a value outside the list — including the deliberate other safety valve.

The most important schema decision here: mark category_detail as optional, never required.

A core structured-output rule is to require a field only if it is always present. The detail field is present only when category is other — it is absent for billing, technical, and account tickets.

If you force it into required, the model will fabricate a detail string for cases that don't need one, just to satisfy the schema. You'd be manufacturing hallucinations to enforce a rule you didn't actually need.

So how do you make sure category_detail is filled when the model picks other? The dependency is conditional, so it belongs in the field description and the system prompt — not in the schema's static required array.

Be explicit about the rule. Explicit criteria beat vague instructions every time.

To guarantee the model returns the classification as structured data rather than prose, force the tool call. Setting tool_choice to {"type": "tool", "name": "classify_ticket"} compels Claude to emit exactly that tool's input, schema-validated.

If you had several extraction tools and just wanted to guarantee some structured call, tool_choice: "any" would do; "auto" lets the model choose between text and a tool. For a single forced schema, name the tool explicitly.

On the consuming side, branch on the enum. The other bucket is where you read category_detail — and where you should expect it to sometimes be missing, because it's optional.

Defensive access (a default of empty string) keeps your code robust against a legitimately absent field, which is exactly the behavior you designed for.

The detail field isn't just a fallback — it's a feedback loop. Every other record carries a human-readable label for a case your taxonomy missed.

Periodically aggregate those details. When a cluster like "partnership inquiry" shows up 40 times a week, you've found your next first-class enum value. You promote it from free text to a named category, and your classifier gets sharper — driven by real data, not guesswork.

This pattern composes cleanly with validation. If a result violates your conditional rule — say category is other but category_detail came back empty — that's a structural error, and retry-with-feedback fixes exactly those.

Send the model the original ticket, its own wrong output, and the precise validation error. Crucially, retry helps because the information needed (the real category) is present in the source. Retry would not help if the information were simply absent from the ticket.

The pattern is for extensibility under uncertainty — open-world taxonomies like ticket categories, document types, or intent labels where new cases will keep appearing.

Don't bolt other onto a genuinely closed set. A priority field of low / medium / high is exhaustive by definition; an other there just invites the model to dodge a real decision. Reserve the escape hatch for enums that legitimately can't anticipate every value.

Put the pieces together and you have a small, robust contract:

• Enum with named values plus other — the schema enforces the closed set.
• Optional detail field — never required, so the model won't fabricate it.
• Prompt + description carry the conditional "fill detail when other" rule.
• Consumer branches on the enum and logs the detail.
• Validation/retry catches a missing-but-required-by-rule detail.

It's a clean separation: the schema guarantees shape; the prompt guarantees behavior; the loop captures what you didn't foresee.

You're building a ticket-classifier tool whose category enum includes billing, technical, account, and other. You add a category_detail string that should be populated whenever the model picks other. How should you encode the requirement that category_detail be filled for other cases?

Key takeaways:

• Closed enums silently misclassify inputs they never anticipated; an other value gives the model an honest escape hatch.
• Pair other with a free-text detail field to capture what the unexpected case actually was.
• Keep the detail field optional — never require a field that may be absent, or the model will fabricate it.
• Put the conditional "fill detail when other" rule in the prompt and field description, not the static required array.
• Mine logged other details to grow the enum with real first-class values over time.
• Use tool_use + JSON Schema to enforce the enum, and retry-with-feedback for structural violations.