Jev for Customer Success: Churn, Health Scores and Expansion (2026)

TypeSafe released Jev on 15 September 2026. Within a week, community use-case lists were filling with agent routing, RAG filtering, guardrails, reranking, trading and games. Customer success was almost entirely absent, and on the most-referenced list it still is.

That gap is strange, because the model's shape matches the problem's shape almost exactly. Jev takes unstructured account context, answers narrow typed questions about it, and returns numbers your code branches on. That is the judgment layer inside a health score.

It is also a trap, and the trap has a name.

Much of your health score is arithmetic Jev is documented to be bad at

TypeSafe publishes a page called model jaggedness, last reviewed 17 September 2026, listing nine things jev-1.13 does poorly. Three are fatal for customer success, and the wording is theirs.

On arithmetic:

"Jev is not a calculator."

On dates:

"reads dates as text, not as ordered quantities"

On scoring, a warning most people miss: do not interpolate between score levels to recover an exact figure, because the levels are weak in numerical calibration.

Now look at what an account record is actually made of.

Six of these ten belong in SQL. The exact ratio depends on your score, and the point is not the fraction: it is that the deterministic rows are exact in code, cheap in code and auditable in code. Sending them to any model converts a fact into an estimate and bills you for it.

The independent testing complicates this slightly in Jev's favour. A pre-registered study run on 20 September measured number comparison at 99.6% accuracy across 13 designs and negation at 100%, and its author's closing recommendation was to test vendor warnings rather than take them on faith. The warnings may be conservative. They are still the right default, because a score that is wrong about a renewal date is wrong in a way nobody catches until the renewal.

That split is not a limitation to work around. It is the architecture.

FACT → JUDGMENT → POLICY → ACTION

Four layers. Each owns something the others must not touch.

Read it as a set of prohibitions and it gets sharper:

• Code must not guess. If it can be computed, compute it.
• Jev must not calculate. It reads meaning, not quantities.
• Jev must not set policy. It reports a judgment. What that judgment is worth is your decision, held in your code, where you can change it without retraining anything.
• Neither writes the email. Generation is a generative model's job.

Most AI-in-CS failures are one layer doing another layer's work. A giant prompt asking a model to weigh everything and return a health score collapses all four into one, which is why nobody can debug the answer.

Jev, LLMs, rules and classifiers: which one for which job

The framework only pays off if you can allocate a task to a layer in a few seconds. This is the table I would keep next to anyone designing a customer success workflow.

Two boundaries are worth stating outright, because they are where teams lose money.

Jev is not a cheaper LLM. It does not write, summarise, explain or generate. If a human needs a sentence at the end of your workflow, a generative model produces it. Jev produces the decision that determines whether the workflow runs at all.

Jev is not automatically better than a classifier. For a stable taxonomy with thousands of labelled examples, a trained classifier is usually cheaper, faster and more predictable. Jev earns its place where categories move, labels are scarce, and you want to change a definition by editing a sentence rather than retraining a model.

The fastest way to ruin a promising decision model is to make it responsible for decisions that were never judgments.

What Jev returns

Three question types. All three mix in a single request, and every question is evaluated independently and in parallel against the same state, so asking twelve questions about an account costs barely more wall-clock time than asking one.

Choice accepts up to 255 options. Score takes two to ten ordered levels. Noul returns no confidence field, because the probability already is the distribution.

No prose comes back. Ever. That is the point.

The four customer success jobs, run through the architecture

Each job splits the same way. The pattern below is the entire method, applied four times.

Churn risk

Do not ask "will this customer churn?" That question silently blends usage, sponsorship, value, support, commercial pressure, timing and competition. When it is wrong you cannot tell which part failed.

Store each judgment separately. That is what makes the score debuggable, testable per signal, and changeable one question at a time.

Health score

The same discipline, one level up. Do not ask Jev for the score. Ask for the dimensions and keep the weighting in your code, where you can see it and argue with it.

TypeSafe calls this composite scoring and recommends exactly this: score dimensions separately, combine with weights controlled in code, preserve visibility into each one. Constructing and validating the score itself is a separate job, covered in how to build a customer health score that predicts churn.

Expansion

Cleaner than churn, because expansion signals are mostly about whether a customer is pressing against what they already bought.

Compute the 34% first, then ask whether it means something. The broader question of which signals constitute expansion, and how to qualify them, belongs to the expansion pipeline model.

