design-output-contracts

Force a named tool call with tool_choice so the model must return a tool-use JSON block and cannot emit an assistant text message. Combine this with a schema containing no prose-shaped fields like message, reply, or text.

Have the model select fact IDs only, and hydrate every rendered price, metric, or quote from a hand-verified server-side data store keyed by ID. The model names which verified fact renders but never authors its value, making fabrication structurally impossible.

Prompting for JSON buys a tendency — the model usually complies but can still leak prose. Forcing tool_choice is an API-level lock that buys a guarantee, since the model physically cannot return a plain text message.

Split unmatched input into two designed intents: guide for willing-but-lost users needing re-orientation, and fallback for off-limits or off-catalog asks requiring an honest decline. Both are designed recipes inside the enum, never a raw error string.

Yes. Validate server-side that a tool_use block exists, the intent is actually in the enum, and confidence clears a threshold such as 0.45. On any failure, degrade to a deterministic keyword backstop route rather than a blank screen.

Skip it for internal tools where an occasional prose leak costs nothing — a tendency from prompting is enough. Use the guarantee only when one leak kills credibility, such as a wrong spoken price or a stray paragraph on a customer-facing surface.