In-scope request check

Decide whether a message is about something your team supports before trusting a routing choice.

Problem

A Choice question always picks one of its options, even when none applies. A recruiter email or a question about another company's product would still be routed to one of your teams.

Goal

Give routing a way to say "none of these", so off-topic messages reach a general inbox instead of a product team.

Input / state

The message as it arrived, plus the list of products or services your support team covers.

message: The customer's message, unedited.
supported_products: Names of the products or services your team supports.

Decision question

NoulQuestion key in_scope

Is this message asking for help with one of the products or services in `supported_products`?

What counts as yes and no

trueThe message asks about, reports a problem with, or requests a change to one of the listed products or services.
falseThe message is about something not listed, is marketing or recruiting outreach, or asks for nothing related to the listed products.

Allowed outcomes

Decided in your code from the answer and its confidence. Thresholds are yours to set and test.

In scopeProbability of yes is above your upper threshold (0.7 is a suggested starting point).
UnclearProbability falls between your two thresholds.
Out of scopeProbability of yes is below your lower threshold (0.3 is a suggested starting point).

Example scenarios

Predefined demonstrations. No model is called; the outcome shown is an illustrative judgment.

Example state

{
  "message": "I can't log in to the analytics dashboard since this morning. The password reset email never arrived.",
  "supported_products": [
    "Analytics dashboard",
    "Billing portal",
    "Mobile app"
  ]
}

Outcome

Illustrative

In scope

Probability of yes is above your upper threshold (0.7 is a suggested starting point).

Why

The message names a listed product and asks for help with it.

Better together with

Complementary classifiers, and what each one adds here.

Support ticket routingChoice
Its companion check: trust the team choice only when the message is in scope.
Combined inSupport inbox triage
Agent tool routingChoice
The same "does any option fit?" guard keeps an assistant from forcing a tool call on an off-topic request.

Used in chains

Support inbox triageStep 1 of 4

Sources

Primary documentation this classifier builds on. Scenarios on this page are illustrative, not taken from production use.

SourcedTypeSafe docs · Pattern
Companion Noul
Pairs a Choice with a Noul asking whether any option fits, because a Choice always picks an option even when none applies.
SourcedTypeSafe docs · Pattern
Screen with a Noul first
Uses two thresholds (0.7 and 0.3 as starting points) so a yes, a no and an unsettled answer each get their own handling.

Using it well

Ask it in the same request as the routing question. Questions are answered independently, so it adds no hidden context to the routing answer.
Use the routing answer only when this check is a clear yes.
Give the unclear band its own handling instead of rounding it to yes or no.
Tune both thresholds on a labelled sample of your own messages.

Request definition

POST https://api.typesafe.ai/v1/systemone

{
  "model": "jev-latest",
  "state": {
    "message": "<message>",
    "supported_products": "<supported_products>"
  },
  "questions": {
    "in_scope": {
      "type": "noul",
      "instructions": "Is this message asking for help with one of the products or services in `supported_products`?",
      "criteria": {
        "true": "The message asks about, reports a problem with, or requests a change to one of the listed products or services.",
        "false": "The message is about something not listed, is marketing or recruiting outreach, or asks for nothing related to the listed products."
      }
    }
  }
}

Request shape from the System One API reference; a Kev server accepts the same body. Replace the placeholder state with your data. Requests need your own API key or server.