Decision Engine: AI decisions via API

The Decision Engine makes small, recurring decisions with AI: which team gets a ticket, how urgent a letter is, whether a human has to review. Instead of text it returns probabilities over a fixed set of answers that your software can use directly. You can use it via API, in chat, via MCP and in the playground.

How it works

You send a state (text, JSON, a conversation, optionally images) and questions with fixed answers. The engine reads off how likely each allowed answer is and returns those values. It does not write a sentence. The language model writes, the Decision Engine judges, and your rules decide what may happen next.

TypeSafe AI made this principle widely known with its product Jev. The Decision Engine implements it with open base models in EU data centres and does not store the state. We have not compared it with Jev or any other third-party product.

Three question formats

• Choice (choice): one of 2 to 26 options, such as team, category or next action.
• Yes/no (binary): does a statement hold? For example review needed, complaint, escalation.
• Score (score): one level on an ordered scale, such as urgency.

You can define your own questions freely. For common tasks there are ten ready-made presets; their questions, options and examples are on the Use cases page:

• Ticket routing (ticket-routing-v1): team, urgency and review need of a support message.
• Inbox document classification (inbox-document-v1): document type, deadline and need for action of a letter.
• Customer feedback analysis (customer-feedback-v1): sentiment, churn risk and response need.
• Lead qualification (lead-qualification-v1): fit, timeline and budget of a sales enquiry.
• Public-authority inbox (behoerden-posteingang-v1): type of matter, responsible unit, deadline and escalation.
• Application complete? (antrag-vollstaendigkeit-v1): formal pre-check of an application (JSON).
• Publication release check (veroeffentlichung-check-v1): data protection and tone before publishing.
• Agent handoff (agent-handoff-v1): which path an AI assistant takes.
• Grounding check (grounding-check-v1): whether a RAG answer is supported by its sources (JSON).
• Agent step gate (agent-step-risk-v1): whether an agent may execute a planned step (JSON).

How to use the Decision Engine

• Playground: logged in, via the sidebar → Decision Engine, with real inference.
• API: POST /v1/decisions with the decisions scope. The models sovr-decision-v1 and sovr-decision-v2 are also listed under GET /v1/models.
• Chat: the Entscheiden (decide) pill in the composer enables the decision_engine tool. The language model calls it with a preset or its own questions and summarises the result. That is how you test a preset on real texts.
• MCP: the authenticated MCP server offers sovrgpt_decide (a decision with a preset or your own questions) and sovrgpt_list_decision_presets (the presets with example states). The key needs the decisions scope.

All paths use the same runtimes and presets.

Automation with a recommendation

Every answer carries a recommendation. recommendation: "act" means your software can go ahead; "review" means a human should look first. The reasons are listed in reasons, for example a probability below the threshold, a chosen abstention such as unclear, or an answer that changes when the options are reordered.

You control how much runs automatically with policy.mode:

In autonomous mode your application should react to warning signals itself, for example by falling back to a safe default.

Until 23 Sep 2026, review_only was the default, without a double check. You get that behaviour at the previous cost with "policy": { "mode": "review_only", "stability_check": false }.

Double check

A choice answer can flip merely because of the order of the options, even when the displayed probability is close to 100 %. That is why the engine by default asks every choice question a second time with reordered options, in parallel with the first pass. If the answers differ, the recommendation is review (in autonomous mode only a warning signal in reasons). If only the second pass fails, the answer carries the warning signal stability_unavailable.

The double check protects you from answers that are only right thanks to a lucky order. It does not make the model more accurate: if it is wrong the same way in both orders, the check reports nothing. For choice questions it costs twice the input tokens; switch it off with "stability_check": false. All warning signals are in the API reference.

Two versions

Both run on open base models; we decide which runtime does the computing. Which version applies by default is set by an owner or admin of your organisation under Decision Engine.

How fast is a decision?

A chat answer is produced token by token. A decision needs a single model pass per question, or two parallel passes for choice questions with the double check; several questions run at the same time.

Measured warm, v1 takes about 65 ms per question and v2 about 200 ms; four questions in parallel take roughly twice as long. A chat answer to the same text takes 5 to 30 seconds. These are measurements without the double check, not a guarantee; we have not yet re-measured what the double check adds. The actual duration is in every answer under timing_ms.

Images work as the state but take considerably longer. We have not measured how long.

What the numbers do not tell you

• The values are uncalibrated. 0.92 means “92 % of the probability mass is on this option”, not “92 % likely to be correct”.
• A model can be wrong with full confidence. An empty reasons means “nothing remarkable found”, not “certainly correct”.
• recommendation is a recommendation to your workflow. The engine itself never acts.
• The state is treated as data, never as instructions. It is not stored; only token counts are billed.

We will quote accuracy figures only after calibration and quality reports per preset. Until then, test a preset on a sample of your real records, ideally with review_only, before letting decisions run automatically.