A 311 intake tool takes a complaint_type string parameter that residents' free text maps to loosely, causing the model to send inconsistent values like 'trash', 'garbage problem', and 'refuse issue' for the same category. What schema change fixes this?
Select an answer to reveal the explanation.
Short Explanation
A dropdown that is secretly a blank text box gets you trash, garbage problem, and refuse issue for the same thing. An enum pins the value to the list the backend actually knows.
Full Explanation
A tool's schema is the contract the model is actually held to; anything expressed only in prose is a suggestion. When a 311 backend accepts a fixed, small set of complaint categories, a free-text string parameter invites the model to produce plausible synonyms, and that drift surfaces later as tickets nothing can route.
Declaring complaint_type as a JSON Schema enum of the exact accepted values makes an out-of-vocabulary value structurally impossible rather than merely discouraged. The model selects from the list, every call arrives in the backend's own vocabulary, and classification happens once, at the boundary, where it can be validated.
A polite instruction in the description is advisory, and a model emitting a reasonable synonym is behaving reasonably because the schema never told it otherwise; accepting any string and having the backend guess later pushes an avoidable classification problem downstream into a component with less context about the resident's intent; collapsing everything to a single general category discards the signal routing depends on, curing inconsistency by removing the data.
Exam caveat: enums fit fixed, small value sets—if the category list changes often, the enum can silently drift out of step with the backend it was meant to mirror. Operational check: generate the enum from the backend's category table rather than hand-maintaining it, and add a test that fails the build when the two lists diverge.