Interested in a ServiceNow event built for developers? Registration for now[dev]26 is officially open!

Martin Rudack
Giga Sage

Jev is a pretty hyped topic at the moment. When I first read about it and understood the purpose of a System One model, I immediately realized this is exactly what we need on the ServiceNow AI Platform to build intelligent automations in a scalable way.

 

This article provides a brief overview of what Jev (and System One models in general) is, along with practical use cases you can implement today.

 

What is Jev?

Jev is not another new LLM, it is a new kind of model. It does not generate text, because it is not optimized for humans. It is optimized to be consumed by code.

 

Jev is a System One model. It makes fast, structured decisions that we can use directly in our Flows. While the input can be natural language, the outputs are typed decisions and probabilities. This means we can use the response directly in our code without having to parse or convert natural language back into a usable format.

 

According to TypeSafe.ai, Jev is 193.6x faster and 444.6x cheaper than frontier LLMs for System One tasks.

This makes it an incredibly promising tool for bringing fast, inexpensive, and intelligent automation to the ServiceNow AI Platform.

 

This article is not about how to send a request to a REST API. Instead, I want to inspire you with practical use cases that you can use in your flows.

 

The model uses primitives, which are essentially different types of question you can use. Currently, there are three different primitives supported:

  • Choice
  • Score
  • Noul

Let's start with a Noul example.

 

A Noul question is a yes/no question that returns the probability that the answer is “yes”. You receive a number between 0 and 1. A one means a clear yes and a zero a clear no.

 

The fact that the result is a probability and not a Boolean is very powerful. It allows you to handle questions differently in your automation based on the impact an error would have. The importance or the impact determines your threshold for when to automate and when to escalate to a human.

 

If an error is expensive then only execute the “yes” branch of your flow automatically if the response is 0.9 or above, or the “no” branch if it is 0.2 or less. Everything in between should be escalated to a human.


If the impact is low then maybe move the threshold to 0.75 and 0.3.

 

Use Case 1: Improve Resolution Notes / Save LLM Calls (Noul)

A while ago, I wrote two articles detailing ways to increase the quality of incident resolution notes.

 

Increase resolution notes quality with custom Now Assist Skills in Playbooks

Level Up Your Resolution Notes with UI Interactions and Now Assist Skills in the Australia Release

 

The core idea in both was the same, only the implementation was different. The first article used playbooks, the second one used UI Interactions.

 

The core idea is a custom skill which sends the provided resolution notes to an LLM before resolving the incident. The LLM checks if the notes meet professional standards and if they actually address the incident. If a problem is detected, it provides a reason or proposes an improved version.

 

If you have a high volume of incidents, this results in a massive number of expensive LLM calls where most of it hopefully aren't even necessary.

 

This is a perfect opportunity for Jev. Because Jev is fast and inexpensive, you can use it as a gatekeeper to evaluate the resolution notes first. The heavier, more expensive request to the LLM is only triggered if Jev detects a problem.

 

The Request

A request to Jev always contains three top-level attributes:

 

  1. State

The state is named like this because it should represent the internal state of the software.
In our example, this is the context of the Incident, meaning the short description, description and the resolution notes. The state attribute is not limited to a string. It could also be a JSON object or an array.

 

  1. Question

This attribute contains one or more questions, each containing a type, instructions, and criteria (criteria is optional for Noul questions). The instruction is the specific question the model should evaluate. For a Noul question, we use the criteria object to tell the model exactly what constitutes a "yes" or a "no".

 

  1. Model

The specific model version you are using (in this case, "jev-latest").

 

To use Jev in our Incident resolution example, the payload of the request would look like this:

{
  "state": {
    "short_description": "Microsoft Teams calls have no audio",
    "description": "During Microsoft Teams calls I can see other participants, but I cannot hear any audio. My headset works correctly with other applications.",
    "resolution_notes": "fixed - I have planted a tree."
  },
  "questions": {
    "is_professional": {
      "type": "noul",
      "instructions": "Does the provided resolution notes meet professional standards?",
      "criteria": {
        "true": "The resolution notes contain a brief issue summary, the root cause of the incident, actions taken, and verification that the problem is fixed.",
        "false": "The resolution notes contain no evidence of what the agent did, what the problem was, or if the problem is fixed."
      }
    },
    "fits_incident": {
      "type": "noul",
      "instructions": "Is the resolution note related to the problem described in the incident?"
    }
  },
  "model": "jev-latest"
}

 

 

 

The Response

The response clearly tells us that these resolution notes should be rejected, justifying the subsequent call to the LLM.

 

{
  "model": "jev-1.13.0",
  "answers": {
    "is_professional": {
      "type": "noul",
      "noul": 0.01
    },
    "fits_incident": {
      "type": "noul",
      "noul": 0.02
    }
  },
  "usage": {
    "input_tokens": 423,
    "output_tokens": 41
  }
}

 

Use Case 2: Find the correct Service Offering (Choice)

For a fast incident resolution, it is necessary that the incident is routed directly to the correct team. Ideally, you defined all your Service Offerings with the responsible teams and make them mandatory during incident creation. But let’s face it, not every organization is able to enforce mandatory Service Offerings for end-users.

 

