hunch
(noun, hʌntʃ)An intuitive guess or feeling. If you have a hunch about something, you are sure that it is correct or true, even though you do not have any proof.
The first piece in this series posed an obvious question — does Jev replace anything Pega already does — and pointed at case management and workflow as the place a fast, typed, probabilistic judgement call is most likely to actually earn its keep. Pega has already made the argument, in its own recent position on predictable AI (Why Predictable AI Matters - Governing Decisions, Not Models | Pega), that intelligence belongs in tiers: rules for the deterministic and near-free, statistical models for what can be learned from an organisation’s own outcomes, and progressively more expensive forms of reasoning reserved for what genuinely needs them. A Pega case type already runs two of those tiers side by side. This post is really about where Jev sits as a third.
Reminder: What is Jev?
Jev is TypeSafe AI’s flagship model, and the first of what the company calls a System One model — built for fast, structured judgement rather than generated prose. Where a chat model reasons its way to an answer in visible text, Jev takes a block of state (a case record, an email, a transcript) together with a set of typed questions, and returns typed answers directly, in a single pass: no essay to parse, just values and probabilities that code can branch on, sort by, and route with, with no measurable slowdown as more questions are added to the same call.
There are three question types, and they can be mixed freely in one request. Choice picks the best-fitting option from a defined list and returns a probability for each. Score rates the state against ordered levels and returns a distribution alongside the headline number. Noul asks a yes/no question and returns a single probability that the statement is true. TypeSafe’s own guidance is to keep each question narrow — the kind of gut-check a knowledgeable person could make in a few seconds — and to decompose anything more complex into several atomic questions, combined afterwards in code rather than left for the model to weigh internally.
The first of Pega’s intelligence tiers is business rules: deterministic, explicit, and entirely predictable, running at close to zero marginal cost — eligibility checks, approval thresholds, skill-based routing that sends an assignment to whichever available operator has the right skill profile. Rules do not learn and do not guess; they apply the same logic to the thousandth case as to the first, which is exactly why regulators like them and why they remain the backbone of anything with a compliance obligation attached.
The second tier is Process AI’s own predictions, which behave quite differently: a model that forecasts a SLA breach, and which gets more accurate as more cases pass through it. This is Pega’s statistical AI tier — it learns from an organisation’s own outcomes rather than a generic training set.
Pega’s own material on this is clear about the trade-off — as the model accumulates evidence from real outcomes, its predictive power increases. That is a considerable strength, but it carries a cold-start problem: a brand-new case type, or a rare case category, has no history to learn from yet, and a prediction is only as good as the volume of evidence from closed cases behind it.
Jev’s decisions are neither of these tiers, and have a big difference that needs reflecting on: Process AI’s predictions learn from what actually happened in your cases; Jev’s judgement is a pre-formed hunch, fixed at the point you call it, drawn from a generalist model that has never seen a single one of your cases and never will unless you build that in yourself. That is a real limitation. It is also, for exactly the situations where Process AI is weakest, a genuine advantage — a new case type, an unfamiliar channel, a category too rare ever to accumulate enough evidence, all of which currently mean waiting, or falling back on simplistic rules.
It is worth thinking about which tier Jev actually belongs to, because it does not slot cleanly into any of the ones already on the table. It is not classic rules. It is not statistical AI in Pega’s sense, because it has not learned from this organisation’s own outcomes the way Process AI has. And it is not quite the local, self-hosted model tier either — the one built for exactly this kind of bounded task, intent classification, extraction, routing, at near-zero marginal cost and with data that never leaves the building. Jev is priced and behaves like that local tier, but it is hosted externally, by a third party, running a generalist model none of us trained. It sits in a gap the existing map does not quite cover: cheap and fast like a local model, but carrying a dependency and a data-sovereignty question closer to a frontier LLM.
The obvious potential opening is unstructured intake: an email, a scanned letter, a chat transcript, a free-text field on a form, all of which a rule engine handles badly without Natural Language Processing. Run a Jev Choice question over an inbound email — which of these eight categories does this belong to — and a case can be routed to the right work queue. Run a Score question over the same text for urgency, and priority in that queue is set before an triage human has read a word. Run a Jev Noul question asking whether the case shows signs of the kind of risk that warrants a closer look, and there is a triage layer sitting in front of the case type’s existing routing and SLA logic — doing in one typed call what previously needed either a person reading the intake, or a mature model that did not yet exist.
Pega’s own economic argument explains the decision choice precisely: route every task to the lowest-cost viable form of intelligence, and treat escalation to anything more expensive as a deliberate, governed choice rather than a default.
Jev looks, on that logic, like an obviously good routing target. Could a single typed call replace the upstream analytics pipeline currently needed to characterise and tag an incoming case? Could it stand in for the bespoke NLP model a data science team spent months training just to infer customer intent? Could it, more ambitiously still, remove the human triage step altogether — the person who currently reads an inbound case and decides where it goes?
Each of those would lower the cost per decision in exactly the way the economics recommend: less bespoke infrastructure to build and maintain, faster time-to-value for a new case type, and a real cost saved on work that is, for most cases, fairly mechanical.
Push on that ambition though and several questions arise.
- Accuracy: a bespoke NLP model, however unglamorous, was trained and validated against this organisation’s own cases, with a measured error rate; a generalist model’s error modes on this specific business are, by definition, unmeasured until something goes wrong.
- Compliance: categories such as vulnerability, complaints, and safeguarding are often not just conventionally reviewed by a person, but required to be, by rules written with a human reviewer in mind.
- Transparency: “the model returned 0.83” is not an explanation a complaints team, an ombudsman, or the customer will accept in place of a reason. And regulation is not just slow-moving here, it is actively catching up: Pega’s own position on this points at audit obligations that will eventually require organisations to show where and why a probabilistic system was used at all — a considerably higher bar than most case-triage logic could currently clear. Working out which categories can bear that scrutiny and which cannot is a compliance question before it is an engineering one.
None of that is safe, however, without one rule that has to be non-negotiable, because a case type has consequences a customer engagement engine does not: a wrongly triaged claim can miss a regulatory deadline, a demoted priority can leave a vulnerable customer waiting, and nobody downstream will have any way of knowing a probability score made that call.
A Jev-style hunch may only ever add scrutiny. It must never remove it.
Where hard rules and existing models suggest a minimal scrutiny path on a case, a hunch can raise a flag, request a second look, or route a case to a specialist queue. It must never be allowed to lower a priority, wave through an approval, or close a case that would otherwise have had one — there is no learned history behind the number, and no audit trail explaining why.
The fraud example from the first post makes the asymmetry concrete: a claim that trips none of the hard compliance rules but earns a middling Noul score should go to a human for a second look, not be waved through with extra confidence because two independent checks happen to agree. The reverse case is more dangerous, and more tempting to build: a claim that gets a reassuring 0.92 positive from Jev should still get exactly the scrutiny it would have got anyway. Hard compliance rules must still be followed. A generalist model’s confidence is not evidence, and should never be allowed to stand in for it.
None of which means full Jev-based automation is always the wrong call. A low-value, easily reversible case type with no compliance sensitivity attached — a routine address change, a low-tier query with no financial exposure — is a reasonable place to let Jev run the whole triage step unsupervised, upstream analytics and human review both; the lowest-cost-viable tier, for once, genuinely is the answer. The judgement call is knowing which categories those are, and for now, at least, that judgement still needs a person too.
As a case type matures and Process AI’s own predictions accumulate enough evidence to speak with real authority, the sensible expectation is that Jev’s role recedes rather than grows — handing routine categories to a model trained on the organisation’s own outcomes, and keeping its typed hunches for the genuinely new, the genuinely rare, and the genuinely unstructured. This is not a wholesale replacement for Process AI, but a genuinely new capability filling a gap that previously had no good answer.
Everything in this post so far has been about runtime — Jev looking at a live case as it arrives. There is a second, quieter place the same primitives could sit: watching the people and tools that design and build the workflow, rather than the workflow itself — Blueprint and Studio, not the case.
Blueprint already generates a proposed case type, flow and data model from a natural-language brief, and it is worth being clear that this is a different, and entirely appropriate, use of a frontier-scale model: exactly the kind of infrequent, high-value, creative synthesis Pega’s own position reserves for that tier, paying for itself once by producing a structure that then runs at near-zero cost. Jev’s role would be a separate, second pass over that output, not a substitute for it: a typed Noul or Score question run over the generated design before a human opens it — does this case type define an SLA, does this flow include an escalation path, how closely does this structure follow the patterns Pega itself recommends.
Studio is a closer parallel still, because Pega already runs a version of this idea at build time: Guardrails scores an application against best practice largely through static, rule-based checks — counts, circular references, naming conventions. Jev’s typed judgement reads as a complement rather than a replacement, for the same reason argued throughout this post: a static check counts well but judges badly — whether a flow is needlessly complex for what it does or whether a strategy resembles a known anti-pattern. And the same discipline applies: a flag on a build artefact earns a place in a review queue, not the authority to block a deployment, and a design with a reassuring score should still get exactly the review it would have got anyway.
Workflow and case management is, in the end, the easier half of this overall comparison, because Pega’s own architecture already has a place set for a fast, provisional, typed judgement call sitting alongside rules and models, and because the tiering question here has a fairly comfortable answer: Jev fills a real gap, on a tight leash. The harder question is what happens when the same tiering question is asked of the Customer Decision Hub, where the job is not routing a single case but arbitrating between dozens of competing actions for the same customer, at scale, in real time, with a formula built to be defended in front of a regulator — and where, unlike here, the answer is much less obviously comfortable. That is where we turn next in Part 3.