Jev for input validation

TypeSafe's Jev classifier can flag likely fake email addresses and phone numbers in signup forms without training or fine-tuning, returning a confidence score for each listed choice instead of generated text. In a demo, Jev rejected the 867-5309 phone number from the Tommy Tutone song and "555" numbers and "example.com" emails without being explicitly programmed to do so, with scores under 0.5 triggering an error asking for a real number or address. The author recommends keeping format checks like regex and zod for empty fields and missing @ symbols, and using Jev only for judging whether contact details are likely real.

Ever since the Jev announcement https://typesafe.ai/blog/introducing-system-one-models-and-jev , I've been seeing tons of use-cases and how it can be applied to problems that didn't work well with traditional LLMs. There are demos out there from playing Tetris https://x.com/tdinh me/status/2101094189694099738?s=20 to driving cars https://x.com/jpschroeder/status/2100347770867458384?s=20 . While these demos are really cool, I'm more interested in exploring how the various ways it can actually be used in real production software. Jev's core use case is as a classifier. You give it some state and a question whose answers you have already listed. It returns a score for those answers instead of generating text, so you can drop it into normal validation code without a training step. The biggest shift here is that, instead of getting raw text output like you get from traditional LLMs, you get a "confidence score" for each output. This means you get a smart, general classifier without having to do any training or fine-tuning. Here is a simple example of how you can use Jev to classify the sentiment of a review: // Input { "state": { "review": "The product works well, but shipping was painfully slow." }, "questions": { "sentiment": { "type": "choice", "choices": "positive", "neutral", "negative" } } } // Output { "sentiment": { "choice": "neutral", "probabilities": { "positive": 0.28, "neutral": 0.61, "negative": 0.11 } } } Input Validation I spend a massive amount of time trying to figure out how users can input information that is: - Invalid/malformed - Missing - Intentionally misleading This usually involves lots of data validation logic i.e. regexes, zod, etc that is still easy to get wrong. But what if we just use Jev? For example: // Input { "state": { "email address": "scott@example.com" }, "questions": { "type": "noul", "instructions": "Is the email address real and valid?", "criteria": { "true": "The email address is likely a real and valid email address.", "false": "The email address is likely faked or invalid." } } } I had to spell out that providers like gmail.com should count as valid. Otherwise a lot of normal addresses came back as fake. Changing the criteria is how you tell Jev what to accept. Validating email addresses is hard. Yes, we have regex to help with this, but it's not simple: ^ a-zA-Z0-9. %+- +@ a-zA-Z0-9.- +\. a-zA-Z {2,}$ Format checks are still important. We still need to check for empty fields, a missing @, a phone number that's too short, etc: zod or a regex should catch those. The harder part is determining if the email or phone number is likely real or not. Some products get spammed with lots of fake info to create bot accounts, get freebies, or other things. Having a way to not only validate an email or phone number, but also help determine if it's likely real or not would be a huge help. I made a demo showing how this could work. Given a signup form, we can use Jev to validate the phone number and email address and determine if they're likely real or not. Interestingly, it even denies the famous 867-5309 phone number, from the song "867-5309/Jenny" by Tommy Tutone, without being told to It also denies other fake numbers/emails "555" numbers, "example.com" emails . These are not explicitly programmed in - the classifier just "knows" that these likely aren't real numbers and emails. In the demo, both checks run on blur. Anything under 0.5 shows an error and asks for a real number or address. Another option would be to block the obvious fakes and only warn when the score was in the middle. I would imagine you could also integrate this directly into other validation libraries, like zod: js import { z } from 'zod'; import { TypeSafeClient, noul } from '@typesafe-ai/sdk'; const jev = new TypeSafeClient ; const schema = z.object { phone: z.string .refine async phone = { const { answers } = await jev.systemOne { state: phone, questions: { valid: noul 'Does this look like a real, valid phone number?' , }, } ; return answers.valid.noul = 0.6; }, { message: 'Please enter a valid phone number', } } ; Being low latency and cheap, this now makes sense to run on a critical path like this. Assuming you're not operating at scale which most of us aren't , this could be a great way to handle a classic problem that's nearly impossible to solve with traditional programming logic.