Jev is a new model from TypeSafe AI which has received a lot of attention around its launch with everyone on X and LinkedIn claiming it is truly the greatest piece of software we have ever seen. I do think there is a lot to like about Jev and that it has huge disruption potential for a lot of legacy industries. I spent the weekend brainstorming a few simple applications of the software and building a microsite to demonstrate my findings.
What is Jev?
What makes Jev unique in the current state of AI is that it is explicitly NOT a chat bot. This is unlike ChatGPT, Claude, Gemini etc where you have the typical AI input field and talk to it like a person. Jev is a far simpler system in terms of its inputs and outputs, for this weekend’s project I used simple nouls which you can think of as a yes or no question, you provide your own context along with the questions and Jev will reply with a probability of how true the statement is.
For example:
Question: “Does this animal commonly live in wooded habitats?”
Context: “The brown bear is a large bear species found across North America, Europe, and Asia.”
Result: “0.85”
or written as JSON which is how we interact with Jev:
Context
{
"animal": "Brown bear",
"description": "A large bear species found across North America, Europe, and Asia."
}
Question
{
"lives_in_the_woods": {
"type": "noul",
"instructions": "Does this animal commonly live in wooded habitats?",
"criteria": {
"true": "The animal commonly lives in forests, woodlands, or other wooded habitats.",
"false": "The animal does not commonly live in forests, woodlands, or other wooded habitats."
}
}
}
Result
{
"lives_in_the_woods": 0.85
}
Jev returns 0.85, indicating a high probability that the proposition “this animal lives in the woods” is true given the supplied context. Importantly, this isn’t a claim that 85% of brown bears live in woods - it’s Jev’s probability for the proposition we’ve asked it to evaluate.
This might seem very basic and like something a simple web search could answer let alone a fully fledged LLM like Astra or Fable which is correct but that is what makes Jev so interesting and in my view disruptive.
Sending simple yes or no questions to an LLM is really not where they excel. This is in part due to latency causing long waits for a user between questions and answers but also because LLMs will hallucinate. You could ask about a brown bear’s habitat and get a response discussing migration patterns and diet. That can be fixed with prompting or finetuning but you will find yourself fighting the system to get the answer you want. Jev can’t wander outside the output space you define. It won’t invent an explanation, field or answer you didn’t ask for. That doesn’t mean its judgement is always correct, but it makes the failure mode very different from a generative LLM. TypeSafe AI promises zero hallucinations with Jev.
So, what did I build this weekend? I brainstormed a couple of applications that interest me, can be completed very quickly and have utility in the real world. I came up with three choices each with their own story and the same theme on how Jev will impact existing companies.
Fraud Detection
The first and most obvious use-case I saw was fraud detection for ecommerce orders. Fraud detection is an area where you can only get the best signals with mountains of data or you pay someone to do it for you. I have worked with a client who had such bad fraud problems they were at risk of being removed from not only their payment processor but the Visa/Mastercard networks as a whole. If this can happen to a brand with hundreds of millions of dollars in revenue what hope does someone starting out have. Ecommerce platforms like Shopify do a lot of the heavy lifting for fraud detection and they are my recommended platform for any new ecommerce founder. I am still thinking, how could we have solved this fraud issue for our client without building and training our own classifier. Jev gives us a faster and simpler approach to solving this problem.
I set up a basic order format and several questions that Jev can use to determine if an order warrants additional review.
The high-risk fraud scenario in Jev in Practice, with editable state and Noul questions.
{
"order_id": "ORD-91847",
"customer": {
"account_age_days": 3,
"previous_orders": 0,
"lifetime_value_usd": 0,
"email_verified": true
},
"order": {
"total_usd": 1849,
"items": [
{
"name": "Premium smartphone",
"quantity": 2,
"unit_price_usd": 924.5
}
],
"item_profile": "High-resale-value electronics"
},
"payment": {
"avs": "pass",
"cvv": "pass",
"failed_attempts": 2
},
"fulfillment": {
"shipping_speed": "Next Day Air",
"address_type": "commercial freight forwarder",
"billing_shipping_distance_miles": 1180,
"freight_forwarder": true
},
"session": {
"device": "new device",
"ip_country": "US",
"billing_country": "US",
"shipping_country": "US"
},
"customer_communication": "Please ship immediately. My assistant may contact you after checkout to update the delivery address."
}
{
"suspicious_pattern": {
"type": "noul",
"instructions": "Does this order show a suspicious purchasing pattern when the customer history, order value, item profile, device, and payment attempts are considered together?",
"criteria": {
"true": "The combined purchasing signals are materially suspicious.",
"false": "The purchasing pattern is ordinary or reasonably explained."
}
},
"fulfillment_urgency": {
"type": "noul",
"instructions": "Do the selected shipping speed and customer communication indicate suspicious fulfillment urgency rather than ordinary convenience?",
"criteria": {
"true": "Urgency is unusual enough to contribute to fraud concern.",
"false": "Timing is routine or has a reasonable explanation."
}
},
"redirect_risk": {
"type": "noul",
"instructions": "Is there meaningful risk that this shipment will be redirected or its delivery address changed after payment authorization?",
"criteria": {
"true": "The state supports a meaningful address-change or redirect risk.",
"false": "There is little evidence of an address-change or redirect risk."
}
},
"additional_review": {
"type": "noul",
"instructions": "Do the contextual fraud signals in this order warrant additional manual review before fulfillment?",
"criteria": {
"true": "Pause fulfillment for a proportionate manual fraud review.",
"false": "No additional fraud review is warranted from the available context."
}
}
}
{
"model": "jev-1.13.0",
"answers": {
"suspicious_pattern": {
"type": "noul",
"noul": 0.91
},
"fulfillment_urgency": {
"type": "noul",
"noul": 0.77
},
"redirect_risk": {
"type": "noul",
"noul": 0.91
},
"additional_review": {
"type": "noul",
"noul": 0.92
}
},
"usage": {
"input_tokens": 788,
"output_tokens": 79
},
"durationMs": 297
}
Jev’s typed results for the high-risk order, including the overall manual-review decision.
In the example above we send an order to Jev along with our questions and criteria. Jev analyzes the data within the context we have provided and can only return its answers to our questions. In this case Jev returns a 0.92 probability that this particular order warrants a review from support staff.
When it comes to fraud often people in the business have a vibe on what the telltale signs are but what they lack is the technology, clean data set and budget to build a bespoke classifier for their use case. Writing these instructions and criteria took several minutes and the API integration with Jev was a breeze. This allowed me to classify orders into a low, medium or high bucket which could then be directed to support teams when needed.
Sales Qualification
The next area I tested was sales qualification. Imagine you are a general contractor with dozens of leads and you are trying to identify which potential customers are most likely to sign and complete a project. We can establish a list of questions that help us identify high-intent leads that we should actively pursue versus leads less likely to purchase. Like fraud, this is an area where all kinds of SAAS products, courses and formulas exist but with a simple call to Jev we can get an instant answer back that we can take action on. Jev’s responses are best taken as guidance from an advisor instead of a purely factual answer. There is no room for Jev to hallucinate and users won’t be stuck reading 3,000 words of generated slop grenades.
The sales qualification starts off with an “Opportunity”. This is the project and customer information that lives in a business’ CRM today.
{
"opportunity_id": "OPP-1357",
"project": "Kitchen renovation",
"quote": {
"value_usd": 38400,
"customer_stated_budget_usd": "30,000–35,000",
"age_days": 4,
"views": 4
},
"source": "Referred by a previous customer",
"site_visit": "Completed; designer walked the space with both homeowners.",
"engagement_after_quote": {
"emails": 3,
"calls": 1,
"last_contact_days_ago": 1
},
"desired_completion": "Must be complete before Thanksgiving.",
"competing_quotes": 2,
"sales_notes": "Customer called to clarify whether appliances were included. They asked how soon a start date could be reserved.",
"customer_comments": "The price is higher than we expected, but we really like the design and the referral gives us confidence."
}
Our questions cover purchase intent, price and timing sensitivity, competitive pressure and help us decide whether the sales team should proactively follow up on the lead.
{
"purchase_intent": {
"type": "noul",
"instructions": "Does the customer’s behavior show meaningful intent to purchase this renovation project in the near term?",
"criteria": {
"true": "There are concrete buying actions or commitment signals, not just general interest.",
"false": "The customer appears exploratory, inactive, or unlikely to proceed soon."
}
},
"price_sensitivity": {
"type": "noul",
"instructions": "Is price a material obstacle to this customer moving forward with the quoted project?",
"criteria": {
"true": "Budget tension is likely to delay, reduce, or prevent the purchase.",
"false": "Price is accepted or appears manageable in the broader context."
}
},
"timing_importance": {
"type": "noul",
"instructions": "Is the customer’s desired completion timing important enough to affect their vendor decision or require prompt action?",
"criteria": {
"true": "A real deadline or scheduling constraint materially affects the decision.",
"false": "Timing is flexible, distant, or unimportant."
}
},
"competitive_pressure": {
"type": "noul",
"instructions": "Is there meaningful competitive pressure on this opportunity from other contractors or alternatives?",
"criteria": {
"true": "The company risks losing an active opportunity to a competing option.",
"false": "There is little evidence of an active competitive decision."
}
},
"proactive_followup": {
"type": "noul",
"instructions": "Should the sales team prioritize a proactive, personalized follow-up on this opportunity now?",
"criteria": {
"true": "Timely outreach is likely to help advance a credible opportunity.",
"false": "Immediate proactive outreach is unlikely to be valuable."
}
}
}
{
"model": "jev-1.13.0",
"answers": {
"purchase_intent": {
"type": "noul",
"noul": 0.77
},
"price_sensitivity": {
"type": "noul",
"noul": 0.69
},
"timing_importance": {
"type": "noul",
"noul": 0.89
},
"competitive_pressure": {
"type": "noul",
"noul": 0.8
},
"proactive_followup": {
"type": "noul",
"noul": 0.88
}
},
"usage": {
"input_tokens": 799,
"output_tokens": 101
},
"durationMs": 334
}
Like our fraud detection example we get back a list of nouls with a probability for each question. In the above example Jev returns a 0.88 probability that proactively following up on this lead should be prioritized. Using data the business already had we are able to qualify leads without human intervention or expensive CRM add-ons. Running this system over an entire lead database allows a sales team to generate a prioritized list improving their chance of success. If the questions are not right or the team finds the ratings from Jev are incorrect they can simply adjust the questions and tweak the system to get a better result with no need for complex prompt engineering or finetuning.
Patent Screening
The last example I built this weekend was an interesting idea on a topic that has huge potential. Patents can be difficult to assess and have huge cost as experts and lawyers are brought in to determine whether a product infringes on an existing patent from an available list. For makers and creators it is very difficult to budget money for patent investigation when other priorities like getting something out the door is taking your focus.
I created a mock object of a patent application which covers the product and a fictional patent. Jev then reviews the data against a set of questions used to determine how closely the product appears to overlap with individual patent claim limitations.
{
"fictional_patent": {
"notice": "Fictional demonstration patent. This screening exercise is not a legal opinion or an infringement determination.",
"publication": "US 20XX/0123456 A1 (fictional)",
"title": "Adaptive Multi-Zone Irrigation Using Distributed Environmental Inputs",
"representative_claim": {
"preamble": "A controller for operating an irrigation system, comprising:",
"limitations": [
"independently controlling a plurality of irrigation zones",
"receiving soil-moisture measurements from wireless sensors associated with the zones",
"receiving weather forecast data from a remote service",
"combining the soil-moisture measurements and remote weather forecast data to calculate zone-specific watering requirements",
"automatically modifying irrigation schedules for the zones based on the calculated watering requirements"
]
}
},
"product": {
"name": "VerdantIQ Controller",
"architecture": "Cloud-connected controller operating twelve irrigation zones independently.",
"zone_control": "Each zone has its own valve, plant profile, schedule, and calculated watering requirement.",
"sensors": "Battery-powered wireless soil-moisture sensors transmit zone-specific readings every fifteen minutes.",
"weather_data": "The controller retrieves hourly precipitation, temperature, wind, and evapotranspiration forecasts from a remote weather API.",
"analysis": "A zone-level model combines current soil moisture with remote forecast data to calculate required water volume and duration.",
"schedule_changes": "The controller automatically shortens, postpones, or cancels each zone’s schedule using the calculated requirement.",
"history": "One year of sensor values, calculated requirements, and actual watering is retained.",
"mobile_override": true
}
}
{
"independent_zone_control": {
"type": "noul",
"instructions": "Does the product implement the fictional claim limitation requiring independent control of multiple irrigation zones?",
"criteria": {
"true": "The product independently controls a plurality of irrigation zones.",
"false": "The product does not independently control multiple zones."
}
},
"wireless_moisture_sensors": {
"type": "noul",
"instructions": "Does the product implement the fictional claim limitation requiring soil-moisture measurements from wireless sensors associated with irrigation zones?",
"criteria": {
"true": "Wireless zone-associated sensors provide soil-moisture measurements.",
"false": "This kind of wireless soil-moisture sensing is absent."
}
},
"remote_weather_data": {
"type": "noul",
"instructions": "Does the product implement the fictional claim limitation requiring weather forecast data from a remote service?",
"criteria": {
"true": "Remote weather forecast data is received by the product.",
"false": "Remote forecast data is not received."
}
},
"combined_sensor_analysis": {
"type": "noul",
"instructions": "Does the product combine soil-moisture measurements and remote weather forecast data to calculate zone-specific watering requirements as described in the fictional claim?",
"criteria": {
"true": "Both input types are combined in the claimed calculation.",
"false": "The inputs are missing, kept separate, or not used for that calculation."
}
},
"automatic_schedule_changes": {
"type": "noul",
"instructions": "Does the product automatically modify zone irrigation schedules based on calculated watering requirements as described in the fictional claim?",
"criteria": {
"true": "Calculated watering requirements automatically modify zone schedules.",
"false": "Schedule changes are manual or are not based on the claimed calculation."
}
},
"detailed_ip_review": {
"type": "noul",
"instructions": "Considering the product description and the fictional claim limitations only as an initial screening exercise, does this potential overlap warrant detailed review by a qualified IP professional?",
"criteria": {
"true": "The described overlap is substantial enough to warrant professional review.",
"false": "The described overlap is limited enough that this claim is a lower review priority."
}
}
}
{
"model": "jev-1.13.0",
"answers": {
"independent_zone_control": {
"type": "noul",
"noul": 0.98
},
"wireless_moisture_sensors": {
"type": "noul",
"noul": 0.98
},
"remote_weather_data": {
"type": "noul",
"noul": 0.98
},
"combined_sensor_analysis": {
"type": "noul",
"noul": 0.98
},
"automatic_schedule_changes": {
"type": "noul",
"noul": 0.98
},
"detailed_ip_review": {
"type": "noul",
"noul": 0.91
}
},
"usage": {
"input_tokens": 1064,
"output_tokens": 122
},
"durationMs": 414
}
We can see in the results that Jev returns a 0.91 probability that the patent should be reviewed further. Much like the sales and fraud examples earlier this gives a lawyer or inventor an ordering of patents to review. What might have been hundreds of hours reading patents and determining if they are relevant we can instead start with the patents showing the greatest apparent overlap. Jev isn’t claiming to have found a match but it does tell you where a match is most likely to be. I can see a use case where Jev is combined with existing classifiers all helping to filter and combine data before it reaches a human.
Is Jev worth the hype?
It feels like every model release has hundreds of voices online telling us we are on the cusp of AGI. Seeing the response from Jev’s release made me think there was going to be an Astra-level competitor. I did not find that at all but what I did find was one of the more practical, targeted use models that has proper utility for software engineers. We won’t see the same level of consumer usage compared to ChatGPT and Claude but for business applications Jev is going to be very popular.
It is fair and reasonable to think Jev is simply a classifier which is a technology that has been around for years. All of the examples I demonstrated in this post have been solved problems for years with entire industries built around them and Jev was able to build a prototype competitor in an afternoon. Jev’s value is that it enables complicated software for simple businesses.
Should you use Jev?
If you are looking at a large dataset that you need to classify, ask questions about and return simple answers then Jev is for you. The API is simple and most importantly cheap. I ran dozens of queries this weekend and am still only at fractions of a cent. I encourage people building LLM wrappers to consider how they could use Jev to replace all or part of their systems. Opus is famous for giving wordy responses to simple questions so why not try Jev and get the bare response you need to then interrogate further. I am interested to see how people combine both Jev and other generative models perhaps using Jev to compile a list of high risk orders then using Astra to identify trends, support solutions and security improvements to a codebase.
A minor note on the name
I really dislike the name TypeSafe AI since the word type safe already has such a common meaning in programming. It is an incredibly frequent word in programming content and now results will be muddied with people needing to clarify what they mean by “type safe”.
Conclusion
Overall I had a positive experience using Jev. I was pleasantly surprised Sol already had a good understanding of Jev and its purpose which made my research easier. The site I built used Vite, React and runs on a tiny node server with Express. I found the Jev playground and tutorials easy to understand, I was originally confused by the model’s description but they simplified the concepts immediately.
My examples are quick prototypes designed to test a core feature across a few areas I am familiar with. If you are using Jev for these applications or think the model could not keep up with existing classifiers let me know because I am curious what an expert’s read is.
The Jev in Practice source code is on GitHub. These prototypes are nothing special, but I hope they inspire you to try your own examples. You will need your own TypeSafe API key which you can get after joining their platform. At the time of writing there is a $5 credit on my account that I am nowhere near using fully.
The most interesting thing about Jev is not that it can classify an order, qualify a sales lead or compare a product against a patent claim. Software capable of doing all of those things has existed for years. What’s interesting is how little was needed to build them. I didn’t collect thousands of labelled examples, train a model or become an expert in machine learning. I described the data I had, defined the questions I cared about and started getting useful signals back.
That’s why I think Jev has disruptive potential. It doesn’t necessarily replace sophisticated classifiers built by companies with millions of examples and dedicated ML teams. It gives everyone else a way to start.