Every workflow has steps where a rule is too brittle and a person is too slow. Is this failed pipeline run worth a retry or a rollback? Does this claim need a second pair of eyes? Can this agent run the command it just proposed? Today those steps end up as hard-coded gateways that nobody dares to touch, as manual tasks that pile up in a queue, or as an LLM call that works in the demo and gets switched off in production because nobody can say how often it is wrong.
Jev by TypeSafe AI changes the shape of that step. TypeSafe calls it a System One model, after Kahneman’s fast, intuitive thinking. The LLM plays the System 2 role: slow, deliberate reasoning on the cases that need it. Jev answers typed questions with calibrated probabilities in a few hundred milliseconds. The overview of System One models in enterprise architecture covers the category and where it fits across integration, process intelligence and agentic AI. The post on Jev with Apache Kafka and Flink covers the event-driven data streaming pattern. This post covers the process side: workflow orchestration and process intelligence.
A calibrated decision with a probability is the missing primitive in workflow orchestration and process intelligence. It replaces brittle gateway code, the clear cases in manual queues, and LLM calls nobody trusts in production, because it turns “automate or not” from a binary into a threshold the process owns. A System One model like Jev gives the number. The workflow decides what the number means, keeps the audit trail, and sends the cases that must be explainable by rule to a decision table or a person.
Jev in Workflow Orchestration
Workflow orchestration is where a System One model like Jev turns from a single call into a governed step: the orchestrator asks the question, branches on the answer, and keeps the record.
The Confidence Gate as a Workflow Pattern
The pattern is simple. A task in the flow sends the case to the decision model with a few typed questions. The model returns answers with probabilities. A gateway compares the probability against thresholds and branches. High confidence proceeds to an automated task. Medium confidence goes to an LLM task that reasons about the case and writes an explanation, and if the LLM is still unsure, on to a person. Low confidence goes straight to a human task. Every branch ends in the same log entry: the probability, the threshold, the branch taken, the outcome, and the model version.
The thresholds are inputs of the flow, versioned with the flow, pinned to a model version. They do not live in the model, and they do not transfer between model versions or between question types, as early adopters have found out. When TypeSafe ships a new version, the flow re-scores a sample from the log and the thresholds get re-tuned before the version goes live.
The plumbing belongs to the workflow as well, whether it runs a business process, a data pipeline or an infrastructure job. Timeouts and rate-limit responses from the hosted API trigger a fallback task that calls an open decision model, so the process does not stall on a vendor incident. Retries, backoff and the audit trail are what orchestrators do anyway. Jev adds one more task type to a pattern the orchestrator already knows. The 0.87 in the figures is an example of the probability the gate compares: 87% confidence that the chosen answer is right.
The Same Gate Across All Orchestration Domains
The gate pattern is identical wherever a workflow runs, and that is the point of unified orchestration. Most teams meet the pattern first in one domain:
- Data pipelines. A failed run is scored for likely cause and business impact. High confidence that it is transient triggers a retry. High confidence that the source changed triggers a rollback and a ticket. Low confidence pages the on-call engineer with the log attached. A permissions error that will fail the same way five times gets no retries at all.
- Infrastructure. Configuration drift and monitoring alerts are scored before an automated remediation runs. The flow fixes what it is sure about and holds the rest for an operator.
- Applications. Claims, support tickets and loan files get a decision at each step. The confident share flows through, the uncertain share lands with a person, and the criteria change without a release.
- Business processes. Approvals and exceptions get a decision where the policy changes faster than the rules engine can follow. The gate replaces the manual queue for the clear cases and keeps the person for the rest.
Most enterprises start with one of these and pick the orchestrator that is native to that domain: a data orchestrator, an infrastructure automation tool, a BPM engine. The gate pattern then has to be rebuilt in every tool, with its own thresholds, its own fallback and its own log format. A unified orchestrator runs the same gate once, across data, infrastructure, applications and business processes, with one decision log.
The argument holds for any orchestrator that spans the four domains. Kestra is one example of such a unified orchestration platform.
Agent Flows: A Check Before Every Tool Call
The most direct use of the gate is in front of an AI agent. Before an agent runs a command, a decision task asks a few typed questions about the pending action: Is it irreversible? Is it off-task? Is it outside the agreed scope? Low confidence on any of them pauses the agent and opens a review. The LLM inside the agent stays the reasoner. The decision model is the check, and the orchestrator logs the decision next to the action. This is how “trusted agentic AI” becomes measurable: every action carries the probability that allowed it.
How Orchestrators Add Jev: Airflow, Camunda, Kestra, and Others
Every orchestrator can call Jev over HTTP. The difference is how much of the gate the tool understands. Four building blocks matter: a task that asks the typed questions and returns the probabilities, a branch that routes on the probability, a human step that holds the case below the threshold, and a log entry per decision. A retry policy that first asks what kind of failure occurred is the same gate applied to the pipeline itself.
The orchestration vendors moved quickly after the launch, each from its own domain. Camunda added a Jev connector that feeds BPMN gateways, with a public demo that scores the complexity of a request to pick the right LLM for an agent. Apache Airflow added Jev to its AI provider package, the add-on that holds its LLM operators. It comes with a confidence branch, a review step for answers below the bar, and a failure-classifying retry policy. Kestra added a plugin task that evaluates typed questions and feeds the existing Switch and If tasks, with a batch variant for files. All three follow the same split: the model gives a probability, the workflow decides.
The question to ask any orchestrator is whether that gate can run across all four domains with one decision log, or only in the domain the tool was built for.
Jev in Process Intelligence
Process intelligence combines process mining, workflow orchestration and the decision gate between them. Mining shows where a process actually runs and where it stalls. Orchestration runs the improved version. The gate decides which path a case takes. A calibrated decision model changes the gate, and through it the other two.
When a Rules Engine Still Beats Jev
In a regulated process, the classic rules engine has one advantage that a decision model like Jev cannot match. A decision table, the rules-engine format that BPM tools standardize as DMN (Decision Model and Notation), does exactly what someone wrote down. It can be read line by line, shown to a regulator, and it changes only when a person edits it and someone approves the change.
Jev’s logic is learned from data. Nobody can read the rule it applied, it can be confidently wrong on inputs unlike its training data, and its behavior shifts with every model version. It is probably reproducible, since TypeSafe describes the outputs as consistent for similar inputs, but it is not specified. Jev has the same auditability problem as any machine learning model. It is just faster and cheaper.
The workflow provides the determinism that the model lacks. The gate routes by rule. Above one threshold the case proceeds, between the thresholds it escalates, below the lower one it waits for a person. Cases that must be explainable by rule go to a decision table or a human task, whatever the model thinks. The orchestrator holds the audit trail. Rules and System One models like Jev are neighbors in the same flow, and the flow is what a regulator gets to see.
The Decision Log as Process Mining Input
Every gate decision lands in a log that the orchestrator writes: Jev’s probability, the applied threshold, the branch taken, the outcome, and the model version. This decision log is a new kind of event source for process mining. A classic activity log says which step ran when. A decision log says why a case took a path and how sure the system was.
Process mining can now answer questions it could not answer before. Where are thresholds too tight, so cases with high confidence still wait for a person? Where do reviewers overrule the model, and were they right? Which manual step has run for six months with the model at high confidence every time, and could be automated tomorrow? Did confidence drift after the last model version, and did anyone re-tune the thresholds? The gate turns automation from a project into a measurement.
What the Decision Log Means for Celonis, SAP Signavio, and Other Process Mining Platforms
Process mining vendors already ingest event logs from systems such as ERP, CRM and workflow engines, plus the task-level activity captured by task mining. Celonis, SAP Signavio, UiPath Process Mining and the others will treat a confidence-annotated decision log as the richer input it is, and the obvious next feature is a decision-quality view: confidence distribution per step, overrule rate per reviewer, automation candidates ranked by confidence and volume.
There is a second effect that the miners should notice. If the orchestrator already writes the decision log, the orchestrator holds the most valuable process data, and the miner is downstream of it. The line between “we mine your process” and “we run your process” gets thinner every time a decision model replaces a manual step. The orchestrators that own the gate own the log.
The miners see this coming. Gartner renamed its Magic Quadrant from process mining to process intelligence in 2026. And Celonis, for example, now positions its platform as the operational context layer for enterprise AI, built around a process graph as a digital twin of the business. That is closer to how Palantir sells Foundry than to classic process mining, and a decision log with confidence values is exactly the kind of context such a platform wants to own.
When to Use a System One Model Like Jev in a Workflow
A confidence gate with a System One model like Jev fits a workflow step well. The more of the following apply, the better the fit:
- The step handles unstructured input. A ticket, a claim, a log, an alert, an agent action.
- The criteria change often. A policy update should be a text edit in the flow, not a rules project.
- There are no labels yet. The decision log produces them.
- Several questions apply to the same case. One call answers all of them.
- A few hundred milliseconds per step is acceptable. Inside a workflow it almost always is.
- A human path already exists. The gate reduces the manual share instead of inventing a new process.
When Not to Use a System One Model Like Jev in a Workflow
In the following cases a System One model like Jev is the wrong tool. Each bullet names what to use instead:
- Decisions that must be explainable by rule. Regulated credit decisions and eligibility rules have to show the exact rule that applied. Jev returns a probability from learned logic that nobody can read line by line. Use a rules engine with decision tables.
- A fixed, approved rule set. When the rules are stable and already written down, a model adds cost and uncertainty to a question that has one known answer. A rules engine is cheaper and clearer.
- SLA paths under 50 milliseconds. The gate is a remote call of a few hundred milliseconds, so it breaks the budget before the model even answers. Keep it out of the hot path.
- Steps that need a written justification. Jev returns a choice and a probability, not text. A customer letter or an audit note needs an LLM task, possibly after the gate.
- Data that cannot leave your infrastructure. Jev is a hosted API, so the case data goes to the vendor with every call. Run an open model that speaks the same API, such as Laya or Kev, in your own data center or cloud account instead. They are different models with their own accuracy, so check the calibration yourself before the probabilities drive a gate.
- Very large option sets. Jev handles up to 255 options per choice and switches to a slower two-stage process above that. Route across a large category tree with a hierarchy of questions instead.
Jev Production Readiness for Workflows
Expect realistic savings. The launch multipliers apply to a single call. Across a whole system the gain is one order of magnitude, not several, because the hard cases still go to a larger model and the cache, fallback and review paths cost money too. Early production reports of a cascade, with Jev as the first stage and a frontier model as the second, put the cost two orders of magnitude below the frontier model alone, at nearly the same accuracy.
Run the gate in shadow mode first: a parallel branch that scores every case and logs the result while the existing path decides. Compare the log with what people did, tune the thresholds, then switch. Version the thresholds with the flow and pin the model version, because a new version changes the probabilities. Watch rate limits against parallel executions, since a burst of workflow runs hits the API harder than a single stream. Keep the fallback lane to an open decision model. As of September 2026, Jev has one published model version and publishes rate limits without an SLA.
What Jev Means for Workflow Orchestration and Process Intelligence
The confidence gate is the primitive. The orchestrator owns the determinism and the audit trail. The process miner reads the log and points at the next step to automate. Jev, or any decision model after it, makes the gate cheap enough to put in front of every step that used to need a person, and measurable enough to prove when the person is no longer needed.
This series started with how System One models like Jev change enterprise AI architecture and continued with why Jev fits Apache Kafka and Flink better than LLMs. This post closes the loop with the process layer. Start with one workflow where a manual step handles clear cases most of the time, add the gate in shadow mode, and let the log tell you when to switch.
To follow this work across data integration, workflow orchestration, process intelligence and trusted agentic AI, subscribe to the newsletter and connect on LinkedIn.
