Decision Engine: Use cases

The presets are built in and usable via API, in chat and via MCP. Questions and options may still change; every preset therefore carries a version number that is echoed in every answer.

The Decision Engine does not answer a question with prose but with probabilities over a fixed set of options. This page shows what that is good for in practice — using the nine presets that ship with SovrGPT.

What a preset is

A preset is a server-side question pack: one or more questions with fixed options, levels or yes/no, plus a short instruction per question. You send only the preset id and the state — the text, document or JSON object to decide about. The questions live on our side so that they read the same on every call and for every customer. That is the prerequisite for calibrating them later and for quality reports per preset.

How to call a preset

curl https://sovrgpt.com/api/v1/decisions \
  -H "Authorization: Bearer $SOVR_KEY" -H "content-type: application/json" \
  -d '{
    "preset": "ticket-routing-v1",
    "state": "Since this morning I cannot log in."
  }'

Three things hold for every preset on this page:

• Answers are recommendations. Every answer carries abstain — with the default review_only it is always true. Your workflow decides what follows; the engine does not act. How to set a threshold rule instead is described under Release.
• Every choice question has a domain abstention — an option such as unclear or other, always the last one. If the model picks it, abstain stays true even with a threshold rule. For “unsure → a human reviews” that is more reliable than a percentage.
• Two presets expect a JSON object as state (Application complete? and Grounding check). Send the object directly as state, not as a string — the questions refer to its fields.

The full list with all questions and example states is returned by GET /v1/decisions/presets.

Ticket routing

Id: ticket-routing-v1 · For: customer service, helpdesk, shared service centres

A support mailbox or ticket system receives messages that someone has to read, assign to a team and order by urgency before anyone replies. The ticket system sends the message text as state; back come team, urgency level, review need and language as fields that sort the queue directly. A chat answer would be an explanation nobody reads — what is needed is one assignment per ticket in milliseconds, with a probability.

curl https://sovrgpt.com/api/v1/decisions \
  -H "Authorization: Bearer $SOVR_KEY" -H "content-type: application/json" \
  -d '{
    "preset": "ticket-routing-v1",
    "state": "Seit heute früh kann ich mich nicht mehr anmelden. Außerdem wurde meine Rechnung für September doppelt abgebucht — bitte prüfen Sie das dringend."
  }'

Using the answer. team picks the queue, urgency the position in it, language the template of the first reply. unclear and every ticket with needs_human: true is seen by a person before a reply goes out — the engine routes, it does not answer.

Building your own. Replace the three teams with yours — the description per option is the text the model reads, so prefer “invoices, payments, refunds” over just “accounting”. The abstention unclear stays in last place.

Inbox document classification

Id: inbox-document-v1 · For: administration, back office, mail room, accounting

A central postal address or scan mailbox receives dozens of letters every day: supplier invoices, reminders, contracts, job applications, official mail, advertising. Today a person opens every document, skims it and forwards it — the deadline is often only on page two. The DMS or mail server delivers the OCR text as state; afterwards a workflow sets the folder, the responsible unit and the deadline flag, and documents with a high need for action are at the top of the list at once. What is needed is one field per document with a probability, in milliseconds and for a fraction of a cent.

curl https://sovrgpt.com/api/v1/decisions \
  -H "Authorization: Bearer $SOVR_KEY" -H "content-type: application/json" \
  -d '{
    "preset": "inbox-document-v1",
    "state": "Sehr geehrte Damen und Herren,\n\nzu unserer Rechnung Nr. 2026-0871 vom 12.08.2026 über 1.845,20 € haben wir bislang keinen Zahlungseingang festgestellt. Wir bitten um Ausgleich bis spätestens 30.09.2026. Sollte die Zahlung bereits erfolgt sein, betrachten Sie dieses Schreiben als gegenstandslos.\n\nMit freundlichen Grüßen\nBuchhaltung Müller & Sohn GmbH"
  }'

Using the answer. doc_type picks the folder and the responsible unit, has_deadline sets the follow-up, action_level sorts the list. Everything that is other, carries a deadline or has action level 3–4 goes to a person — the engine pre-sorts, it does not process.

Building your own. The state is the OCR text; headers and footers may stay in. If you need your own document types (delivery note, order confirmation), add them as options with a clear boundary and keep other at the end.

Customer feedback analysis

