Decision Models: Fine-Tuning LLMs for Structured Decisions

Many application workflows do not need an LLM to write another paragraph. They need it to pick a route, classify an event, or decide whether a case needs human review.

A normal language model can give those answers as text or JSON, but the application must still parse and validate them. A decision model changes the interface: you give it a state and typed questions with allowed options, and it scores those options directly.

Unsloth’s decision-model guide describes this workflow, with a training path built on a language-model backbone and a dedicated decision head.

From generated answers to typed decisions

A decision request has three parts:

state: the information the model must evaluate, such as a support ticket or an agent trace.
questions: named questions, their instructions and the allowed options.
gold: the expected answer for each question, during training.

Unsloth documents three question types:

choice selects a named option.
noul answers yes or no.
score selects a level from an ordered list.

The result holds the selected answer and a probability for each option (Unsloth’s dataset and inference documentation).

The three types are older than Unsloth’s guide. On 15 September 2026, TypeSafe AI introduced Jev as its first “System One” model. Jev returns type-safe values with calibrated probabilities instead of text, and TypeSafe calls its training method Reinforcement Learning for Calibrated Decisions (RLCD) (TypeSafe AI’s launch post).

The typed-decisions dataset card says its schema follows the System One primitives noul, choice and score. Cloudflare’s Clef announcement opens with the attention that Jev drew to decision models.

This is not the same as asking a generative model for JSON. Structured output constrains the generated tokens to a schema. A decision head scores the supplied options directly.

The application still validates the decision and applies its own policy. But it never parses free text to find out which option the model chose (how Unsloth’s decision head works).

What the decision head changes

Unsloth combines an LLM encoder with a decision head. It encodes the state and the question schema together, and the head scores the candidate answers. One forward pass answers several typed questions about the same state (Unsloth’s training guide).

The Unsloth implementation exposes the dataset builder, the trainer, evaluation and calibration.

Unsloth’s guide describes its head as the same design as Cloudflare’s Clef. Clef freezes a Qwen backbone and trains a routing head together with rank-256 low-rank adapters. Its head routes evidence for each option, attends across the questions and scores the options against the schema (Cloudflare’s Clef announcement).

Other decision models use smaller encoders:

Laya typed-decisions is a 421M-parameter ModernBERT specialist.
THX-01 is a 307M-parameter mmBERT-base encoder with a decision head of about 15M parameters.

The Clef and THX-01 posts both describe an RLCD post-training stage, the method that TypeSafe AI named for Jev.

Fine-tuning with Unsloth

The Python path takes four calls:

FastDecisionModel loads a supported backbone with the decision head.
get_peft_model attaches LoRA adapters.
build_dataset converts your rows.
DecisionTrainer trains.

The settings that the guide documents do not all agree, so read them as different starting points:

Recommended settings: a learning rate of 2e-4, two epochs on typed-decisions, and about 60 steps for a quick try (recommended settings).
Code example (Qwen3.5-4B): 2,048-token sequences, 4-bit loading, LoRA rank 16, a batch of 2 with four accumulation steps, 240 steps and a learning rate of 2e-5 (train with code).
Benchmark summary on the same page: LoRA rank 64 for one epoch.

Choose and validate a configuration for your own data and hardware. The worked example below shows why: there, the number of optimizer steps mattered more than any other setting.

LoRA trains far fewer parameters than full fine-tuning (Hugging Face PEFT: LoRA). In Unsloth’s decision workflow the decision head trains too, so do not describe it as training only an adapter.

Dataset quality and probability labels

The public LocalLLaMA/typed-decisions dataset holds four workflows: agent-trace observability, customer service, invoice processing and security incidents. Its card describes 300 training cases and 100 test cases per workflow.

Its gold labels are probability distributions, not single classes. A teacher model labels each case three times, and the gold is the mean. So a score on this data measures agreement with that teacher, not correctness.

Unsloth’s own custom-data format is simpler. gold holds one answer: an option key for choice, a boolean for noul, or a zero-based level for score. The implementation also accepts a probabilities mapping (the dataset guide, target parsing).

Match the schema exactly. Never flatten a distribution into an arbitrary class.

A useful dataset is more than a pile of labels:

Options that a reader can tell apart.
Examples that cover realistic edge cases.
Training and test splits that share no case.
An extra evaluation set that reflects your own data and the cost of each failure.

Evaluation and calibration

Accuracy alone does not say whether the probabilities are reliable. A model can pick the right class and still give misleading probabilities to the others.

Unsloth provides FastDecisionModel.evaluate and FastDecisionModel.calibrate. Calibration fits probability temperatures on held-out examples and reports accuracy, expected calibration error and loss (calibrate and save).

Three rules keep the numbers honest:

Calibrate on a held-out part of the training data.
Evaluate once, on a separate test set.
Choose thresholds against the cost of false positives and false negatives, on data like production.

A probability is a model estimate, not a guarantee.

One published result shows the size of the gain. The Hugging Face post that introduces Beam fine-tuned Qwen3.5-0.8B with Unsloth for incident routing, severity and escalation. On 320 synthetic test tickets, all three answers were right for 76.25% of tickets, against 4.69% when the unadapted model returned JSON. That is one experiment on synthetic data, not a general claim.

Where decision models fit

Decision models suit tasks whose possible answers are known in advance:

Routing a ticket.
Triaging a security alert.
Classifying an agent trace.
Deciding whether a case needs review.
Scoring a request against an ordered rubric.

They suit open-ended synthesis, new categories and long explanations less well.

The two kinds of model combine well. A decision model handles bounded routing, and a general LLM investigates the ambiguous cases or explains a decision to a reviewer.

Keep authorization outside both models. A predicted option, even at a high probability, is not permission to act.

A worked example

Fine-Tune LFM3, a Large Language Model, into a Decision Model with Unsloth: Lead Qualification with Claude Code over MCP is a tutorial on this site that applies all of the above on one laptop GPU. It fine-tunes LiquidAI/LFM3-1.7B for two decisions in a B2B lead workflow, across three pages:

Lead qualification on LeadForge’s synthetic CRM data.
Reply routing into 11 intents.
Claude Code over MCP: an agent researches real companies with Firecrawl and hands each decision to the two models behind a policy gate.

The results came out mixed, and the tutorial reports them as they are:

Text: a clear win. The reply model reaches a test macro-F1 of 0.975 over 11 intents, against 0.705 for a TF-IDF classifier.
The lesson behind it. The first version trained for 20 optimizer steps and scored 0.778. Choosing the epochs and the LoRA rank on validation data gave the rest.
Tabular data: no win. Over four training seeds, the lead model ranks conversions slightly below a logistic regression (ROC-AUC 0.871 against 0.876), with a slightly lower Brier score (0.109 against 0.111).
A gap in the data. No training record lacked a field, so the model never learned to answer “insufficient evidence”. The policy gate checks for missing fields in code.

The notebooks, plots, data and recorded sessions are in the companion repository. The models are the lead qualifier and the reply router on the Hugging Face Hub.

The takeaway

Decision models do not replace generative models. They give a different interface to one class of problems: the application already knows the possible answers and needs a model to score them consistently.

The engineering work is in the schema, the labels, the calibration, and the policy that stays outside the model.