Skip to content
ajan.io

The model suggests.Your policy decides.

Which team should take this request, is the evidence enough to answer, should this go to a person: make the decisions you take hundreds of times a day consistent. Your rules look first; with no rule, a fast decision model estimates probabilities, the agent's language model steps in when needed, and anything below the threshold goes to a human. Why each decision was made stays on record.

Risk class

1Request

Invoice portal

The VAT amount on last month's invoice looks wrong. Could you send a corrected invoice?

Which team should take it?

Input sent to the decision

channel
invoice_portal
amount
1,240
email
m***@example.com

2Cascade

  1. RuleChecked in order, first match wins
    billing Β· invoice portal Β· 1.00
  2. Decision modelLaya Β· local decision model
    Not needed
  3. Language modelThe agent's model Β· strict JSON
    Not needed
  4. HumanMy tasks β€Ί Decision review
    Not needed

3Outcome

Calibrated confidence

Execute1.00

Where the flow continues

billing

The same confidence turns into a different action under a different risk class. Demo: runs on fictional requests and doesn't call a real model. Confidence values are examples.

01Decision types

Three kinds of decision

Not open-ended chat: bounded questions whose answers are defined up front.

A decision model doesn't write text, it makes a choice. You define the options, what each one means and a short instruction; the decision model says which option is right and how likely.

One of several options

Choice

β€œWhich team should take this request?”

An ordered level, 2–10 steps

Score

β€œHow urgent is this complaint?”

A probabilistic true or false

Yes / No

β€œIs the evidence enough to answer this?”

02Cascade

Cheapest first, uncertain to a human

Each stage steps in only where the previous one couldn't be sure.

If you have a firm business rule, the model is never called. Without one, the decision model estimates probabilities in milliseconds. If confidence sits just below the auto threshold, the agent's language model is asked. What remains uncertain goes to a human, or the flow continues from its "Uncertain" port.

  1. Instant

    Rule

    First rule whose conditions all hold

    Confidence 1.00. No model is called.

  2. Fast

    Decision model

    When no rule matches

    Laya, a multilingual classifier running on our own infrastructure, returns probabilities and calibrated confidence.

  3. Deep

    Language model

    When confidence falls short of auto

    The agent's own model answers in strict JSON; its self-reported confidence counts for at most 0.95.

  4. Final say

    Human

    Below the threshold, or high risk

    A Decision review opens in My tasks; the chosen answer is recorded.

A hosted decision model (Jev) can join the cascade too. It is hosted abroad, so it switches on only after a contract and data processing consent are recorded.

Pick the ordering: local first, lowest cost, lowest latency or a custom cascade. A provider that fails three times in a row is taken out for 30 seconds and the cascade moves to the next one.

03Rules

The rule you know, before the model

Rules are evaluated in order; the first one whose conditions all hold wins.

If you have a firm rule such as "everything from the invoice portal goes to billing", don't try to teach it to a model, write it down. Rules are part of the decision definition and ship with its version. No free-form code runs; only defined comparisons are allowed.

  1. 1channel = invoice_portal∧amount > 0β†’ billinginvoice portalMatched
  2. 2subject contains "quote"∧customer_type ∈ {dealer, enterprise}β†’ salesenterprise quote
  3. 3error_code exists→ technicalhas an error code
Comparisonsequalsnot equalsinnot incontainsexistsnot exists>β‰₯<≀regex
  • Confidence 1.00

    A matching rule answers before the model, with certainty and no cost.

  • High risk still goes to a human

    For R3 and R4 decisions, the human review rule wins even when a rule matches.

  • Safe regex

    Regular expressions run with a 100 ms timeout; they can't lock up the rule engine.

04Thresholds

Risk sets the threshold

The same 90% confidence runs automatically at low risk and goes to a human at high risk.

Every decision has a risk class. As risk rises, the auto threshold rises and the failure behaviour gets stricter. Confidence isn't the provider's raw number; it's calibrated against measurements.

  1. R0Very low
    Ask a human β‰₯ 0.4, Ask a stronger model β‰₯ 0.6, Execute β‰₯ 0.8
    Try the next provider
  2. R1Low
    Ask a human β‰₯ 0.5, Ask a stronger model β‰₯ 0.72, Execute β‰₯ 0.92
    Try the next provider
  3. R2Medium
    Ask a human β‰₯ 0.6, Ask a stronger model β‰₯ 0.8, Execute β‰₯ 0.95
    Ask a humanThe auto threshold can't go below 0.90.
  4. R3High
    Ask a human β‰₯ 0.6, Ask a stronger model β‰₯ 0.85, Execute β‰₯ 0.97
    Fail closedGoes to a human by default.
  5. R4Critical
    Ask a human β‰₯ 0.6, Ask a stronger model β‰₯ 0.9, Execute β‰₯ 0.99
    Fail closedAlways goes to a human.
  • Uncertain
  • Ask a human
  • Ask a stronger model
  • Execute

Ignoring the decision and carrying on after a failure is forbidden for R3 and R4.

05Decision step

The Decision step in workflows

Every option is a port, plus an "Uncertain" port for when nobody can be sure.

Add a Decision step in the workflow designer and list the options; each option connects to its own branch. Yes/No decisions come with two ports. The confidence percentage can be used in later conditions. Describe the flow in plain language and the AI draft builds classification steps as Decision steps.