Id: customer-feedback-v1 · For: customer service, customer success, product management

After a purchase, a support contact or a contract year, companies collect free-text feedback through surveys, shop reviews and social media — often thousands of entries nobody reads in full. The text (optionally with an NPS value or the source as JSON) is the state; afterwards four values go to the CRM or BI system: a high churn risk creates a task for customer success, topic distributions feed the product dashboard, and only feedback with “response needed” lands in the work queue. A chat model could summarise every review — what is needed are four comparable fields per entry that you can put thresholds on.

curl https://sovrgpt.com/api/v1/decisions \
  -H "Authorization: Bearer $SOVR_KEY" -H "content-type: application/json" \
  -d '{
    "preset": "customer-feedback-v1",
    "state": "Die Kamera macht bei Tageslicht wirklich gute Bilder, aber nachts ist alles verrauscht, da hilft auch der Nachtmodus nicht. Der Support hat freundlich geantwortet, konnte aber nichts ändern. Für 349 € hätte ich mehr erwartet. Wenn das angekündigte Firmware-Update nichts bringt, geht sie zurück."
  }'

Using the answer. Churn risk 2–3 and every needs_response: true entry is handled by a person; topic and sentiment go to the dashboard in aggregate. The engine decides who comes first — never what is answered.

Building your own. For sentiment and churn_risk, expected_index gives a finer value than the chosen level — useful when charting trends over months. Use sovr-decision-v2 for that, whose probabilities are finer-grained.

Lead qualification

Id: lead-qualification-v1 · For: sales, inside sales, marketing automation

Website form, trade fair and e-mail bring in enquiries every day, from a bachelor's thesis to a corporate tender. Sales should call the few hot leads within an hour but works through the list chronologically. The enquiry text (plus form fields such as company or headcount) is the state; afterwards the CRM builds a priority from fit and timeline: a strong fit with a short horizon goes straight to an account manager, a weak fit without a timeframe into the nurturing track. Sales needs four fields that are named the same in every record and can be sorted by threshold.

curl https://sovrgpt.com/api/v1/decisions \
  -H "Authorization: Bearer $SOVR_KEY" -H "content-type: application/json" \
  -d '{
    "preset": "lead-qualification-v1",
    "state": "Betreff: Anfrage KI-Assistent\n\nGuten Tag, ich bin IT-Leiterin eines Maschinenbauunternehmens mit rund 850 Mitarbeitenden an drei Standorten. Wir suchen bis Ende Oktober eine DSGVO-konforme KI-Lösung für unsere 120 Konstrukteure, da unser bisheriger Anbieter zum 31.12. den Dienst einstellt. Das Budget für 2027 ist freigegeben. Können wir nächste Woche telefonieren?\n\nViele Grüße\nDr. Karin Vogt"
  }'

Using the answer. fit and timeline become a priority; a strong fit with timeline 3–4 goes straight to a person. The engine prioritises, it does not disqualify — every enquiry stays visible, and sales decides about quote and contact.

Building your own. Form fields belong in the state, most simply as a JSON object with the free text as one field. If you need an industry question, add it as a choice with an other option.

Public-authority inbox

Id: behoerden-posteingang-v1 · For: public administration

The mail room of a city administration receives hundreds of e-mails and scanned letters every day — applications, objections, complaints, notices, advertising. Today an employee reads every message and distributes it by hand; for objections with deadlines, every day of idle time is a liability risk. The engine delivers four machine-readable values per message with which the document management system puts the message into the right inbox, gives deadline matters a follow-up and presents escalations to the head of office — with a rule such as “unclear or review needed → mail room, otherwise inbox”.

curl https://sovrgpt.com/api/v1/decisions \
  -H "Authorization: Bearer $SOVR_KEY" -H "content-type: application/json" \
  -d '{
    "preset": "behoerden-posteingang-v1",
    "state": "Sehr geehrte Damen und Herren, gegen den Bußgeldbescheid vom 3. September 2026 (Az. 0815/26, Parken im eingeschränkten Halteverbot) lege ich hiermit fristgerecht Widerspruch ein. Mein Fahrzeug stand zum genannten Zeitpunkt nachweislich in der Werkstatt, die Rechnung liegt bei. Ich bitte um Aufhebung des Bescheids. Mit freundlichen Grüßen, Katrin Vogel"
  }'

