Typed decisions: asking a model for a value, not a paragraph

A typed decision is a question to an AI model where you declare the answer type and the allowed options before it reads the input: one label from a list, a level on a scale, or the probability that a statement is true. The model returns only a value from that space, with probabilities, so code can act on it.

Most software that "uses AI to decide" is really asking a question with a small, known answer space. Which team should own this ticket? How urgent is it? Is this message a phishing attempt? The answer is not an essay. It is a value from a set you already know: a label, a level on an ordinal scale, or a yes/no probability.

A typed decision makes that explicit. Before the model reads the input, you declare three things:

1. The state: the thing being judged, such as an email, a ticket, a JSON record or a conversation.
2. The question: a short natural-language instruction, for example "Which department should handle this request?"
3. The answer type and its options: the set of labels, the ordered levels, or the true/false pair that a valid answer must come from.

The model's job is then narrow and checkable. It does not write an answer. It distributes probability over answers you already enumerated. Every output is valid by construction, because the only things it can return are the things you listed.

This is the same idea as a type signature in a programming language. A function typed (Ticket) -> Department cannot return a haiku. A typed decision model cannot either.

The usual alternative is to prompt a generative model ("Reply with one of: billing, technical, sales, other") and parse what comes back. That works in a demo and becomes a maintenance problem at volume.

The deeper benefit is that a typed answer composes with ordinary code. A choice feeds a switch statement. A score feeds a sort order or an SLA timer. A noul probability feeds an if p > 0.8 gate. None of these need a second model to interpret the first one's prose.

Typed decisions do not remove the need to evaluate. A typed model can still pick the wrong option with high probability. What typing removes is a whole class of format failures, so the failures you are left with are judgement failures, which you can measure with accuracy and calibration metrics. See calibrated probabilities for why the distribution matters as much as the argmax.

A typed decision request has a fixed shape. Laya uses the same shape as TypeSafe's Jev decision API, which introduced the /v1/systemone protocol:

{
  "state": { "subject": "Duplicate charge", "body": "We were billed twice for March." },
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which department should handle this request?",
      "criteria": { "billing": "invoices, payments, refunds", "technical": "bugs, outages", "other": "everything else" }
    },
    "urgency": {
      "type": "score",
      "instructions": "How urgent is this request?",
      "criteria": ["not urgent", "soon", "critical deadline or blocking issue"]
    },
    "refund_requested": {
      "type": "noul",
      "instructions": "Does the user explicitly request a refund?"
    }
  }
}

• state can be a string, an object or a list (for example a conversation). Objects are serialised to JSON before the model reads them, so field names such as subject and body are visible to the model and can be referenced in instructions.
• questions is a map from your own ids to question definitions. The ids come back unchanged in the response, so you never match answers by position.
• type is one of three primitives: choice, score or noul. They are covered in depth in choice, score and noul.
• criteria defines the answer space. For choice it is a map of label to description (or a plain list of labels). For score it is an ordered list of level descriptions, index 0 first. For noul it is optional and can describe what true and false mean.

Laya is an encoder model, not a text generator. For each question it builds one token sequence:

[CLS] <type> question: <instructions> [SEP] [MASK] option0 [MASK] option1 ... [SEP] <state> [SEP]

Every option gets its own [MASK] marker. The encoder (ModernBERT-large for the English checkpoint, mmBERT-base for the multilingual one) reads the whole sequence bidirectionally, a small two-layer decision head refines it, and a scorer reads one logit off each marker. A softmax over those logits is the answer distribution. A learned type embedding tells the model whether it is answering a choice, score or noul. The mechanics are described in option-marker scoring.

Three consequences follow directly from that design:

1. The answer space is defined at request time. There is no fixed label head, so a new schema needs no retraining. You can change the options on the next call.
2. All questions in a call run in one batched forward pass. The model card reports 39.5 ms for one question and 158.6 ms for ten on the English checkpoint on a T4 GPU, and 32.8 ms and 72.3 ms on the multilingual checkpoint.
3. Nothing is generated. The response contains no free text from the model, so there is nothing to parse. See hallucination-free decisions for what that does and does not guarantee.

