{"slug": "what-is-jev-a-simple-primer-on-ai-that-makes-decisions", "title": "What is Jev? A Simple Primer on AI That Makes Decisions", "summary": "Former OpenAI researcher Diogo Almeida has released Jev, an AI model built to return small, structured judgments with attached probabilities rather than open-ended generated text, according to TypeSafe, which calls Jev its first \"System One Model.\" The TypeSafe API exposes three question shapes — Yes/No, Choice, and Score — so software can ask narrow questions such as whether a £127 meal expense needs manager approval and receive answers like YES: 0.97, leaving the code to decide what the judgment means. The approach targets fuzzy decisions that are hard to express as hard-coded rules, such as fraud detection, ticket routing, and customer churn risk.", "body_md": "# What is Jev? A Simple Primer on AI That Makes Decisions\n\nMost of the AI we encounter today is designed to generate things: text, images, code, answers. **Jev****, a new model from former OpenAI researcher Diogo Almeida, is built around a different idea.**\n\nInstead of asking AI to produce an open-ended response, you ask it to make a small, well-defined judgment: *Is this suspicious? Which category does this belong to? How risky is this?*\n\n*It returns a structured answer with an attached probability.*\n\nThat sounds simple, but it points to a different way of putting AI inside software.\n\nThis is a short, nontechnical primer on what Jev is, how it works, and why the idea is interesting.\n\n## The basic idea\n\nThe simplest way to understand **Jev** is this:\n\n**Jev is an AI model designed to make small, fast, structured decisions inside software.**\n\nInstead of asking it to produce an open-ended response, you give it **the current state of a situation and a specific question to answer**.\n\nJev then returns **a structured decision with a probability attached**.\n\nFor example, imagine a software system looking at an expense claim.\n\nIt already knows a few facts:\n\n- the expense is £127\n- the category is a meal\n- manager approval has not yet been given\n\nThe system can then ask Jev a narrow question:\n\nDoes this expense need manager approval?\n\nJev might answer:\n\n- YES: 0.97\n- NO: 0.03\n\nYour software can then decide what to do:\n\n```\nif P(YES) > 0.90:\n    send_to_manager()\n```\n\nThe important point is that **Jev makes the judgment, but your software still decides what that judgment means**.\n\nThat is the main idea.\n\nTypeSafe calls Jev its first **System One Model**, designed for fast, bounded judgments that software can act on directly.\n\n## Think of Jev as a smart decision function\n\nConceptually imagine a normal function:\n\n```\nshould_escalate(ticket)\n```\n\nOrdinary code might contain rules like:\n\n```\nif ticket.value > 10000:\n    return true\n```\n\nBut reality is rarely that clear.\n\nYou might instead need to answer questions like:\n\n```\nDoes this customer actually sound upset?\n\nDoes this transaction look suspicious?\n\nWhich team is best placed to handle this?\n\nHow serious is this incident?\n```\n\nThose are fuzzy judgments.\n\nThere usually isn't a neat value sitting in a database that says:\n\n```\ncustomer_is_actually_upset = true\n```\n\nJev wraps that kind of fuzzy judgment in something that feels more like a software function.\n\n**State goes in. A typed answer with a probability comes out.**\n\nIn other words, it lets software ask questions that are difficult to express as simple hard-coded rules.\n\n## Jev basically gives you three kinds of primitives\n\nThe current TypeSafe API exposes three basic question shapes:\n\n- **Yes / No**\n- **Choice**\n- **Score**\n\nIn plain English, that means Jev can answer:\n\n- Is something true?\n- Which option fits best?\n- How strongly does something apply?\n\nYou can think of them as:\n\n```\nNoul    → Is X true?\n\nChoice  → Which X?\n\nScore   → How much X?\n```\n\nThe interesting part is that you can combine these small judgments to create larger workflows.\n\nFor example, a system might first ask:\n\nDoes this request look fraudulent?\n\nIf not, it might then ask:\n\nWhat kind of request is this?\n\nAnd finally:\n\nHow urgent is it?\n\nJev provides the fuzzy judgments.\n\nYour code defines the workflow.\n\nA useful way to think about the division of labour is:\n\n**Jev makes the judgment. Your code decides what to do with it.**\n\n## A useful example: customer support\n\nImagine a customer says:\n\n\"I cancelled two weeks ago and you've charged me again. I'm really annoyed and I'm thinking of leaving.\"\n\nA customer support system could make several small judgments about that message.\n\nIt might ask:\n\n- Is fraud involved?\n- What is the main issue?\n- How likely is this customer to leave?\n\nEach of those is a separate, narrow judgment.\n\nTogether, they can guide what happens next.\n\nPerhaps Jev decides:\n\n- fraud is unlikely\n- the main issue is billing\n- churn risk is high\n\nThe system can then route the message to a human retention team.\n\nWhat's interesting is that you can see precisely where intelligence exists in the workflow.\n\nYou're not saying:\n\n\"AI, deal with this customer.\"\n\nYou're saying:\n\nI know how this business process works.\n\nI just need intelligence at these specific decision points.\n\nThat is a very different engineering philosophy.\n\n## Turning fuzzy judgments into software decisions\n\nTraditional software is great when the rule is precise:\n\n```\nage >= 18\nbalance < 0\ncountry == \"UK\"\n```\n\nThese are easy because the facts already exist and the rule is explicit.\n\nBut some rules look more like:\n\n```\nDoes this seem suspicious?\n\nIs this document actually relevant?\n\nDoes this response adequately answer the question?\n\nIs this request unusually risky?\n```\n\nYou can't easily write:\n\n```\nif suspiciousness == true:\n```\n\nbecause \"suspiciousness\" isn't sitting in your database.\n\nJev effectively lets you create something resembling:\n\n```\nsuspiciousness = jev(state)\n```\n\nand get something like:\n\n```\n0.93\n```\n\nYour software can then turn that judgment into policy:\n\n```\nif suspiciousness > 0.90:\n    block_transaction()\n\nelif suspiciousness > 0.60:\n    send_for_review()\n\nelse:\n    continue()\n```\n\nAnother way to think about it is that Jev turns a messy real-world judgment into something ordinary software can act on.\n\nIt takes an ambiguous situation, produces a probability, and lets code use thresholds to decide whether to proceed, review, or stop.\n\nThat is probably the most useful mental model.\n\n## Jev is deliberately bounded\n\nOne interesting thing about Jev is that you define the possible answers upfront.\n\nImagine you're building a ticket-routing system.\n\nYou might decide that every ticket must go to one of four places:\n\n- Billing\n- Technical\n- Sales\n- Fraud\n\nJev's job is to judge **which of those options fits best**.\n\nIt isn't allowed to suddenly decide:\n\n\"Actually, create a new department.\"\n\nThe space of possible answers already exists.\n\nThat constraint is intentional.\n\nTypeSafe describes Jev outputs as **typed**, meaning the surrounding software knows the structure and possible forms of the answer in advance.\n\nSo rather than giving the model complete freedom over what happens next, the software defines the boundaries first.\n\n**Software defines the world. Jev makes judgments inside that world.**\n\nThis makes the model less open-ended, but for many software systems that may actually be a useful property.\n\n## Why probabilities matter\n\nSuppose Jev answers:\n\n```\nFraud?\n\nYES: 0.51\nNO:  0.49\n```\n\nThat tells you something important.\n\nThe system isn't very confident.\n\nSo perhaps your software says:\n\n```\nconfidence < 0.70\n```\n\nmeans:\n\n```\nHUMAN REVIEW\n```\n\nBut if Jev returns:\n\n```\nYES: 0.995\nNO:  0.005\n```\n\nyou might be comfortable allowing an automatic action.\n\nThe confidence score therefore isn't just extra information.\n\nIt can become part of the control logic.\n\nFor example:\n\n- low confidence → human review\n- medium confidence → another check\n- high confidence → automatic action\n\nThat creates a useful separation between **judgment** and **policy**.\n\nJev produces the probability.\n\nYour software decides what level of confidence is good enough.\n\n## The bigger architectural idea\n\nMost software is built around a fairly simple idea:\n\n**input goes in, code applies rules, output comes out.**\n\nThat works extremely well when the world is clean and predictable but ordinary code struggles when the rule depends on interpretation.\n\n- Was the customer genuinely upset?\n- Does this document seem relevant?\n- Does this transaction look suspicious?\n\nJev introduces another building block.\n\nInstead of forcing everything into deterministic rules, software can combine:\n\n- **deterministic logic** for exact rules\n- **judgment logic** for fuzzy decisions\n\nThat's the interesting idea.\n\nIt's not:\n\n\"replace the application with AI.\"\n\nbut:\n\n**put machine judgment exactly where deterministic logic isn't enough.**\n\n## What might this look like in a real workflow?\n\nImagine an invoice-processing system. Some steps are straightforward. The system can calculate totals using normal code. It can check whether an invoice has already been paid using a database lookup.\n\nBut other steps involve judgment.\n\n- Is this a valid invoice?\n- Do the fraud indicators look suspicious?\n- Does the vendor information seem correct?\n\nA workflow might therefore alternate between ordinary code and Jev judgments.\n\nNotice what's happening.\n\nThe intelligence isn't one enormous black box instead it's scattered through the workflow:\n\n```\nCODE\nJEV\nCODE\nJEV\nCODE\n```\n\nEach component does the thing it is good at. The application still owns the overall process. Jev is inserted where fuzzy judgment is needed.\n\nTypeSafe's published workflow evaluations use this general philosophy: break a business process into programmatic rules and narrow intelligent judgments, then compose them into a larger workflow.\n\n## A simple mental model to remember\n\nStrip everything else away, and the contrast is fairly simple.\n\nOrdinary code works well when you already have:\n\n- clear facts\n- clear rules\n- a deterministic answer\n\nJev becomes useful when you instead have:\n\n- messy facts\n- an ambiguous judgment\n- a probability-backed answer\n\nIn practice, the two work best together.\n\nSoftware handles the overall workflow and Jev is called at the specific points where judgment is needed.\n\nOr in one sentence:\n\n**Jev turns fuzzy judgments into typed, probability-backed values that ordinary software can use.**\n\nThat is probably the cleanest definition.\n\nNo spam, no sharing to third party. Only you and me.", "url": "https://wpnews.pro/news/what-is-jev-a-simple-primer-on-ai-that-makes-decisions", "canonical_source": "https://www.anup.io/what-is-jev/", "published_at": "2026-10-01 08:07:46+00:00", "updated_at": "2026-10-01 08:16:52.655157+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-products", "ai-tools", "ai-agents"], "entities": ["Jev", "Diogo Almeida", "OpenAI", "TypeSafe", "System One Model"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/what-is-jev-a-simple-primer-on-ai-that-makes-decisions", "markdown": "https://wpnews.pro/news/what-is-jev-a-simple-primer-on-ai-that-makes-decisions.md", "text": "https://wpnews.pro/news/what-is-jev-a-simple-primer-on-ai-that-makes-decisions.txt", "jsonld": "https://wpnews.pro/news/what-is-jev-a-simple-primer-on-ai-that-makes-decisions.jsonld"}}