Hugging Face Shipped a Decision Pipeline: One Call Returns Three Typed Answers With Probabilities, Not Tokens

November 11, 2026 – On November 10, Hugging Face shipped a decision pipeline into transformers, and the call is one line:

from transformers import pipeline

decide = pipeline("decision", model="autotrust/GEV-26B-Decide")

You hand it a state and a set of questions, and it returns typed decisions with probabilities instead of a string you have to parse. The shipped example is a support ticket – “I was charged twice for my order and want a refund.” – and the model answers three questions at once: which team should handle it, how urgent it is, and whether the customer is actually asking for a refund. That is the whole bet: most production LLM use is not generation, it is routing, triage, scoring and yes/no gating. (Hugging Face)

The call, and what comes back

The request has two components. state is the information to evaluate – a string, a structured JSON object, or other modalities for supported models. questions is a map of named questions, each with a type and its own criteria.

decision = decide({
    "state": "I was charged twice for my order and want a refund.",
    "questions": {
        "department": {
            "type": "choice",
            "instructions": "Which team should handle this?",
            "criteria": {
                "billing": "Payments and refunds",
                "technical": "Bugs and technical issues",
                "sales": "Pricing and subscriptions"
            }
        }
    }
})

The reply is a distribution, not a word:

{'department': {
    'type': 'choice',
    'choice': 'billing',
    'confidence': 0.9974000453948975,
    'probabilities': {
        'billing': 0.9982666969299316,
        'technical': 0.0010246571619063616,
        'sales': 0.0007087149424478412
    }
}}

Three failure modes motivate the whole interface, and the Hugging Face post names them plainly. First, an LLM prompted for JSON is not guaranteed to follow the schema – it can emit invalid JSON, unexpected keys, or an answer outside the allowed choices. Second, constrained decoding helps but does not eliminate the overhead: Outlines and XGrammar restrict which tokens may be generated at each step, enforcing structure at a cost. Third, and this matters most, autoregressive generation is unnecessary work when the application already knows the candidate answers – you pay for token-by-token sampling to produce a value drawn from a known finite set.

Three primitives, not one

The interface exposes three answer types, and they are not interchangeable.

Choice is a probability distribution over options, computed as a softmax over the model’s logits with a temperature parameter, with the argmax taken as the pick. You get the winner and the belief it displaced – which is what lets a router escalate on a 0.51 as easily as on a 0.99.

Score measures something on an ordered scale. Ask how urgent the ticket is on a three-level scale and the model returns the full distribution plus its expectation:

{'urgency': {'type': 'score', 'score': 1.7053890228271484,
             'legend': {'0': 'low', '1': 'medium', '2': 'high'},
             'confidence': 0.5580834252759814,
             'probabilities': {'0': 0.014908230863511562,
                               '1': 0.26479458808898926,
                               '2': 0.7202972173690796}}}

The expectation over the level index is 0(0.01) + 1(0.26) + 2(0.72), which is the reported 1.7. That is not a model choosing a fictional level between medium and high – it is the mean of the distribution it actually holds. The score primitive reported 0.558 confidence, and the post does not derive a separate formula for it.

Noul – the name comes from Bernoulli – is the yes/no primitive. It returns the probability parameter itself, and the application decides what to do with it:

{'refund': {'type': 'noul', 'noul': 0.9947046637535095}}

A noul of 0.92 means 0.92 yes, 0.08 no – nothing is sampled; the probability is handed over.

What it buys you against classification and zero-shot

Neither capability is new: runtime-defined labels existed in zero-shot classification, and probabilistic labels in trained classifiers. The decision-model interface packages them under one contract:

Property	Classification	Zero-shot classification	Decision model
Probability over choices	Yes	Yes	Yes
Labels defined at inference	No	Yes	Yes
Multiple typed questions	No	No	Yes
Ordered scoring and yes/no decisions	Task-specific	Possible with adaptation	Native primitives

The limitation of a conventional classifier is structural: classes are baked into the classification head, one logit per class. Add a fourth department and the model does not acquire an output class – you modify the head, collect data, retrain. Zero-shot classification fixes that by supplying labels at inference time, typically via an NLI model that turns each candidate label into a hypothesis and measures entailment. The post’s own facebook/bart-large-mnli example returns scores of 0.8466812372207642 for billing, 0.0962134450674057 for sales and 0.05710534751415253 for technical support – but one score per label, for one question at a time. The decision-model interface adds multiple typed questions over the same state, with ordered and boolean primitives that are native rather than adapted.