Renewal risk

The left column is non-negotiable. TypeSafe's own documentation tells developers to keep date comparison and arithmetic in code. Renewal dates and forecast mechanics belong to renewal forecasting, not to a model.

A worked request

One account, one call. Facts are pre-computed and passed in as settled values, not as raw events for the model to work out.

{
"model": "jev-1.13.0",
"state": {
"usage_change_30d": "-38% (computed)",
"renewal_days": "74 (computed)",
"seat_utilization": "91% (computed)",
"champion_status": "Primary champion left the company 12 days ago",
"support_summary": "Three unresolved integration tickets. Latest says the issue is blocking rollout.",
"customer_message": "If we cannot get this stable before next month, we need to revisit whether we can keep this running."
},
"questions": {
"adoption_deterioration": {
"type": "noul",
"instructions": "Is there meaningful evidence that product adoption is deteriorating?"
},
"cancellation_intent": {
"type": "noul",
"instructions": "Does the customer's language communicate intent to cancel or seriously reconsider continuing?"
},
"primary_risk": {
"type": "choice",
"instructions": "Which risk dimension is most strongly supported by the evidence?",
"criteria": {
"adoption": "Strongest evidence is weakening usage",
"stakeholder": "Strongest evidence is loss of sponsorship",
"support": "Strongest evidence is unresolved implementation friction",
"commercial": "Strongest evidence is downgrade or budget pressure",
"insufficient_evidence": "The evidence does not support a material risk call"
}
}
}
}

Jev did not calculate 74 days. It did not decide what to do. It read three judgments out of text, and your policy layer decides that support risk plus cancellation intent plus a renewal inside 90 days equals an executive review.

Note the fifth Choice option. It is there deliberately, and the next section explains why.

Can Jev find churn risk inside support tickets?

This is the easiest case to grasp, because the source material is already language. No feature engineering stands between the raw text and the judgment.

Take this example support message:

"This is the second month we have been charged twice. Our team is losing patience. If we cannot get this fixed this week we are going to reconsider the renewal."

A support workflow classifies that once, as billing, and routes it. But the same fifty words carry at least five independent signals, and one request can read all of them in parallel:

Keep frustration and cancellation intent apart. They correlate loosely and mean completely different things. A customer can be furious about a bug and entirely committed to the product; another can write one calm sentence saying procurement has already chosen a competitor. A single sentiment label collapses both into the same number and loses the only distinction that matters commercially.

This is where support data stops being a queue and starts being a signal source. The same reading applied to churn signals sitting in call notes is the other half of the same idea.

What the benchmarks actually found

An independent researcher ran Jev and Claude Haiku 4.5 over 2,000 emails from a phishing dataset, one call per email, and published the code and raw data. It is the most useful thing published about the model so far, and the headline is not the interesting part.

The first two rows are measured on all 2,000 emails; the bottom three on a held-out 1,000 after the signals and weights were fitted on the other half. That split is the honest way to report a fitted result, and it is the reason the decomposed numbers are trustworthy rather than inflated. It also means the rows are not a single before-and-after.

Read the ladder top to bottom. Three things fall out of it.

The broad question performed poorly; decomposition plus a learned combiner performed far better. Jev's single verdict scored 62.6% across all 2,000 emails. In a separate train/test experiment, five atomic Jev signals combined by a logistic regression fitted on 1,000 labelled emails reached 95.0% on the held-out 1,000. Those are different evaluation setups, so the honest conclusion is not that Jev went from 62.6% to 95%. It is that the decomposed system performed far better than the broad-verdict design.

Be precise about what that buys you, because most summaries are not. The gain belongs to decomposition plus labelled data plus a regression you maintain, not to Jev alone. The model supplied five better inputs. The labels and the weighting did the rest, and both are yours to build and keep current.

The decomposition is the win, not the model. Haiku asked the same five questions reached 93.2%, with a higher AUROC than Jev's, 0.991 against 0.982. The gap in Jev's favour is not statistically significant, at p = 0.063. Decomposing worked on both engines.

A dumb rule beat the clever one. A list of URL shorteners and free hosting domains plus a sender-versus-link check scored 91.8%, beating Jev's best single AI signal at 89.4%. Before you reach for a model, check whether a rule already answers the question.

