Type-safe AI output is not the same as a correct decision
A model can select a valid document ID and still select the wrong document. Separate output shape, meaning, permission and execution with one worked example.
A type or schema restricts the form of an answer. It does not establish that the selected value answers the question, that the caller may use it, or that a later action succeeded. Those properties need different evidence and checks.
Suppose a model must choose one of two existing document IDs. It returns the guide for an older software version, although the request names the current version. The returned ID is allowed and real. The choice is still wrong.
The download button could work perfectly and deliver exactly the file named by the model. That would make the wrong choice easier to execute, not more correct. Follow the request from the allowed answer to the eventual operation before deciding what a passing check means.
Follow a valid answer to the wrong document#
In this illustrative library, guide-17 describes version 1 and guide-28 describes version 2. A request explicitly asks for version 2. Both IDs appear in the model’s permitted answer set, and both point to stored documents. Returning guide-17 satisfies membership in that set but fails the request.
If the version requirement and document metadata are already exact, ordinary code can filter out version 1 before asking a model to interpret the remaining content. That removes this particular unsuitable candidate. It does not establish that every remaining document contains the answer. Use explicit rules where the facts already settle the question.
Jev’s Choice interface returns a selection from supplied options. A generative model can also produce a constrained result: OpenAI documents schema-constrained output and explicitly notes that it can still contain mistakes. Neither interface turns membership in a permitted answer set into proof of a correct choice.
Try it: change the selected document ID
Still check the source content, user permission and outcome of any later action.
Illustrative IDs and checks; no document service is queried.
Ask what each check establishes#
For our proposed document workflow, separate these checks. The names describe the question each check answers; they do not imply that one library performs all of them.
| Situation | Take | Because |
|---|---|---|
| The response is missing a required field or names an option outside the allowed set. | Check the shape | Reject an unusable response. Schema validation alone cannot detect the wrong allowed document. |
| The ID exists, but its document describes the wrong software version. | Check the meaning | Compare the requested version and evidence with the selected document, not just its identifier format. |
| The right document exists, but the caller has no access to it. | Check permission | The server must enforce the access rule for this caller and document. A recommendation does not grant access. |
| The request was permitted, but storage failed before the file was delivered. | Check the result | The intended action and its confirmed outcome are different records. Do not label a failed operation as completed. |
- Situation
- The response is missing a required field or names an option outside the allowed set.
- Take
- Check the shape
- Because
- Reject an unusable response. Schema validation alone cannot detect the wrong allowed document.
- Situation
- The ID exists, but its document describes the wrong software version.
- Take
- Check the meaning
- Because
- Compare the requested version and evidence with the selected document, not just its identifier format.
- Situation
- The right document exists, but the caller has no access to it.
- Take
- Check permission
- Because
- The server must enforce the access rule for this caller and document. A recommendation does not grant access.
- Situation
- The request was permitted, but storage failed before the file was delivered.
- Take
- Check the result
- Because
- The intended action and its confirmed outcome are different records. Do not label a failed operation as completed.
In this design, the service checks current access when it serves the document, not only when a list of candidates was prepared. Permissions can change between those moments. Restricted credentials and enforced controls address access; the classifier’s answer is not a replacement for them.
Also distinguish a declared type in application code from a check on received data. Writing a type annotation is not evidence that the remote response was validated. Identify which runtime component enforces the actual response contract, including its error cases.
Test names against their intended meanings#
A September 2026 preprint by Sun and colleagues investigates Jev and two related models by changing which definitions are assigned to option names. The authors report changes in the selected meaning while outputs remain type-correct. This is a controlled sensitivity test, not an estimated failure rate for normal production traffic or a general verdict on Jev.
One practical test follows from that finding. Keep the question and intended meanings fixed, rename the option IDs, and compare the selected meaning after decoding each answer with its own mapping. A different returned string can be the correct result of a rename. Comparing raw strings would count that correct change as a failure.
Repeat an unchanged request too, so ordinary variation is not mistaken for an effect of the edit. This is a proposed test for your integration, not an experiment executed here. Neutral IDs are a candidate design choice to evaluate, not a guarantee that interpretation becomes correct.
Keep missing results and failed actions visible#
Define what happens when no candidate answers the request. Adding an explicit “none of these” outcome can represent that possibility, but the model can still choose it incorrectly. Test it as another decision rather than treating the extra option as a correctness guarantee.
A timeout is different: the application has not received a usable decision. Keep it separate from an actual “none of these” answer. After a tool operation, preserve the operation’s status separately from the classification. Choosing an ID must not set a download’s status to completed.
A confidence signal can help prioritise additional work when it has been evaluated for that purpose. It cannot supply missing permission or prove which file was delivered. Keep those checks even for highly confident decisions.
Make the test distinguish the mistakes#
Save separate cases for a forbidden ID, an allowed but wrong-version ID, a correct ID without permission and a permitted operation that fails. Specify the expected result of each layer. A test that accepts any allowed ID would pass the wrong-version case and never reveal the missing requirement.
The model selected the right document. The caller lost access before the download. Should the server serve it?
No, under this workflow’s access rule. The earlier selection remains a correct identification of the document, while the later action is now unauthorised. Rejecting the download does not require pretending that the classification was wrong.
Use repeatable task cases to check these distinctions after changes. Then improve the question, options and context contract when a failure reveals that the model was asked to decide something the input could not support.
Questions people also ask
2 QUESTIONSAre structured outputs still useful?
Yes. They make a response easier to consume and can rule out invalid shapes or values under the supported schema. That benefit is separate from whether the chosen value is factually appropriate. Keep both format checks and task-specific checks.
Would a higher confidence threshold fix a wrong document choice?
Not necessarily. The model can prefer the wrong document with high confidence. Check the required document identity, version and permissions directly when those facts are available, and evaluate confidence against real task outcomes.