The confidence number is not the probability

Choice and Score also return a confidence field, and the definition matters for how you threshold it. For a choice over K options, confidence is the winning probability normalised against a uniform distribution:

confidence = (p_max - 1/K) / (1 - 1/K)

Check it against the shipped output: with p_max = 0.9982666969299316 and K = 3, (0.9982666969299316 - 1/3) / (1 - 1/3) = 0.9974000453948975 – exactly the number the pipeline returned. A uniform distribution scores 0, a single-option distribution 1, so the field answers “how concentrated is this, relative to guessing?” rather than “how likely is the winner?”.

The important caveat is that probabilistic is not the same as calibrated. Nothing in the November 10 post shows these confidence numbers are calibrated in TypeSafe’s sense – that a 0.9 corresponds to 90% accuracy. Treat confidence as a relative concentration score until someone measures it.

The vendor model behind the interface

The pipeline’s example checkpoint, autotrust/GEV-26B-Decide, prints as a JevForDecision – the architecture of Jev, the first System One model from TypeSafe AI, announced by founder Diogo Almeida on September 15 after two years in stealth. Jev ships with a new model architecture, a parallel sampler, and a training method called RLCD (Reinforcement Learning for Calibrated Decisions), and gives up string generation entirely: unstructured state in, typed probabilistic decisions out – the structural reason it cannot hallucinate. TypeSafe’s own framing is a “frontier-intelligence function call”, and the vendor claim is that Jev matches existing LLMs on System One tasks “while being two orders of magnitude faster and more efficient” – 70ms to 500ms end-to-end against 3 to 329 seconds for frontier models, at $0.042 per million input tokens with output “free”. (TypeSafe)

Attribute that number. The baseline is unspecified, no independent benchmark was run, and TypeSafe’s post says its published evals “are generally run from our laptops on the West Coast” and that it cannot prove its pricing is not subsidised. The post’s own subtitle: “Extraordinary claims require extraordinary evidence”. Jev was also in early access.

The interface is the point, and it is standardising

Decision models are not new on this blog – Liquid AI’s open d1 pair and Nokia’s AnyJev layer both shipped in the last two months. What changed on November 10 is that the interface stopped being a per-vendor affair.

The pieces are already in place around one contract. Transformers now exposes DecisionPipeline, AutoModelForDecision and DecisionConfig. The serving docs carry a /v1/systemone endpoint, and llama.cpp shipped server support for it on October 2 – send a state (text, JSON, a screenshot) and typed questions, get a probability per option in one forward pass. The Hub can list models by the decision-model tag, and trl#8040 adds an experimental DecisionTrainer, so training can target shared primitives instead of one architecture.

That is the strategic point: models should be free to work internally however they like, as long as they accept the same state and questions and return the same typed decisions. The category is young – the name was settled by community consensus after a naming poll, and it describes a computational role, not a theory of cognition – but a common contract lets inference engines, the Hub and training tools each build once.

What this changes in production

The honest read is that this is additive, not a replacement. The interface gives up open-ended generation by design, so the question is which calls in your stack move and which stay. Routing, triage, intent classification, PII detection, guardrail checks, RAG relevance scoring – exactly the places where your application already knows the candidate answers and where a malformed JSON string is a production incident waiting to happen.

Three things to check before you adopt it. First, measure the option-order flip rate on your own traffic; a decision that changes when you reorder the labels is not a decision. Second, do not read confidence as a probability until someone calibrates it on your data. Third, treat the speed claims as vendor claims until reproduced against your latency budget – though the 40x-to-200x range TypeSafe quotes is for System One-shaped queries, precisely the traffic a decision model is for. And note the interface may still change shape: the topic rests on two posts published within the last nine weeks.

Sources

1. A decision pipeline for agents - Hugging Face blog, published November 10, 2026
2. Introducing System One models and Jev - TypeSafe AI blog, the Jev announcement
3. Serving: the /v1/systemone endpoint - Hugging Face Transformers documentation, live
4. Decision models in llama.cpp - Hugging Face blog, llama.cpp server support, October 2, 2026
5. trl PR #8040: experimental DecisionTrainer - GitHub pull request, live
6. dottxt-ai/outlines - GitHub repository, structured-generation engine used for constrained decoding
7. mlc-ai/xgrammar - GitHub repository, structured-output engine used for constrained decoding

The probability and confidence figures above are Hugging Face’s published outputs for the shipped example, reproducible from the post. The speed, throughput and pricing figures are TypeSafe’s own claims and have not been independently verified.