What Jev kept was price: roughly 27 times cheaper and 5 times faster than the LLM for signals of comparable quality.

The caveats are the researcher's own. Email bodies were synthetic. Ground truth came from URL reputation feeds, not a human reading each message. Each system got one prompt. And the dataset was partly separable by regex to begin with, which caps how far any of it generalises.

Do not carry the 95% to customer success. That number belongs to phishing. Carry the architecture lesson: ask an AI model for the observable judgments that produce an outcome, never for the outcome itself.

Three ways teams will get this wrong

1. Reading a Noul as an outcome probability

You ask "does this message express cancellation intent?" and get back 0.90.

That is a 0.90 probability that the message expresses cancellation intent. It is not a 90% chance the account churns. Those are different events, and conflating them is the fastest way to build a system nobody trusts.

The same applies to Choice. A primary_risk = support with confidence = 0.90 means the model has a clear preference for support over the other categories you offered. It says nothing about what happens at renewal. Mapping any signal to an outcome requires validating that mapping against your own closed accounts.

2. Trusting a confidence number you have not calibrated

TypeSafe is upfront in their own docs:

"Calibration is measured across groups of predictions; it does not guarantee that an individual answer is correct."

Three findings from independent testing sharpen this, two of them from the same out-of-distribution study:

• Thresholds do not transfer between question types. An independent out-of-distribution calibration study ran 900 rule-generated support tickets on 19 September 2026, on a task the model cannot have been trained on. Yes/no answers came back underconfident, while Choice and Score came back overconfident, needing corrections in opposite directions on the same inputs. TypeSafe's own documentation states the same thing plainly: there is no guarantee that thresholds transfer between question types. A 0.8 cutoff tuned on one question is not a 0.8 cutoff on the next, and a single confidence threshold across a mixed request is therefore wrong for at least one of its questions.
• Confidence is flat until it is not. The pre-registered study found accuracy essentially unchanged from 0.50 to 0.95, then jumping at 0.99. Its recommendation was to gate at 0.99 or not gate at all. The three-band high, medium and low design the vendor documentation teaches did not match the measured behaviour.
• Confidently wrong is not hypothetical. In the same study, one question asked for a priority level set by an organisational rule that was nowhere in the ticket text. No model can recover it. Jev scored 44.7% against a 25% chance baseline, which is roughly common sense and nothing more, while the level it picked carried an average stated probability of 0.74. Overall calibration error on that unseen set was 0.107, about 4.4 times the 0.024 noise floor. The model did not signal that the answer was unknowable. This is the exact failure shape of a health score asked to judge something your data never captured.

An uncalibrated confidence field is decoration. It becomes a safety mechanism only after you have plotted it against outcomes on your own accounts.

3. Forgetting that it always answers

The pre-registered study fed the model 30 deliberately out-of-scope messages. It declined zero of them, answering all 30 with high confidence.

There is no built-in "I do not know." Given a forced set of options, it picks the least wrong one.

Every CS leader already knows this failure by another name: the green account that churned. The score returned a number because the score always returns a number, and nobody could see it had nothing to go on. Moving from rules to a model reproduces that failure faster and cheaper unless you design against it.

Two cheap mitigations:

Give every Choice an explicit escape option and treat it in code as a distinct state, not a low score. An account with no signal is not a healthy account, and a score built without usage data has to say so out loud.

Get the criteria descriptions right or leave them out. The same study found wrong option descriptions dropped accuracy to 16.7%, below the 25% you would get guessing at random, while missing descriptions cost only 0.8 points. A misleading rubric is far worse than no rubric. Option ordering also moved results by up to 13 points on ambiguous questions.

What it costs to run across a whole book

Only input tokens are billed. Output is free. List price is $0.042 per million input tokens.

The benchmark repository published its actual invoice as a check: 3.66 million input tokens billed at $0.15, which matches the published rate to the cent. So the arithmetic below is anchored to a real bill, not a pricing page.

Assume roughly 4,000 total input tokens per account, covering the state, the computed facts and a dozen short questions with their criteria. TypeSafe bills all input, not just the state.

Twelve judgments on a 4,000-token account work out to roughly 71,000 individual judgments per dollar.

The saving is not the point. The cadence is. At this inference price, model cost is unlikely to be what limits how often you score an account. Data freshness, connector sync intervals and workflow design become the binding constraints instead, which is a very different set of problems to solve than a budget.

