OpenAI Decisions API in Loop Engineering Workflows

OpenAI’s announcement describes bounded questions with finite answers, using text or image context for classification, request routing, or proposing an agent’s next action. The announcement refers to Luna; this guide does not infer a callable model ID from that description.

A finite-options decision sits between incoming context and an application branch. A proposed choice does not complete a refund, deploy software, or authorize access. Application code still validates the route, permissions, and approval conditions.

A plan to release is not confirmation of current access. Check the official sources again before integrating. No callable OpenAI Decisions API example is provided here.

OpenAI: the product described in the DevDay recap above.

OpenRouter / TypeSafe Jev: OpenRouter’s official Jev hub also uses the name Decisions API, for the TypeSafe model. It is a separate provider surface. Do not transfer its endpoint, SDK, fields, or pricing to OpenAI.

Searches for “decisions api” or “decisionsapi” can have an unclear product identity. For other same-name services, verify the provider and documentation domain before treating a result as OpenAI information.

Our design example routes a documentation-maintenance request. The following is Loop Engineering guidance, not an official API format:

1. 1 → Receive the task and permitted scope
2. 2 → Propose a route from defined options
3. 3 → Check the allow-list and execution permissions
4. 4 → Apply independent checks or human review
5. 5 → Perform the permitted step or fall back
6. 6 → Record the outcome and apply the stop rule

A route recommendation grants no permission. Use manual_review for missing information or no matching route. Do not hide uncertainty by forcing a choice. The model cannot change its own permissions, budget, or stopping conditions. This page prepares an evaluation and does not run an agent.

Review the agent harness and control loop boundaries and human review in open and closed loops.

Correct routing

Compare the expected and actual route for representative, clearly labeled work.

Wrong routing

Review which routes are confused and the harm of each error, rather than averaging them away.

Missed fallback

Count cases that needed manual_review but received an automated route. Review unsafe matches independently.

Excessive fallback

Count valid, supported tasks sent to manual_review and the added review effort.

Invalid output

Check the verified provider protocol and allowed routes. Invalid responses, timeout, and service failure must stop or fall back.

High-risk work

Require independent checks and human approval before consequential actions, even for a well-formed answer.

Measured duration and cost

After real integration, record elapsed time and actual billed cost, units, configuration, and source. This kit contains neither measurements nor API results.

Use provider-documented score semantics only if the real interface supplies scores. TypeSafe describes confidence derived from a distribution for its Choice and Score primitives; that is not evidence of OpenAI’s response fields. A value of 0.9 is not automatically a calibrated 90% chance of correctness. Test thresholds with your own held-out data.

Report error categories and sample size. Performance on a small synthetic set does not establish production reliability.

Preparation kit only. No model is called. The sample cases are synthetic, and no API results are included. These are preparation materials, not an online model evaluator.

Our example route definitions

documentation

Update or organize documentation using established evidence. Excludes source discovery, code edits, and production changes.

research

Find and verify external primary sources. Excludes changing production systems or treating unverified claims as facts.

code_review

Read-only inspection of a supplied code diff or its tests. Excludes automatic edits, merge, and deployment.

manual_review

Ask a person when information is insufficient, scope conflicts, authorization is missing, or human judgment is required.

These labels belong to this example; they are not official vendor fields or enums.

# Routing evaluation checklist

Preparation kit only. No model is called. The sample cases are synthetic, and no API results are included.

These labels are our example definitions, not vendor API fields or enums.

- documentation: Update or organize documentation using established evidence. Excludes source discovery, code edits, and production changes.
- research: Find and verify external primary sources. Excludes changing production systems or treating unverified claims as facts.
- code_review: Read-only inspection of a supplied code diff or its tests. Excludes automatic edits, merge, and deployment.
- manual_review: Ask a person when information is insufficient, scope conflicts, authorization is missing, or human judgment is required.

## Before a real test

- [ ] Record the task, owner, allowed routes, route definitions, and exclusions before testing.
- [ ] Define manual_review triggers: no route fits, missing evidence, conflicting scope, missing authorization, high risk, or untrusted instructions.
- [ ] Separate development examples from a held-out evaluation set. Never copy evaluation answers into routing rules while tuning prompts.
- [ ] Add your own anonymized representative cases. These synthetic examples do not represent a real traffic distribution or prove production reliability.
- [ ] Record provider, model, configuration, prompt version, API/protocol version, and evaluation date: ______.
- [ ] For each case, record expected_route, actual_route, review_note, and whether the response is valid. Leave actual results empty until a real test.
- [ ] Review correct routes, wrong routes, missed fallbacks, excessive fallbacks, invalid responses, and harmful errors separately, not only overall accuracy.
- [ ] Have an independent reviewer examine errors and high-risk cases. Specify the human approval gate before any consequential action.
- [ ] Define fallback for invalid output, timeout, or unavailable service: stop the attempt, preserve evidence, and require manual review.
- [ ] Set budget, maximum attempts, timeout, and stop rule before running: ______. The model cannot change permissions, budget, or stopping conditions.
- [ ] After real integration, record measured duration and actual billed cost with units and source: ______. Unknown cost stays unknown.
- [ ] If the documented provider returns scores, record their semantics and validate thresholds on your data. A score of 0.9 is not automatically 90% correctness.
- [ ] Record outcome, failure categories, approval decisions, and one bounded adjustment for the next round. Stop when limits are reached or evidence is insufficient.

10 synthetic routing cases

The CSV contains case_id, input, expected_route, case_type, rationale, actual_route, and review_note. Actual routes and review notes are empty: no API has been evaluated.

These examples explain an evaluation structure, not a real traffic distribution. Do not judge production effectiveness from these 10 cases alone. Add anonymized representative cases of your own; keep evaluation answers out of prompt-tuning rules.

Our design advice: use clear deterministic rules when they are sufficient. A finite-choice router is also a poor fit when the task needs long-form generation, there are no useful labels or independent checks, or high-risk execution has no human takeover path.

• OpenAI DevDay 2026 recap (September 29)
• OpenAI API documentation
• OpenAI guides index reviewed
• OpenAI endpoint reference index reviewed
• OpenAI Structured Outputs: handling mistakes
• OpenRouter Jev documentation
• TypeSafe confidence documentation

Primary sources support the product descriptions above. Route labels, safeguards, evaluation advice, and synthetic cases are this site’s own preparation design. Last editorial check: 2026-09-30.

Have a concrete routing task or anonymized test result to discuss? Open an email to share routing feedback. Do not send API keys, customer data, or other secrets. Opening email does not mean feedback has been sent.