The decision model

A decision model is a fast model that answers yes-or-no questions about an event with a probability, in well under a second. Sift can use one to add escalations and second opinions to a filter. It is optional, off by default, and can never filter an event. This page explains what it powers, what it costs you, and how Sift behaves when it is not answering.

What it is, and what it is not

Sift supports TypeSafe’s Jev as its decision model. It is not part of Kindo: Sift calls it directly, with its own API key, from your Sift deployment. An admin turns it on; the model version is pinned, so it does not change under a running filter. See Decision model settings. With no decision model configured, every feature on this page is unavailable and says so, and each filter runs exactly as it would without them.

One rule: it only ever adds

The decision model may add an escalation or a suggestion. It may never keep an event from the agent. Sift never waits on it to decide whether to filter an event: every question is asked after the filter has decided, or when a person asks (Try it, Measure now, Check now). So a wrong answer, or an event crafted to mislead it, can cost at most an extra agent run, never a missed event.

What it powers

Feature	Where you see it	What it does	Offered when
Fit check	Overview › How it decides › Decision model; the gear icon (Administration) › Decision model	Measures how well the model reads the filter’s intent	Any filter with enough labels
Always-escalate rules	Settings › Pipeline, Always escalate block	Plain-language rules that send on filtered events	A configured model to watch; the model reads the filter at least partly to switch to Escalating
Verdict check	Settings › Labels; the Verdict check tab	Puts verdicts the model strongly disputes in front of a person	The model reads the filter well
Gold-set pool	The gold set build	Finds more likely matches for the gold set	Any new gold set

Fit check

Before offering anything else, Sift measures whether the model understands the filter. It asks the model the filter’s intent as a question about the filter’s newest labelled events, up to 300, and scores the answers against the agent’s verdicts. On the console’s meter, How well it reads the policy, “0% is guessing, 100% perfect”.

Band	Score	Unlocks
reads it well	50% or more	Always-escalate rules and the verdict check
reads it partly	5% to 50%	Always-escalate rules
does not read it	under 5%	Nothing

A reading needs at least 20 actionable and 20 benign labels. Sift takes the first one as soon as there are enough, again on the filter’s retrain schedule, and on demand with Measure now. If the band later falls below what a feature in use needs, the filter’s Actions tab says so; the feature is not switched off for you.

Always-escalate rules

The Always escalate stage can hold plain-language rules: questions such as “Does this mention a production database?” The model is asked every rule about each event the filter filtered. Where it answers yes with enough confidence, the event is sent to the agent after all; Sift calls this a rescue, and the agent’s verdict on it becomes an ordinary escalation label.

Reach caps how often a rule may fire: Narrow (0.1% of filtered events), Normal (0.5%) or Wide (2%). It fires only on a yes, so usually less.
Max rescues per hour (20 by default, 1 to 200) caps how many filtered events the rules may send in an hour. A rescue also counts toward the filter’s Max escalations per hour.
Of a burst Collapse folded together, at most one event is rescued.
In Watching mode the rules record what they would have sent and send nothing, so you can see their worth first. Watching needs only a configured model; switching to Escalating needs the model to read the filter at least partly. Try it asks a rule about sample events before you save.

See Use Collapse, Always escalate and Shape delivery.

Verdict check

The verdict check is a queue of the agent’s verdicts that the model strongly disagrees with, for a person to settle. It is off by default; an operator or admin switches it on in Settings › Labels (Switch it on), and it is offered only when the model reads the filter well.

A person answers each item The agent was right, The agent was wrong or Can’t tell. Right or wrong becomes an analyst label for that event, which outranks the agent’s verdict in training; Can’t tell writes none. Insufficient data verdicts are never checked.

Sift asks at most 200 questions per filter per day by default; an operator can change the cap. Once 30 items have been checked and fewer than 10% of them overturned the agent, the check pauses itself: the agent is reliable enough that the queue is not worth a person’s time. You can resume it. See Answer the verdict check.

Gold-set pool

With a decision model, a gold set build reads a wider pool of recent events and uses the model to find the ones most likely to match the intent, alongside an even spread of the rest. Rare matches are then more likely to appear in the 50 items you review. See The gold set.

When it is not answering

The decision model is never in the way of a filter scoring. When it fails repeatedly, Sift stops calling it for a minute and treats it as not answering, then tries again.

Always-escalate rules pause. Events filtered while the model is away are not rescued, and are asked when it returns, if that is within 24 hours. Field rules need no model and keep working. If the rules find no model for 15 minutes on a filter that is filtering, its Actions tab raises a fault, “Always-escalate rules are paused”, with Check the decision model. The rest of the filter keeps filtering exactly as approved.
The verdict check asks nothing new; open items stay answerable, and new verdicts are checked when the model returns.
A gold set build goes ahead without the model’s help, as it would with no decision model.

Where you manage it

The gear icon (Administration) › Decision model shows whether a model is configured and answering (Check now), calls and estimated cost per feature over the last 30 days, and how well it reads each filter. The console page is admin-only.