A classification score needs a business rule around it

OpenAI marked the Decisions API generally available on 22 October. (OpenAI)

The guide specifies gpt-6-luna, typed predicate, choice and score answers, and up to 400 questions per request. Your application executes any resulting actions. An answer type or probability estimate does not itself establish that the business decision is correct. (OpenAI)

A probability is a model estimate, not a guarantee that the business condition is true. Availability of an API also says nothing about your labelled examples, data permissions or acceptable error rate. Begin with a narrow decision whose outcome can be checked.

Use one bounded example

Imagine a shared inbox that receives service questions, invoices and ambiguous messages. The first pilot could propose a queue and show its evidence to a person. It should not issue refunds, reject applications or send binding commitments. This example is a design exercise, not a demonstration of a deployed KIURO classifier.

Evaluate errors by consequence

A message sent to the wrong internal queue may be recoverable. A private invoice sent outside its permitted group is a different class of error. Build an evaluation set that includes missing attachments, mixed purposes, unsupported languages, quoted text and messages that do not fit the categories. Keep a held-out set for checking a change after you choose prompts or thresholds.

• Record correct routing, incorrect routing and abstention separately.
• Inspect false positives and false negatives for the classes that create expensive or sensitive actions.
• Compare the proposed workflow with an explicit baseline, such as the existing manual rules.
• Keep model version, question definitions and input preparation fixed during each comparison.

Do not borrow a threshold from a demo. Select it using labelled cases and the cost of each mistake, then test it on cases that did not set the threshold. An apparent probability of 0.9 does not by itself establish a nine-in-ten success rate on your business's messages.

Make fallback part of the design

Illustrative application logic; not an API request schema:
if required evidence is missing:
    send to human review
else:
    obtain a typed classification
    apply task-specific acceptance rules
    propose queue or request review
record evidence reference, model version and reviewed outcome

If the API times out or the answer is outside your application's accepted contract, keep the message in an owned pending state. A retry should not create duplicate CRM records or repeated notifications. Separate model evaluation from credentials that can write to customer systems.

Estimate the pilot before integrating it

The cost is not just inference. Include labelling, error investigation, input preparation, permissions, monitoring and the human review that remains. A smaller labelled pilot may expose a poor category design before a larger integration makes it expensive to change. We have not measured a speed, accuracy or savings result for this example.

Use custom software and internal tools when a defined application is needed, and system integration when the work is chiefly connecting an agreed result to existing tools. The distinction keeps an API announcement from becoming an undefined automation project.