The output for each question is typed as well:

"Typed decisions" is also the name of a specific benchmark: 400 cases and 2,000 decisions across four synthetic workflows (customer service, invoice processing, security incidents and agent-trace observability). The Laya family includes a checkpoint fine-tuned on that benchmark's training split, laya-typed-decisions.

The model card reports, on that benchmark:

Two honest readings. First, the fine-tuned checkpoint is strong on the workflows it was trained on. Second, the base checkpoints are below the majority-class baseline on this benchmark zero-shot. The card says it plainly: Laya is "a fast base to specialise, not a zero-shot decision engine" for this kind of multi-field workflow. If your schema resembles one of the four workflows, the specialised checkpoint is worth trying. If it does not, plan to evaluate the base checkpoints on your own data, and consider fine-tuning. The trade-off is discussed in zero-shot vs fine-tuned.

A few rules drawn from the model card's limitations and from how the sequence is built:

• Keep option sets small. Options share a fixed option budget (head_max_len, 192 tokens on the English checkpoint, 256 on multilingual). At 77 options each label gets roughly 3 to 4 tokens, and on Banking77 Laya scores 0.425 against Jev's published 0.870. For large label spaces, split into a coarse question and a fine question.
• Describe options, do not just name them. "billing": "invoices, payments, refunds" gives the scorer something to match against. Descriptions are truncated at 48 tokens per option.
• Include an escape option. An other choice lets the model put mass somewhere honest when nothing fits.
• Check noul on your data. The card documents that noul can follow its false: / true: labels rather than the state. If answers look stuck, ask the same thing as a two-option choice with neutral keys.
• Treat score as the weakest primitive. The card reports SST-5 at 0.372. Use few, clearly separated levels.
• Calibrate before you threshold. The checkpoints ship over-confident. See temperature scaling.

Laya Studio hosts the open Laya checkpoints behind the /v1/systemone protocol. Get a key at /signup and send:

curl -s https://api.laya.studio/v1/systemone \
  -H "Authorization: Bearer $LAYA_STUDIO_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "state": {
      "subject": "Duplicate charge on invoice #4411",
      "body": "We were billed twice for March. Please refund the duplicate today or we will cancel."
    },
    "questions": {
      "department": {
        "type": "choice",
        "instructions": "Which department should handle this request?",
        "criteria": {
          "billing": "invoices, payments, refunds",
          "technical": "bugs, outages, system errors",
          "sales": "pricing, new contracts",
          "other": "everything else"
        }
      },
      "urgency": {
        "type": "score",
        "instructions": "How urgent is this request?",
        "criteria": ["not urgent", "soon", "critical deadline or blocking issue"]
      },
      "refund_requested": {
        "type": "noul",
        "instructions": "Does the user explicitly request a refund?"
      }
    }
  }'

The response has this shape (the numbers are illustrative, not a benchmark; routing.detection is trimmed):

{
  "model": "laya-rl-agent",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "billing",
      "probabilities": { "billing": 0.9121, "technical": 0.0287, "sales": 0.0214, "other": 0.0378 },
      "confidence": 0.7173,
      "action": { "act_probability": 0.9987 }
    },
    "urgency": {
      "type": "score",
      "score": 1.4681,
      "legend": { "0": "not urgent", "1": "soon", "2": "critical deadline or blocking issue" },
      "probabilities": { "0": 0.0812, "1": 0.3695, "2": 0.5493 },
      "confidence": 0.18,
      "action": { "act_probability": 0.9991 }
    },
    "refund_requested": {
      "type": "noul",
      "noul": 0.9312,
      "confidence": 0.9312,
      "action": { "act_probability": 0.9994 }
    }
  },
  "usage": { "input_tokens": 212, "output_tokens": 0 },
  "routing": { "model": "english", "repo": "convaiinnovations/laya", "reason": "English Latin text" }
}

This call is billed its input tokens (1 credit = 1 input token); each of the three questions reads the state once. See /pricing for the 5 free runs and plans, and /docs for the full reference.