Draft with AISplit incoming support requests into billing, technical and sales; if unsure, ask the team lead.
  • Inline or registered

    Define the decision inside the step or call a registered decision key; inline definitions are versioned automatically too.

  • Review inside the flow

    A decision sent to a human pauses the flow, then continues down the chosen branch.

  • Mock answers in simulation

    When testing a flow, give the Decision step a sample answer and try each branch in turn.

06Human review

A human review is a learning record

The reviewer sees the model's suggestion, its confidence and its source; the choice is recorded.

When a decision goes to a human, a Decision review lands in that person's My tasks. They accept the model's suggestion or pick another option. That choice is recorded as an override and can be added to evaluation datasets. Models don't retrain themselves; your team decides what changes.

  1. Review

    A person accepts or changes the suggestion.

  2. Override record

    Suggestion, choice and reviewer are recorded.

  3. Dataset

    Records are collected as evaluation examples.

  4. New version

    The team measures and, if needed, publishes a new version.

When the real outcome is known later (say the request actually belonged to sales), it is added to the decision's record too.

07Versions and tests

Measure before you publish

Every version is immutable; it is measured in shadow and published once it passes the gate.

Each version of a decision definition is locked by a content fingerprint. Try a new version in the test console without publishing it, then measure it in shadow mode on real traffic without changing behaviour. Medium and high-risk decisions can't go live until they pass the measurement gate. Rolling back means re-publishing an older version.

  1. DraftOptions, instruction, rules
  2. EvaluationMeasured on labelled examples
  3. ShadowOn real traffic, behaviour unchanged
  4. CanaryLimited use
  5. ProductionThe default version
  6. DeprecatedTakes no new calls

Measurement gateR2 and above: at least 30 examples, accuracy at least 0.80

What you measure

  • Accuracy and coverage

    At which confidence threshold how much traffic runs automatically, and how accurately.

  • Calibration

    How well confidence matches real accuracy (ECE); a 10-bucket calibration profile.

  • Confusion matrix

    Which option gets mistaken for which, and macro F1.

  • Latency

    p50, p95 and p99 per provider, compared on the same dataset.

08Decision trace

A trace for every decision

Which version, which provider, what confidence, which action, and why.

Every execution leaves a trace: version and source, the providers tried and their outcomes, raw and calibrated confidence, the policy action and its reason code, latency and cost. A fingerprint of the input is kept instead of the input itself; you choose how much to store.

Execution trace6f0c…

decision
support.route Β· version 4 (production)
source
workflow Β· Request routing
input
sha256:9f2c…e41a Β· stored: redacted
result
technical
confidence
raw 0.74 Β· calibrated 0.71
policy
Ask a human Β· insufficient_confidence
latency
212 ms

Attempts

  1. 1.ruleskipped Β· no matching rule
  2. 2.layalow confidence Β· technical Β· 0.71
  3. 3.humantask opened Β· My tasks
  • Secrets never leave

    Fields such as password, token, API key, CVV and IBAN are always stripped from the input.

  • Personal data masked

    Emails and phone numbers are masked before reaching a decision provider.

  • You choose retention

    Store no input, only a fingerprint, a redacted copy or the full input.

09API

Call it from your own systems

Make the same decision outside a workflow, from your own application.

Call a registered decision through the API: one at a time, in a batch, or test an unpublished version. Use an idempotency key so a repeated request isn't processed twice. Rules, thresholds and versions are part of the decision definition and are managed through the API.

Request
POST /api/v1/tenants/{tenantId}/decisions/execute
{
  "decisionKey": "support.route",
  "version": "production",
  "state": {
    "channel": "email",
    "message": "The license key is rejected…"
  },
  "context": { "idempotencyKey": "ticket-1001" }
}
Response
{
  "executionId": "6f0c…",
  "result": {
    "type": "choice",
    "value": "technical",
    "rawConfidence": 0.74,
    "calibratedConfidence": 0.71
  },
  "provider": { "name": "laya" },
  "policy": {
    "action": "HumanReview",
    "reason": "insufficient_confidence"
  }
}
execute
One decision on the production or a given version
execute-batch
Many inputs, one call
test
Try an unpublished version with a chosen provider
outcome Β· override
Write back the real outcome and human corrections

10Inside the platform

The platform's own decisions run here too

The small decisions in every chat turn go through the same cascade, with the same trace.

Which agent answers, whether a search is needed, whether the evidence is enough to answer: these are defined in the decision layer too. The mode is kept per organisation and managed by our platform team; shadow is the default. If the decision layer has a problem, chat carries on with its usual behaviour.

  • Which agent answersagent.route
  • Is a knowledge search neededrag.required
  • What the query intendsretrieval.intent
  • Is the evidence enoughrag.answerability
  • Which tools are candidatestool.route
  • Which model classmodel.route
  • Is a human handoff neededconversation.handoff_required
  • Prompt injection signalsecurity.prompt_injection_signal

Mode per organisation

  1. OffThe decision isn't called.
  2. ShadowThe decision is made and measured; behaviour doesn't change.
  3. LiveThe decision's action is applied.

Chat decisions fall back safely: if the decision layer doesn't answer, chat works just as it does today.

Frequently asked

The most common questions about decision models and the decision layer.

All FAQs

A decision model doesn't generate text; it chooses among defined options and returns a probability for each. That makes it fast, cheap and measurable. The language model only steps in where the decision model isn't sure.

Define the decision you make most, measure it, then trust it.

Start free; add a Decision step to your workflow and leave the uncertain calls to your team.