A language model predicts output from the context it receives. It does not automatically know your database, enforce your permissions, or guarantee that a plausible answer is true. Start by defining the behavior your application needs, then choose the smallest output contract that supports it.
Define the contract first
A ticket classifier might return:
{"category":"billing","needs_review":true,"reason":"The ticket mentions an unknown invoice."}
Allow only known categories, require a Boolean for needs_review, and limit the explanation length. Reject additional fields when they could be mistaken for executable instructions. Schema validation checks shape; a well-formed classification can still be wrong.
Keep trusted application instructions separate from user text. Explain the task, allowed categories, and behavior when evidence is insufficient. Reserve room in the context window for the response rather than filling the entire window with input.
Work through uncertainty
For “My account is broken,” choosing billing invents specificity. A review state preserves uncertainty so a human or follow-up question can resolve it. Do not interpret a model’s self-reported confidence as a calibrated probability.
Exercise
Create twelve example tickets including ambiguous, irrelevant, and instruction-like text. Record expected labels before running the model. Test malformed JSON and a category outside the allowed set using fixtures.
Check: report schema validity and classification accuracy separately. Invalid output never triggers an action. Record the model and prompt version so you can repeat the comparison.