Choice: a category with a clear meaning
Choice fits tasks that select one option from a defined set. In a return scenario, the options might be the standard procedure, manager review or a request for missing facts. Each option represents a different next action your application can handle explicitly.
Describe categories with clear boundaries. “Important” and “urgent” can overlap; task routing and urgency are better expressed as separate questions. If incoming data may be incomplete, define in your rules how to handle that.
Score: a scale with explainable levels
Use Score for an ordered assessment. A scale such as “does not prevent ordering,” “makes ordering harder for one customer,” “blocks one payment method” and “blocks all methods” explains what changes between levels.
This is easier to evaluate than asking for an abstract score without criteria. When analyzing errors, you can identify which feature the model missed: scope, an available alternative or whether ordering was blocked at all. When changing the order or meaning of levels, version the scale alongside the integration.
{
"completeness": {
"type": "score",
"instructions": "How many of the three facts are known: time since receipt, use of the item and presence of tags?",
"criteria": [
"None",
"One fact",
"Two facts",
"All three facts"
]
}
}Noul: one statement, one next check
Noul is useful for a stated proposition, such as whether a draft answer contradicts the provided source. Include the source in the context and explain what to assess. Do not combine factual verification and stylistic preferences in a single statement.
Whichever type you choose, a structured format alone does not establish that a decision is correct. Test the content on your own data, handle API errors and determine the next action in your own code. This makes the response format a clear part of the workflow.