The gap between SQL rules and judgment calls
Every data team eventually hits the same wall: SQL and rule based logic handle clean, well defined categorization well, but fall apart on the judgment calls that require reading unstructured text and weighing ambiguous signal. Classifying a transaction as fraudulent, matching a messy job title to a standard taxonomy, or scoring customer sentiment from a support ticket are all tasks that rules can approximate but rarely nail, and that previously required either manual review or an expensive, slow call out to a general purpose large language model.
Decision models are the industry's answer to that specific gap. TypeSafe AI's Jev, which debuted September 15, belongs to a category the company calls System One models, named for the fast, intuitive mode of judgment rather than slower, deliberate reasoning. The pitch is narrow by design: handle the high volume judgment calls that sit between deterministic rules and full generative reasoning, cheaply enough to run at warehouse scale across millions of rows without the latency or cost of a full model call for every single one.
What a decision model actually returns
The defining feature of a decision model like Jev is its output shape. Given an input and a predefined set of questions, it returns a choice from a fixed list, a numeric score, or a yes or no answer, each paired with a confidence value. That output is deliberately constrained to fit directly into a database column with a known type, rather than the free text a chatbot style model produces, which would need additional parsing and validation before it could safely populate a structured field.
Moor Insights and Strategy VP and principal analyst Michael Leone describes this as returning a label and a probability that works natively in a warehouse column, which is the right framing for why platform vendors are racing to add this capability rather than leaving it to a bolt on tool. If the output already matches what a column expects, the integration cost drops close to zero, and that is precisely what makes the category attractive to data engineering teams stretched thin on pipeline work.
The evidence: cost and speed at scale
The numbers vendors are citing are striking enough to explain the interest. Astronomer reported sorting roughly 250,000 job titles in a production pipeline, and in a 4,000 title test, Jev completed the task in 66 seconds for 16 cents, against an estimated 11 to 21 dollars using Snowflake's AI_CLASSIFY function at list price for the same workload. MotherDuck ran a separate test classifying 100,000 news articles into four topics, with Jev finishing in 40 seconds for 50 cents at 89 percent accuracy, compared with an OpenAI model that scored 88 percent accuracy but took nearly 32 minutes and cost 37.58 dollars.
Southbridge AI, a startup using Jev for Ohio campaign finance record matching, reported a 99.56 percent reduction in model costs compared with a frontier model for the same task. These are vendor reported figures rather than independently audited benchmarks, and all three examples come from early adopters with an incentive to showcase strong results, but the consistency of the pattern across three unrelated use cases, large cost reductions with comparable or better accuracy, is notable enough to take seriously.
Who is building this into the stack
The adoption pattern here looks less like a single vendor's product launch and more like an entire category forming at once. Databricks is building ai_decide, currently in beta, alongside support for the open SemIf-OpenJev specification. Snowflake has Snowflake Decision in private preview, built by the same team whose head of AI platform, Pavan Pothukuchi, is publicly advising customers on when to use it. MotherDuck shipped a prompt_jev() function directly into its SQL interface, and Astronomer is adding Airflow provider support so decision models can run as a native step in existing data pipelines.
That breadth of simultaneous investment, across data warehouses, lakehouses, orchestration tools, and specialized AI vendors, is the strongest signal that decision models are becoming standard infrastructure rather than a passing trend. When four vendors with different business models and different customer bases all conclude the same primitive belongs in their platform within the same few months, the underlying demand is almost certainly real rather than manufactured by any single company's marketing push.
The skepticism analysts are raising
Pothukuchi himself offers the most useful caution from inside a vendor building this technology: use plain SQL whenever it can settle the question, and reserve decision models for the genuinely high volume judgment calls where rules fall short. That is a meaningful admission from someone selling a decision model product, and it suggests the category is at risk of being oversold into use cases where a simpler, cheaper, more auditable rule would do the job just as well.
HyperFRAME Research practice leader Stephanie Walter adds that any comparison should include traditional machine learning and rules based approaches as baselines, not just a head to head against a general purpose large language model, and that teams need to weigh accuracy, ongoing maintenance burden, and total cost together rather than optimizing for any single metric in isolation. Leone's warning about testing vendor confidence scores against your own data, rather than trusting a vendor's own validation set, is the specific discipline most teams will skip under deadline pressure.
What data leaders should pilot first
The sensible entry point is a high volume, low individual stakes classification task you are currently either skipping entirely or paying for with an expensive general purpose model call. Job title normalization, support ticket routing, and content tagging are the kinds of tasks the early case studies cluster around, and they share a useful property: a wrong answer is annoying but rarely catastrophic, which makes them a safe place to validate a vendor's accuracy claims against your own data before trusting a decision model with anything higher stakes.
Resist the urge to replace every rule based system at once. The strongest argument for decision models is cost and speed at the specific point where SQL rules genuinely run out of nuance, not a wholesale replacement of deterministic logic that already works reliably and cheaply. Pilot narrow, measure against your own baseline rather than a vendor's benchmark, and expand only once the economics and accuracy both hold up under your own data's particular mess.
