# Typed decisions do not establish the right rejection policy

Decisions GA narrows output syntax, while rejection and escalation still need labeled evidence, explicit unresolved cases and a versioned action policy.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-10-22
Original announcement: https://openai.com/index/decisions-api/
Canonical URL: https://retrivium.ai/retrospectives/decisions-ga-rejection-policy/

A typed answer can be perfectly valid and still send the wrong case into an automated workflow. The Decisions API's move to general availability therefore leaves an important application question open: when should a system decline to act on the selected value?

## The service narrowed the output contract

[Sol and Luna](https://openai.com/index/introducing-gpt-6-sol-and-luna/) launched on September 22, 2026. The [changelog](https://developers.openai.com/api/docs/changelog) records Decisions beta on October 6, 2026, before the [October 22, 2026 GA announcement](https://openai.com/index/decisions-api/). The endpoint offered bounded decisions rather than unrestricted prose. That product change reduced output ambiguity without defining every application's rejection or escalation policy.

## A correct label set can still be incomplete

Imagine classifying technical alerts as actionable or informational. A log fragment may omit the maintenance context needed to distinguish them. Forcing one of the available labels creates a valid response while hiding the missing evidence.

The application can design an unresolved outcome or a separate review gate where appropriate. That is a proposed workflow policy, not an assertion that the release supplies a universal rejection mechanism. The answer space must be capable of representing the situations the workflow intends to distinguish.

## Rejection has its own tradeoff

Rejecting every ambiguous input can make an automated system unhelpful. Accepting every plausible choice can send unsupported decisions downstream. The relevant balance depends on the action, available evidence and consequences of delay.

Do not infer that a confidence-shaped value is calibrated for the private workload. If a decision rule uses a score, establish its interpretation and review it against labeled cases. Ordering examples usefully and choosing a safe action boundary are different evaluation problems.

## Build both positive and unresolved fixtures

Prepare illustrative alerts with clear supporting context, misleading vocabulary and genuinely missing information. Have reviewers define which cases can proceed and which need investigation. Retain the source material used for those judgments.

Inspect false acceptance and unnecessary rejection separately. A change can improve one while worsening the other. Include cases close to the operational boundary rather than testing only obvious examples. Otherwise a reassuring aggregate can conceal the exact ambiguity the workflow encounters in practice.

## Version the decision-to-action boundary

Store the model configuration, answer space, decision rule and review examples together. If the workflow's categories or action consequences change, revisit the gate rather than carrying a historical threshold forward automatically.

The retrospective lesson is that structured inference clarifies an interface but does not settle judgment under uncertainty. A useful adoption record explains which decisions were accepted, why unresolved cases stayed unresolved and what evidence would allow them to move forward.

## Related reading

- [Valid output and behavioral acceptance](/journal/vllm-structured-backend-migration/)
- [Defining a meaningful evaluation slice](/journal/inference-benchmark-method/)