This is another great use case for Jev. We don't need to generate text, we just need the system to make a decision between choices that already exist in ServiceNow.

 

This is how a Flow could look like:

Offering Flow.png

 

This time the choice primitive is used. The possible answers are the different Service Offerings the user is subscribed to, which we pass into the criteria object. The sys_id of the offering acts as the key, while the name and description serve as the value.

 

Request:

 

{
    "questions": {
        "correct_incident": {
            "instructions": "Which of the offerings is responsible for this incident?",
            "criteria": {
               "2c2cd4ff475fcfd0d6377212d16d4381": "SN Incident Mgmnt - Provides ServiceNow Incident Management capabilities...",
               "987e543b479fcfd0d6377212d16d4347": "SAP Finance Group Reporting - Provides SAP Group Reporting capabilities...",
               "c08e543f475fcfd0d6377212d16d4302": "SAP Transportation Mgmt Support - Provides operational support...",
               "79f6277f4745e210d6377212d16d437a": "Outlook - Provides corporate email, calendar, contacts...",
               "7cce587b479fcfd0d6377212d16d43ca": "EPIC Pharmacy - Provides EPIC pharmacy functionality...",
               "a6aed0ff475fcfd0d6377212d16d43c3": "EPIC MyChart - Provides patients with secure digital access...",
               "e5be947b479fcfd0d6377212d16d43d1": "EPIC Clinicals - Provides access to EPIC clinical functionality..."
            },
            "type": "choice"
        }
    },
    "model": "jev-latest",
    "state": "Incident Management not working - I am not able to create a new Incident or resolve one."
}

 

 

Response:

 

{
    "model": "jev-1.13.0",
    "answers": {
        "correct_incident": {
            "type": "choice",
            "choice": "2c2cd4ff475fcfd0d6377212d16d4381",
            "confidence": 1,
            "probabilities": {
               "79f6277f4745e210d6377212d16d437a": 0,
               "987e543b479fcfd0d6377212d16d4347": 0,
               "2c2cd4ff475fcfd0d6377212d16d4381": 1,
               "a6aed0ff475fcfd0d6377212d16d43c3": 0,
               "c08e543f475fcfd0d6377212d16d4302": 0,
               "7cce587b479fcfd0d6377212d16d43ca": 0,
               "e5be947b479fcfd0d6377212d16d43d1": 0
            }
        }
    },
    "usage": {
        "input_tokens": 798,
        "output_tokens": 292
    }
}

 

The response to a choice question provides the answer with the highest probability, the overall probability distribution across all options, and a confidence score. You can then use this confidence score in your flow to determine if the Service Offering should be set automatically.

 

 

Use Case 3: Does a KB Article Answer a Specific Question? (Choice + Noul)

This example is adapted from the TypeSafe.ai cookbooks. If you want to see what else Jev can do, I highly recommend checking them out.

 

In this example, we want to check if a Knowledge Base (KB) article actually contains the answer to a user's specific question. To achieve this, we combine a Choice and a Noul question in the same request.

 

The Choice question will rank each line of the article based on how well it answers the question. However, this alone doesn't tell us if the article holds the answer at all, because the probabilities of all choices will always add up to 1. Therefore, we also include a Noul question to verify if the answer exists in the text. If it does, the Choice question tells us exactly which line it is on.

 

We pass the KB article as the state, but we prepend line numbers to each line so we can reference them individually.

 

 

Question 1 (Choice):

The instruction will be: “Which line of the document contains the answer to: <Question>”.

 

The criteria will only contain the line numbers as keys with null values. A single Choice question supports up to 255 options. If the KB article is longer, you must split it across multiple requests.

 

 

Question 2 (Noul):

The instruction will be: “Does any line of the document address or answer: <Question>”.

Criteria will be:

criteria:{
                true: "At least one line of the document states or directly implies the answer",
                false:"No line of the document addresses this"
            }

 

All together the request looks like this:

 

{
  "model": "jev-latest",
  "state": "L0: <h1>ServiceNow Release Cycle and Current Releases</h1>\r\nL1: <h2>Overview</h2>\r\nL2: <p>ServiceNow continuously enhances the Now...",
  "questions": {
      "where": {
          "type": "choice",
          "instructions": "Which line of the document contains the answer to: What is the current ServiceNow release?",
          "criteria": {
              "L0": "None",
              "L1": "None",
             ...
              "L106": "None",
          }
      },
      "exists": {
          "type": "noul",
          "instructions": "Does any line of the document address or answer: What is the current ServiceNow release?",
          "criteria": {
              "true": "At least one line of the document states or directly implies the answer",
              "false": "No line of the document addresses this"
          }
      }
  }
}

 

Response: 

{
  "model": "jev-1.13.0",
  "answers": {
      "where": {
          "type": "choice",
          "choice": "L18",
          "confidence": 0.71,
          "probabilities": {
              "L106": 0.0,
              "L8": 0.0
          }
      },
      "exists": {
          "type": "noul",
          "noul": 0.99
      }
  },
  "usage": {
      "input_tokens": 6097,
      "output_tokens": 1586
  }
}

 

The Noul questions in the response show that the KB article provides an answer to the questions. Therefore, the answer is in line 18.