---
title: Jev AI in LiteTMS: where we've put it to work
description: See how TypeSafe's Jev AI model helps LiteTMS assess driver messages, places and imports, with JSON and Java examples explaining how it works.
slug: where-jev-helps-in-litetms
locale: en
date: 2026-09-24
updated: 2026-09-25
category: technology
tags: jev, ai, transport, driver-chat, data-import
author: LiteTMS Team
draft: false
---

We've built Jev, an AI model from [TypeSafe AI](https://typesafe.ai/blog/introducing-system-one-models-and-jev?utm_source=litetms.eu), into several LiteTMS workflows. It can help spot driver messages that need attention, check whether two place names refer to the same city, suggest how to read an import file and avoid translating a message that's already in the reader's language. These are small assessments inside a transport management system, not a new chat assistant for the office.

If the name is new to you, [our first Jev article](/en/blog/jev-ai-decisions-transport) explains the idea. A text-generating AI writes an answer to a prompt. Jev is designed to answer a narrower question, such as “Does this message need a reply?” LiteTMS then uses that assessment within the relevant workflow.

## Driver messages that deserve a closer look

A driver can send a routine update, ask a question or report a problem. The office shouldn't have to treat every message as equally urgent. In the driver chat, we've added a Jev check that sorts incoming messages by subject and assesses whether the dispatcher needs to act. It can work with written messages and voice notes once their speech has been transcribed.

For example, “The truck has a flat tyre” is different from “I've arrived.” A message assessed as needing action can appear in the attention view; a vehicle problem can also trigger an urgent notification. The office can still read the conversation, reply and mark the matter handled. Jev doesn't send an answer to the driver or decide how the breakdown should be resolved.

For a flat tyre message, the AI assessment can be shown in JSON like this:

```json
{
  "input": { "driver_message": "I have a flat tyre and cannot continue." },
  "jev_assessment": {
    "category": "vehicle_problem",
    "needs_action_probability": 0.94
  }
}
```

LiteTMS reads the category and action score. A vehicle problem with a score this high can appear as urgent, so the office knows to respond.

## Place names in orders and transport documents

A document might say “Köln” while the order says “Cologne.” A literal text comparison sees two different words, although both name the same city. We've added a Jev check for that specific question in AI-assisted order intake and in place checks for CMR documents.

During order intake, it can help choose between suggested places or leave an uncertain match for review. When checking a CMR, a confident same-city answer can clear a *place-name mismatch* that would otherwise be flagged. A separate AI step reads the document; Jev judges whether the place names match.

For the two city names, the assessment can look like this:

```json
{
  "input": { "document_place": "Köln", "order_city": "Cologne" },
  "jev_assessment": { "same_city_probability": 0.92 }
}
```

The high same-city score can clear the place-name mismatch. Other parts of the CMR check remain separate.

## Import files with unfamiliar headings

Moving information into a new system often begins with a spreadsheet. One file says “registration number,” another says “plate,” and a third has headings that are hard to recognize. LiteTMS first uses ordinary matching rules. Where those rules leave gaps, Jev can suggest what kind of records the file contains and which columns belong to which fields.

The suggestions are marked as AI-assisted, and the person importing the file can review the mapping before creating records. We've connected this approach to the general import wizard, as well as CRM deal and cargo imports. A related check can recognize a company already on the contractor list despite a different spelling, helping avoid duplicate entries when the match is confident enough.

Suppose an imported fleet spreadsheet uses “Unit ref.” for registration plates and “Internal ID” for the company's own vehicle codes. The sample values help Jev distinguish the two. When the usual header rules leave the registration field empty, the assessment can look like this:

```json
{
  "input": {
    "columns": {
      "col_0": { "header": "Unit ref.", "examples": ["WX 4821A", "PO 7619K"] },
      "col_1": { "header": "Internal ID", "examples": ["FLEET-17", "FLEET-42"] }
    },
    "field_to_match": "registration_number"
  },
  "jev_assessment": { "column": "col_0", "probability": 0.93 }
}
```

LiteTMS can then suggest the first column for registration numbers. The office reviews that mapping before importing the records. If no column fits, Jev can select “none,” leaving the field for the user to map rather than forcing a match.