Using the answer. zustaendigkeit picks the inbox, fristrelevant sets the follow-up, eskalation presents the case to the head of office. unclear and everything below the threshold stays in the mail room; objections and escalations are never filed without review by a case worker, and the engine never replies itself.

Building your own. The five units are a typical, not a complete, administrative structure. Adapt the options to your organisation chart — one list of duties per option, as above, so that the model assigns “dog tax” to the treasury and not to the public order office.

Application complete?

Id: antrag-vollstaendigkeit-v1 · For: public administration · State: JSON object

An online application portal (housing benefit, childcare place, basic income support) stores every application as a structured record with mandatory fields, a list of documents and a scan status. After receipt, someone has to check whether the case can be processed at all or whether documents must first be requested — today a manual review that takes days and eats into the processing deadline. The engine answers the pre-check at once: complete or not, what is missing, whether the data is consistent and which step follows. Because the answer is structured, the case system can prepare a request letter with the right list of documents or hand the application to case processing.

The state is an object with the fields antragsart, eingangsdatum, pflichtfelder (object), erforderliche_unterlagen (list of names), eingereichte_unterlagen (list with name and lesbar), unterschrift_vorhanden and anmerkung. The field names are German because the questions refer to them.

curl https://sovrgpt.com/api/v1/decisions \
  -H "Authorization: Bearer $SOVR_KEY" -H "content-type: application/json" \
  -d '{
    "preset": "antrag-vollstaendigkeit-v1",
    "state": {
      "antragsart": "Wohngeld (Mietzuschuss)",
      "eingangsdatum": "2026-09-18",
      "pflichtfelder": { "name": "Anna Berger", "geburtsdatum": "1987-04-12", "anschrift": "Lutherstraße 4, 07743 Jena", "haushaltsmitglieder": 2, "iban": "DE89370400440532013000" },
      "erforderliche_unterlagen": ["Mietvertrag", "Einkommensnachweis", "Mietbescheinigung"],
      "eingereichte_unterlagen": [ { "name": "Mietvertrag", "lesbar": true }, { "name": "Einkommensnachweis", "lesbar": false } ],
      "unterschrift_vorhanden": true,
      "anmerkung": "Einkommensnachweis ist ein unscharfes Handyfoto."
    }
  }'

Using the answer. naechster_schritt drives the case system: nachfordern prepares the letter with the list of documents, bearbeiten releases the application. Every request letter is approved before sending, ruecksprache and unclear always land with a case worker, and the engine never decides on approval.

Building your own. The field names are part of the question — if your portal uses other names, map them before the call or write your own questions that name your fields. Do not send the state as a string: the object is serialised canonically so that the same application always yields the same state.

Publication release check

Id: veroeffentlichung-check-v1 · For: communications, data protection and compliance, public administration

Press office, social media team and departments of an authority or a company publish texts every day — press releases, posts, FAQ answers, newsletters, public council documents. A typical data protection incident is not an attack but a well-meant text that names third parties' names, addresses, licence plates or health details. The engine checks every draft before the click on “publish” and returns a release recommendation that the editorial system can show as a traffic light or enforce as a block — for every draft, not just the ones someone has doubts about.

The state is the text to check; a first line Kanal: … only describes the channel and is not part of the text.

curl https://sovrgpt.com/api/v1/decisions \
  -H "Authorization: Bearer $SOVR_KEY" -H "content-type: application/json" \
  -d '{
    "preset": "veroeffentlichung-check-v1",
    "state": "Kanal: Facebook-Seite der Stadt\n\nWas für ein Fest! Über 2.000 Gäste haben gestern mit uns den Marktplatz gefüllt. Ein besonderer Dank geht an Familie Schmidt aus der Goethestraße 12, die den Kuchenstand organisiert hat, und an die Freiwillige Feuerwehr für die Absicherung. Oberbürgermeisterin Dr. Müller eröffnete das Fest um 14 Uhr."
  }'

Using the answer. freigeben is a recommendation to the editors, not an approval. nicht_freigeben and unclear always go to the data protection officer or legal department; ueberarbeiten goes back to the author with the two yes/no values as a hint. No text is changed by the engine.

Building your own. The channel line is the place for context the model should know without checking it — the audience, say, or whether humour fits the channel. The preset does not replace a legal review.

Agent handoff

Id: agent-handoff-v1 · For: AI agents, platform development

