Hugging Face Proposes a Common Interface for Decision Models: Transformers Adds DecisionPipeline and a /v1/systemone Endpoint, llama.cpp Serves the Same API, and Three Primitives (choice, score, noul) Return Probabilities; the Post Reports No Accuracy, Calibration or Latency Benchmark, and Its Worked Numbers Are Not Fully Consistent

On November 10, 2026, Hugging Face published "Decision Models in Hugging Face", a long post by Aritra Roy Gosthipaty, Lysandre, Pedro Cuenca and Tom Aarsen. It describes a common interface for a kind of model that does not write text. A decision model reads a state, such as a customer message, and a set of typed questions with allowed answers, and returns structured decisions with probabilities. The post says the model assigns probabilities to answers the application already understands, instead of generating tokens one by one. The interface is written as "State + Questions + Allowed Answers → Decisions + Probabilities". The post says TypeSafe AI introduced the idea under the name Jev, called a "System One model", and that the community has since settled on "decision model" because the term describes the model's role and not a theory of thought.

The motivating example is a support message: "I was charged twice for my subscription. I need a refund today." An application wants three things from it: which team should handle it, how urgent it is and whether the customer is asking for a refund. The post first shows a language model that writes JSON with those answers, then argues for the alternative. It lists three problems with asking a language model for structured output. The model is not guaranteed to follow the requested schema, so it may return invalid JSON, unexpected keys or an answer outside the allowed choices. Constrained decoding libraries such as Outlines and XGrammar enforce a grammar, but add their own work. And generating a whole response is unneeded work when the application only needs to choose between fixed answers. The post gives no measured speed, cost or accuracy comparison to back these points, so they are arguments and not results.

A question has one of three types, called primitives. A choice question selects one of several answers and returns a probability for each. A score question evaluates something on an ordered scale and returns the expected value of the level index. A third type, called "noul" after the Bernoulli distribution, answers a yes/no question with the probability that the statement is true. For choice and score questions the result also carries a confidence field. For a choice with K options, confidence is the largest probability minus 1/K, divided by 1 minus 1/K, so a uniform distribution gives 0 and a fully concentrated one gives 1. In the post's example the department question returns "billing" with probability 0.998 and confidence 0.997. The urgency score is 1.705 with confidence 0.558, which the post explains as an expectation over the distribution and not a level halfway between medium and high.

The post compares decision models with two older approaches. A traditional classifier has its output classes fixed in its classification head, so adding a fourth department such as Legal can mean new data and retraining. Zero-shot classification supplies labels at inference time, and the post shows a model returning scores for billing, technical support, sales and, after a change, legal. The post says the advantage of decision models is not that they invented runtime labels or probabilities. It is that they put these into one interface with several typed questions about the same state, plus native ordered scoring and yes/no decisions. In the post's own table, classification gives probabilities over choices but cannot define labels at inference time, and only decision models have multiple typed questions.

The part that changes tooling is the support in the Hugging Face stack. Transformers now has a DecisionPipeline, an AutoModelForDecision class and a DecisionConfig class. Running "transformers serve" with a compatible version of Transformers exposes a /v1/systemone endpoint, and the post shows one request with three questions returning three typed answers, with usage of 148 input tokens and 0 output tokens. llama.cpp serves decision models through the same API: the example launches "llama serve -hf ggml-org/Kev-4B-GGUF", whose default server port is 9931. The post adds that the interface also works with compatible autoregressive language models. Transformers builds the decision prompts, reads the answer-label logits in one batched forward pass and applies softmax without generating text, so developers can try the interface without training a new model.

On discovery and training, the Hub has a new "decision-model" tag. The post says decision models need not share a backbone: some are based on encoders such as ModernBERT and others on larger generative language models. For training, decision models can be fine-tuned with the Trainer API. The post gives a deliberately small example that fine-tunes autotrust/JEV-9B on six support messages for 30 steps with a learning rate of 1e-3, using plain cross-entropy over the options for a choice question. It states that first-class training support in TRL is coming and that the related pull request, huggingface/trl#8040, was still open when the post was written. It also points to an Unsloth recipe that fine-tunes models such as Qwen with LoRA and a decision-scoring head.

The post has limits a reader should keep in view. Its text reports no benchmark of accuracy, calibration or latency for any named decision model, so "reliable, calibrated decisions" is a goal the post states, not a finding; this report did not open the images or pages the post links to. Its worked numbers are not fully consistent. A table shows urgency probabilities of 0.10, 0.26 and 0.72, which add up to 1.08, so the table is not a valid probability distribution, while the printed output shows 0.0149, 0.2648 and 0.7203. One sentence refers to a winning probability of 0.80 before computing with 0.99; with three options the formula gives 0.70 for 0.80 and 0.985 for 0.99, and the post prints 0.98. Two printed values can be recomputed from the printed probabilities: the choice confidence, (0.99827 − 1/3) / (1 − 1/3) ≈ 0.9974, and the score expectation, 0 × 0.0149 + 1 × 0.2648 + 2 × 0.7203 ≈ 1.705. Both match the printed output. The post gives no formula for the score confidence, so the 0.558 quoted above is the value the post reports, and this report did not check it. The reader should treat the table and prose numbers as illustrations. The models named, autotrust/GEV-26B-Decide, ggml-org/Kev-4B-GGUF and autotrust/JEV-9B, were not tested for this report, and the post does not give their licenses or sizes beyond the names.

For a team that routes tickets, scores risk or filters content today with a language model that writes JSON, the practical question is narrow. Does a model that returns probabilities for fixed answers fit the decision, and is there a checkpoint good enough for your language and domain? The post offers a common API, a way to test it on an ordinary language model and a small training recipe. It does not offer evidence that a decision model beats the current approach. That comparison has to be run on the team's own data.