Skip to main content
A decision model reads a state — a ticket, a document, a conversation — and answers questions about it with a probability for every option. It does not write text. Use it where your agent classifies, routes, approves or rates: it is faster and cheaper than a chat model, and its probabilities tell you how sure it is. You train one the way you train a chat model: shape a dataset in the Data Workshop, start a job, and compare the trained model with its base on held-out data.

​
Models

A model reads state and questions up to its context. Training skips longer rows, and a longer request is refused with 400. GET /api/decision-models/ returns the list with each model’s limits.

​
Decision rows

A decision row puts the request in input and the answers in expected_output:
An answer can also be a spread of weights, such as {"billing": 3, "shipping": 1}; Overmind normalises it. Every question needs an answer. A row accepts up to 255 options or levels and 100 questions; each model has narrower limits, listed in Models. A job is refused when a row of its training or evaluation version exceeds the chosen model’s limits, and such a request returns 400. The dataset page shows Ready for decision training (or evaluation) when every row is valid, and otherwise names the first row that is not and why. It also warns, without blocking use, when an option is the answer in fewer than 5 rows, or when one answer covers 90% or more of 10 or more rows. Decision rows are only for decision models: chat training, eval runs and the optimiser refuse them. A coding agent connected over MCP reads the format from overmind://decision-models.

​
Train

1

Shape the data

A training dataset of decision rows, and optionally an evaluation dataset of decision rows with different examples.
2

Start a job

On the dataset page, select Train a decision model, or open Training → Decision models → New decision job. Choose the training data, the evaluation data and a base model. The dialog offers up to three unranked picks among the models that fit: Strongest score (highest Decision Index), Smaller (highest index at most half the strongest’s size) and Smallest that fits. A model that does not fit is unavailable, with the reason. Nothing is preselected. Over MCP, check_decision_readiness returns the same picks and start_decision_job starts the job; over REST, POST /api/decision-jobs/recommend/ and POST /api/decision-jobs/.
3

Follow it

The job runs Queued → Running → Succeeded, through Evaluating when it has evaluation data, or ends Failed or Cancelled. Its versions are frozen when it starts, so later versions do not change it. Cancel stops it while it is queued, running or evaluating.

​
Evaluation

With evaluation data, the job scores the base model and the trained model on every row once training ends: An answer given as weights has no single right option and counts only in log loss and Brier. The job’s evaluation also carries, per question, accuracy, the majority baseline, macro F1, and per-option precision, recall, F1 and a confusion matrix; the Console shows per-question accuracy. Rows a model could not answer are counted under unanswered by reason and mark the evaluation partial; with no answered rows it is failed. A warning counts training rows that overlap the evaluation version.

​
Use the model

A succeeded job answers System One requests:
POST /api/decision-models/{model}/systemone (with project in the body) answers with a catalog model as published, without training. A noul answer is {"noul": p}, the probability of true; a score answer carries score (the expected level), confidence and probabilities by level index. A model that has been idle starts again on its first request: the request returns 503 warming with Retry-After, and the retry is answered. A model that cannot answer returns 503 unavailable with a reason: boot_failed, adapter_missing or runtime_error.