decision_unavailable means a decision run was admitted but no model could serve it as written. Read this page when a decision run fails with this code, especially right after you changed question ids, option names or level names.
What happened
Route:POST /v1/runs, decision runs.
Several causes share this code:
The labels are the answer names Neon 1.1 must produce:
yes and no for a noul question, the option names for a choice question, and the level names for a score question. Admission checks the count, uniqueness and size of the question set, but not whether each label is a single token or whether the set fits the template. Those two problems surface here, after admission, instead of as 400 invalid_decision_questions.
The run was refused before the model served it. You are not charged, and the hold is released, but the run stays pending. A replay with the same Idempotency-Key returns 202 with "state": "pending".
How to fix
- Shorten the labels. Use short, common lowercase words for option and level names:
billing,refund,low,high. Avoid long compound names, punctuation and rare words. - Shrink the set. If the run still fails, split the questions across two runs, or remove the question you added last, to find the one that does not fit.
- Check whether it is the set or the service. Send the smallest valid decision (one
noulquestion). If that also fails, the cause is on the service side: retry later with backoff and report therequest_id. - Use a new
Idempotency-Keyfor every retry. A changed question set is a new request, and the old key points at a pending run.
Example
Related
- Decision runs - every field of a decision run and its limits.
- Choice questions - how option names become labels.
- Idempotency - when to reuse an
Idempotency-Keyand when to send a new one. - Error handling - a status-to-action table and a retry helper for every error.
- Problem codes - every code, its status, and whether a retry can help.