StructuredAI can now ask Jev, OpenAI Decisions and Mercury Decide

Rafael

• 2026-10-19

A lot of the code in a workspace asks a model a question with a fixed set of answers. Which team should get this ticket? Is this email about an invoice? How frustrated is this customer, on a scale of four? Asked of a chat model, each of those becomes a prompt, a JSON schema and a parser for the reply, and the answer comes back without any sense of how sure the model was.

Since September there is a class of hosted model built for exactly this. TypeSafe introduced Jev and called it a "System One" model: you define the questions and their possible answers up front, and it returns a probability for each answer instead of writing text. OpenAI followed with the Decisions API, in public beta since October 6. Inception lists a third, Mercury Decide, beside Mercury 3, which launched today.

Curiosity already had an API with that shape. StructuredAI is available in every code scope of a workspace (endpoints, AI tools, scheduled tasks, connectors) and asks three kinds of question: pick one of several options, place the text on an ordered scale, or say whether a statement holds. Until now it answered them with a local checkpoint running on the CPU, or by asking an LLM to estimate the probabilities. From this release it can also send them to any of the three hosted decision models.

The same questions, a different engine

The questions are written once, with a builder:

using Mosaik.AI;

var options = StructuredAIOptions.Decision(DecisionProviders.MercuryDecide, userUID: CurrentUser);

var answers = await StructuredAI.AskAsync(ticket.Body, q => q
    .Choice("department", "Which team should handle this?", o => o
        .Option("billing",   "payments, invoices and refunds")
        .Option("technical", "bugs or integration problems")
        .Option("other"))
    .YesNo("urgent",      "The message conveys urgency")
    .Score("frustration", "How frustrated is the customer?", "calm", "annoyed", "very angry"),
    options: options, cancellationToken: CancellationToken);

bool needsReview = answers["department"].Confidence < 0.8;

Drop the options argument and the same call runs on the local English checkpoint. Swap DecisionProviders.MercuryDecide for DecisionProviders.TypeSafeJev or DecisionProviders.OpenAIDecisions and nothing else changes: the answers have the same type, with a probability per option and a confidence per question.

DecisionProviders is a class the workspace generates for its code, with one constant per provider an administrator has set up. Code that names a provider the workspace does not have fails to compile, instead of failing on the first request. The same mechanism now covers LLM providers, as LLMProviders.<Name>.

All the questions about one input travel in a single request. AskManyAsync runs four inputs at a time by default, and re-ranking sends one yes/no request per candidate.

Two wire formats for three vendors

The vendors agree on the idea and differ in the details:

Mercury Decide accepts the same request as TypeSafe's System One API: a state and a map of questions by id, each of type noul, choice or score. OpenAI's format sends an input and a list of named questions of type predicate, choice or score, and it has no field for what a yes or a no means, so StructuredAI appends those descriptions to the question text. The answers come back in the same StructuredAnswers either way.

Because no vendor charges for output, the cost of a decision is the length of the input. A support ticket of 400 tokens costs $0.000008 on Mercury Decide at the launch price, so a million tickets cost about $8.

What we measured, and what we did not

We ran Mercury Decide against a live key from a test workspace. A request with a choice, a score and a yes/no question took between 0.3 and 1.1 seconds end to end, and a re-ranking test gave the relevant candidate 0.9996 and the unrelated one 0.0004. Every request appeared on the LLM usage page under the model the vendor reported, with its input tokens.

We tested the Jev and OpenAI integrations only as far as the vendors' refusal of an invalid key. TypeSafe quotes 70 to 500 ms end to end for Jev on its own page; we have not reproduced that.

Check the confidence before you route on it

A probability is only useful as a threshold if it means what it says. Two recent posts tested how far the vendors' numbers can be taken at face value, which matters before you pick a threshold like the 0.8 in the example above.

A preview test of the model behind OpenAI's Decisions API ran 3,600 logic problems through GPT-6 Luna, before the Decisions API was documented, and found that when Luna stated 99% or more it was right 68% of the time. Jev's answers at the same stated confidence were right 98.9% of the time. The author notes the test used the general model with reasoning off and plans to repeat it against the Decisions API itself.

Red Hat's AI safety team benchmarked decision models against traditional guardrails on prompt injection and content safety. Jev scored first on content safety (86.20%) and fourth on prompt injection (86.35%, against 89.01% for a small DeBERTa classifier answering in 54 ms). Their conclusion is that decision models "do not reliably outperform" the alternatives, and are a capable alternative where no trained classifier exists. Much of the discussion on Hacker News argues that block-or-allow prompts are too simple a test, and that the case for a decision model is the question nobody has trained a classifier for.

The practical reading of both is the same: label a few hundred of your own cases, at the difficulty you will actually see, and check how often each confidence band is right before you set a threshold.

Which engine to use

The three engines answer different constraints:

• The local checkpoint keeps the text in the workspace and costs nothing per call. Its context is 512 or 1,024 tokens, and the English checkpoint reads only English.
• A decision provider reads up to 65,536 tokens and many languages, and sends every input and question to the vendor. Check that this is acceptable for the data first.
• An LLM provider suits a question that needs world knowledge or a long rubric. It is billed for output, and its probabilities are an estimate the model writes, not a distribution over the options.

Administrators set up decision providers on Manage → AI → Decision Providers. The page has a Test button that asks three questions about a sample text with the key on the form, before it is saved. The Decision Providers documentation has the setup steps and the error types, and the StructuredAI page covers the question builder.

Further reading

• Introducing System One Models and Jev, TypeSafe. The vendor's own description of what a decision model is and what it promises.
• Decisions API guide, OpenAI. The question types and the response fields, and the launch thread asking why anyone would pay for it.
• The OpenAI Decisions API needs a confidence you can trust. A calibration test with numbers, and a checklist for testing any decision model.
• Benchmarking AI decision models against traditional guardrails, Red Hat. The counterpoint: small trained classifiers are still competitive where they exist.