An assistant that knows web search, company knowledge and human handover has to decide before every answer which path to take — today usually a subordinate clause in the prompt that the answering model sometimes follows and sometimes does not. The agent handoff makes this decision a separate, measurable step before the expensive answering model even runs: only what needs the web goes online; only what concerns internal rules searches the knowledge base; only what a human has to decide lands in the queue. With the privacy flag, the workflow can hold a request back from the web search.

curl https://sovrgpt.com/api/v1/decisions \
  -H "Authorization: Bearer $SOVR_KEY" -H "content-type: application/json" \
  -d '{
    "preset": "agent-handoff-v1",
    "state": "Wie viele Urlaubstage habe ich laut unserer Betriebsvereinbarung im ersten Beschäftigungsjahr? Ich bin seit März dabei."
  }'

Using the answer. action picks the tool, sensitive_data: true blocks web search for this request. On human, on unclear and from risk 2 upwards there is no automatic reply — a human sees the case first.

Building your own. Instead of a single text you can send the conversation so far as messages ([{role, content}]); the handoff then decides in context. Your own tools become your own options — with the name your agent uses internally.

Grounding check

Id: grounding-check-v1 · For: AI agents, IT, quality assurance · State: JSON object

A RAG system delivers answers with sources — but in operation nobody checks whether the answer really reflects the sources or adds prior knowledge. The grounding check is the guard after answer generation: it receives question, sources and answer as one state and returns the degree of support, a fabrication flag, a contradiction flag and a release verdict before the answer reaches the person asking. As a decision rather than a chat answer this is done in milliseconds and can be built into the pipeline as a hard rule — without a second model writing an explanation that someone would have to parse again.

The state is an object with question, sources (list of texts) and answer.

curl https://sovrgpt.com/api/v1/decisions \
  -H "Authorization: Bearer $SOVR_KEY" -H "content-type: application/json" \
  -d '{
    "preset": "grounding-check-v1",
    "state": {
      "question": "Wie lange gilt die Garantie auf das Modell X200?",
      "sources": ["Produktblatt X200: Herstellergarantie 24 Monate ab Kaufdatum. Akkus sind von der Garantie ausgenommen."],
      "answer": "Die Garantie auf das X200 beträgt 24 Monate ab Kaufdatum; Akkus sind von der Garantie ausgenommen."
    }
  }'

Using the answer. release goes out automatically, revise and unclear land in post-processing, block is never delivered. Every abstention is logged with question and sources — that is your test set for later.

Building your own. The check only sees what is in sources. Send exactly the passages the answering model received — no more, no less — otherwise the guard judges a different basis than the answer.

Designing your own questions

The presets are examples, not a limit: with questions instead of preset you define your own. What proved useful while building the nine presets:

• The abstention is the last option. Every choice question over free text gets an unclear or other at the end. The model needs a permitted way out, otherwise the question forces an assignment nobody wants.
• At most 26 options, at most 10 levels. Every option gets a letter, every level a digit. A longer list does not add discrimination anyway — a better description per option does.
• Levels are ordered, lowest first. A score is a scale, not an assortment — expected_index and normalized_score only make sense then.
• The state is data. It is never read as an instruction; everything the model is supposed to do goes into instructions. An “ignore all rules” inside the state stays text.
• Order matters. Options and questions are evaluated in source order, and a model may react to the order. To rule that out, test with the options swapped.
• Keep instructions short and decisive. Say what the decision is based on (“the main purpose, not subordinate clauses”) and when the abstention is right. Examples help; exceptions to exceptions do not.
• v2 for graded probabilities. sovr-decision-v1 is very decisive — mostly 1.0 or 0. If you want to put thresholds on max_probability or expected_index, use sovr-decision-v2.

The limits (questions, characters, images) and the meaning of the answer fields are in the API reference.

Trying it in the product

• Playground: logged in, via the sidebar → Decision Engine. Every preset can be run there with its example state or your own text — with real inference and the full answer, including probabilities and abstain reasons.
• In chat as the “Decide” tool: enable the Entscheiden pill in the composer. The language model then calls the decision_engine tool — with a preset or with its own questions derived from your request — and summarises the decision with probabilities. Handy for trying a preset on real texts before wiring it into a workflow.
• Via MCP: the authenticated MCP server offers sovrgpt_decide (one 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 three paths run the same engine with the same presets — what works in the playground behaves the same via API.