Two limits to design around. The per-request budget is 64k tokens, with 32k for the state plus the longest single question, so a large account record needs trimming. And accuracy falls as state fills with irrelevant detail, so trimming is correct anyway. Retrieve what matters, then ask.

One efficiency worth knowing, and this one is TypeSafe's own measurement rather than an independent one: their published cookbook batching 13 questions into a single call rather than sending them separately reports 12.2 times cheaper and 10.0 times faster with no change in the answers. It describes how the API bills rather than how well the model performs, which is why it survives the sourcing rule above. Ask everything at once.

How to test it on your own accounts

Not five convenient accounts in a playground. A shadow evaluation, which costs almost nothing and answers the only question that matters.

Start from known outcomes. Pull 200 to 500 accounts that renewed, churned, contracted or expanded.

Freeze the evidence before the outcome. Reconstruct the account as it stood at 90 and 30 days out. This is the step most teams get wrong, and leaking the result into the state invalidates everything after it.

Compute the facts first. Usage delta, seat utilisation, ticket count, payment status, days to renewal, ARR.

Ask atomic questions, and keep the raw probabilities. Do not discard them after converting to red, amber and green. You need them for calibration.

Act on nothing. Run it in parallel with your existing process.

Measure the system, not the demo. Precision, recall, false positives, false negatives, AUROC, calibration, coverage at each threshold, cost, p50 and p95 latency, and performance broken out by segment and by data completeness.

Compare against boring baselines. Your current health score, a simple rule set, a logistic regression. The phishing benchmark is the reminder: a two-line regex reached 91.8% there. Sometimes the boring system already wins.

Then, and only then, set thresholds. Missing a real churn risk and flagging a healthy account do not cost the same, so the threshold is a business decision informed by measured behaviour, not a number copied from documentation. The mechanics of testing scoring logic against real outcomes are the same whether the score comes from rules or a model, and they are in how to backtest a customer health score against real churn.

Scale is not the obstacle. The entire 5,721-call pre-registered study cost $0.176.

One production rule: pin the model version. jev-latest currently resolves to jev-1.13.0, and aliases move. Thresholds calibrated against one version are not valid against the next until you rerun the evaluation.

If you do not want to build this layer yourself

Everything above describes infrastructure. Calling Jev is one afternoon. Running customer success intelligence in production is not, and the gap between them is where most of these projects stall.

Somebody still has to connect the CRM, product analytics, billing and support, resolve accounts across all four, compute the deterministic facts, design every judgment, assemble a historical set to calibrate against, maintain the weights, rank the results, push them into the tools CSMs actually open, and re-validate the thresholds every time the model version moves.

Jev can make one layer of that cheaper. It does not remove the other layers.

That is the honest build-versus-buy line, and it has nothing to do with which model is best. GainTrace is built around the same separation this article argues for: deterministic facts are computed rather than estimated, and the individual signals stay visible alongside the combined health score, so a CSM can see what moved it and argue with the evidence rather than trusting an unexplained number. GainTrace is free on your first 25 companies.

What Jev could change about customer success software

The first wave of AI in customer success mostly added language. Summaries, meeting notes, QBR drafts, suggested replies. Useful, and almost entirely cosmetic, because the operating system underneath did not change. The same rules produced the same queue, and a model wrote a nicer sentence about it.

What a cheap, bounded, calibrated judgment changes is what software can decide before a human opens the account. Not "here is a summary of this customer," but: is the adoption decline material given their history, does this support thread carry commercial risk, has sponsorship actually weakened, is there a second use case emerging, does any of this justify escalating today. Those are not paragraphs. They are bounded answers with probabilities attached, and under the 4,000-token account example above, at roughly seventy thousand individual judgments per dollar, the constraint on asking them stops being cost.

That is a bigger change than another copilot, and it is worth being precise about what it is not. It is not AI running customer success. The architecture that holds up is narrower and duller than that:

Code owns the facts. Models supply bounded judgment. Policy owns the consequences. Humans own the relationship.

Whether Jev specifically becomes the standard for the second layer is genuinely unknown. It is one week old, its strongest published claims are its own, and the independent evidence so far says the decomposition matters more than the engine. But the separation it was designed around is the right one, and it survives regardless of which model ends up occupying that slot.