## A small check before chat translation

Sometimes a message is already written in the language of the person reading it. Before running a full chat translation, LiteTMS can ask Jev to check that. A confident match lets the system show the original message; an uncertain answer sends it through the usual translation path. That keeps the decision narrow: the reader still gets the translation when the system cannot confidently skip it.

Take a driver writing “Jestem na miejscu, czekam na załadunek,” meaning “I've arrived and I'm waiting to load.” For a reader using Polish, the check can produce this assessment:

```json
{
  "input": {
    "message": "Jestem na miejscu, czekam na załadunek.",
    "reader_language": "pl"
  },
  "jev_assessment": { "language": "pl", "probability": 0.96 }
}
```

The detected language matches the reader's language, so LiteTMS can show the original. For a reader using English, the same Polish message still needs translation. A short reply such as “OK” is less informative: when the language cannot be confidently identified, the usual translation path remains available.

## How the Jev assessment fits into LiteTMS

Jev gives LiteTMS a useful signal, while the office keeps control of the work. The integrations are built in and run when the platform decision layer is activated, subject to company settings. If Jev is unavailable, the usual chat, document and import workflows continue.

## A technical look: TypeSafe Jev, JSON and Java

For readers who want to see what happens underneath, the useful starting point is the question we send. As [TypeSafe's quickstart](https://docs.typesafe.ai/introduction/quickstart?utm_source=litetms.eu) shows, a request contains `state`, the information to assess, and `questions`, the assessments to make. A `noul` question returns a number between 0 and 1 representing the probability that a statement holds. A `choice` question selects among named options, which is how we ask about a message's category.

Here is the action question on its own, using the model identifier configured in our OpenRouter integration:

```json
{
  "model": "typesafe/jev-1.13",
  "state": {
    "driver_message": "I have a flat tyre and cannot continue."
  },
  "questions": {
    "needs_action": {
      "type": "noul",
      "instructions": "The dispatcher must act on driver_message today: reply, give instructions, inform the customer or arrange help. Routine updates and thanks need no action."
    }
  }
}
```

The relevant part of the response can look like this:

```json
{
  "answers": {
    "needs_action": {
      "type": "noul",
      "noul": 0.94
    }
  }
}
```

The application reads `answers.needs_action.noul` and applies a rule. LiteTMS uses an action threshold of `0.55` for driver-message attention. After decoding the JSON, the same check can be written in Java:

```java
Double probability = 0.94; // Value from answers.needs_action.noul
boolean needsAttention = probability != null
    && Double.isFinite(probability)
    && probability >= 0.55
    && probability <= 1.0;

if (needsAttention) {
    System.out.println("Flag the message for dispatcher review");
}
```

The code checks that the value is usable before comparing it with the threshold. In LiteTMS, the category assessment supplies the other part of the rule: a vehicle problem that needs attention also qualifies for an urgent alert. The model assesses the message; the application defines the action. If the answer is missing, the normal chat workflow continues.

The threshold depends on what happens next. For an import-column suggestion, LiteTMS accepts a selected column with a probability of at least `0.60`; skipping translation requires the reader's language to be selected with at least `0.90`. A score of `0.85` can therefore support a column suggestion that a person reviews, but it is not enough to skip chat translation. Each rule reflects the consequence of that particular decision.

## FAQ

### Who developed Jev AI?

TypeSafe AI developed Jev as a System One model for structured decisions. LiteTMS integrates it into specific workflows such as driver-message assessment and place-name matching.

### What is Jev AI used for in LiteTMS?

Jev is connected to driver-message triage, same-city checks in order intake and CMR place checks, import suggestions and a same-language check before chat translation. Platform and company settings determine whether an individual feature is active in a workspace.

### Does Jev reply to drivers or approve CMR documents?

No. It can flag a driver message for attention and assess whether two place names refer to the same city. A person handles the message, and a same-city result does not validate the entire CMR document.

### What happens if Jev is uncertain or unavailable?

LiteTMS keeps the existing workflow. For example, an uncertain language check uses the normal chat translation path, while an uncertain import suggestion leaves the mapping for a person to review.