Integrate Jev decision models with Apache Camel and Red Hat OpenShift

Having explored how Jev handles bounded semantic judgments, we now shift from theory to execution. This guide walks through making your first API call step by step and demonstrates how to integrate Jev into a production-ready, vendor-neutral enterprise architecture.

We will build one small example from beginning to end. A customer types "I would like a coffee." We want to know whether the order is an americano, cappuccino, latte, or espresso. The sentence does not contain enough information to choose correctly. That is why the list must also contain ask_for_clarification. Without that option, the model is forced to pick 1 of 4 drinks even when none is justified.

Step 1: Get access and prepare the shell

Access currently requires a TypeSafe account (early access) and an API key. This shell example needs curl and jq. Export the key only in your shell or inject it from a secret manager. Do not place it in the script or commit it to Git.

export TYPESAFE_API_KEY="your-api-key"
for tool in curl jq; do
  command -v "$tool" >/dev/null || echo "Please install $tool first"
done

Step 2: Define the state

State is the information Jev must judge. For the first call, it is only the customer's exact sentence. Do not silently rewrite "a coffee" as "an espresso," because that would insert a decision before the model is called.

CUSTOMER_REQUEST="I would like a coffee."

Step 3: Define the allowed answers

A Choice question needs options and descriptions. The descriptions explain how each drink differs. The clarification option is a real application outcome: it tells the ordering interface to ask another question instead of sending an uncertain recipe to the coffee machine.

REQUEST_BODY=$(jq -n --arg state "$CUSTOMER_REQUEST" '{
  state: $state,
  model: "jev-latest",
  questions: {
    drink: {
      type: "choice",
      instructions: "Which drink does the customer explicitly want?",
      criteria: {
        americano: "Espresso diluted with hot water",
        cappuccino: "Espresso with milk and thick foam",
        latte: "Espresso with more milk and thin foam",
        espresso: "Small concentrated coffee",
        ask_for_clarification: "No specific drink was identified"
      }
    }
  }
}')

Step 4: Send the request

Send the JSON body to TypeSafe's hosted System One endpoint. The Authorization header carries the API key. The --fail-with-body option makes curl return a failure status while still showing the API's error response. Expect 401 for a missing or invalid key, 422 for a malformed question, and 429 or 529 when you should retry with backoff.

RESPONSE=$(curl --silent --show-error --fail-with-body \
  --request POST "https://api.typesafe.ai/v1/systemone" \
  --header "Authorization: Bearer $TYPESAFE_API_KEY" \
  --header "Content-Type: application/json" \
  --data "$REQUEST_BODY")

Step 5: Inspect the answer and probabilities

Use jq to print the named answer. A realistic response to such an ambiguous sentence should favor clarification, but the following values are illustrative; actual output can differ by model version and wording.

printf '%s\n' "$RESPONSE" | jq '.answers.drink'
 
# Illustrative output, not a recorded Jev response:
# {
#   "type": "choice",
#   "choice": "ask_for_clarification",
#   "probabilities": {
#     "americano": 0.10, "cappuccino": 0.07, "latte": 0.08,
#     "espresso": 0.12, "ask_for_clarification": 0.63
#   },
#   "confidence": 0.54
# }

Notice that confidence (0.54) is not the same number as the winning probability (0.63). TypeSafe derives confidence from the shape of the whole distribution: all probability on one option gives 1.0, and the more evenly it spreads, the lower the confidence. Choice and Score answers carry a confidence value; Noul answers do not. The response also contains a model field with the concrete version that answered, because jev-latest is an alias. Log that version with every decision so that you can explain later why behavior changed.

Step 6: Let the application decide what happens

Jev has judged the sentence; it has not placed the order. When clarification wins, or when confidence is below a threshold you have tested, ordinary code asks the customer a follow-up question. When a specific drink wins with sufficient confidence, code proposes that drink and asks for confirmation. The coffee machine receives a recipe only after validation and confirmation.

MIN_CONFIDENCE=0.70   # choose after testing with your own examples
CHOICE=$(printf '%s\n' "$RESPONSE" | jq -r '.answers.drink.choice')
CONFIDENCE=$(printf '%s\n' "$RESPONSE" | jq -r '.answers.drink.confidence')
 
below() { awk -v c="$1" -v t="$2" 'BEGIN { exit !(c < t) }'; }
 
if [ "$CHOICE" = "ask_for_clarification" ] ||
   below "$CONFIDENCE" "$MIN_CONFIDENCE"; then
  echo "Which coffee: americano, cappuccino, latte or espresso?"
else
  printf 'Proposed order: %s (confidence %s). Please confirm.\n' \
    "$CHOICE" "$CONFIDENCE"
fi

Now try clearer inputs. "A double espresso, please" should point strongly to espresso. "A cappuccino with oat milk" should point to cappuccino; oat milk is a separate attribute that code or another bounded question must capture. "A large coffee with lots of milk" can suggest a latte but can remain ambiguous. These variations belong in the evaluation set before the feature reaches customers.

Where the judgments fit in an agent

Imagine a customer asking where a delayed bean shipment is. An LLM can draft an investigation plan and later summarize evidence. A bounded judgment can decide whether a supplier email is relevant or which registered tool is most appropriate. Code validates tool arguments, checks authorization, calls the tool, and records what happened. A model score should never itself authorize payments or other consequential actions. For a complaint, the order is: Jev assesses the intent, code applies policy and decides the outcome, and the LLM writes a reply for the outcome that code approved.

As shown in Figure 1, the coffee shop agent separates semantic evaluation, policy enforcement, and text generation into distinct stages.

2 more practical examples

Bounded semantic judgments apply to broader agentic and integration workflows beyond single-prompt classification tasks:

In retrieval-augmented generation (RAG) filtering, search returns 20 candidate manuals. A relevance question scores each manual for "How do I descale this espresso machine?" Code filters low-scoring candidates and sends the selected passages to an LLM, which writes an answer with citations. Measure retrieval recall so that filtering does not silently discard the right manual.

In model routing, a request might be classified as a simple FAQ, code task, complex reasoning or sensitive data. A routing policy can then choose an approved small model, coding model, large model, or human review. The policy must independently enforce data residency and access controls; semantic classification cannot replace them. Note the irony for sovereignty: if the router itself is a remote service, the prompt has already left your environment before the policy decides where it may go. Figure 2 illustrates how bounded judgments operate inside both RAG filtering and model routing workflows.

Clean architecture and switching providers

The application can expose a ComplaintClassifier interface whose response carries the team, the probabilities, and a confidence value. A Jev adapter, an LLM adapter, and a rule-based implementation can all implement that interface. The use case holds thresholds and actions, so you can swap implementations or replay evaluation cases without hiding business policy in prompts.

interface ComplaintClassifier {
    ComplaintAssessment assess(Complaint complaint);
}
 
record ComplaintAssessment(
        Team team,
        Map<Team, Double> probabilities,
        double confidence,
        String modelVersion) {}

Keep your options open with a platform contract

A coffee chain would not redesign every register whenever it changes bean suppliers, buys a different espresso machine, or adds a specialist order taker. Each shop uses a stable ordering contract. Behind the counter, the platform can decide whether an order goes to the local machine, a central barista, an external coffee house, or a person. AI applications benefit from the same separation.

Instead of letting every application call TypeSafe, a hosted LLM provider, and a self-hosted model directly, expose organization-owned capabilities such as classify order, generate reply, embed text, or answer question. The application depends on that capability contract. Adapters translate it into Jev Choice questions, an OpenAI-compatible chat request, a KServe inference request or deterministic code. A new service can then be introduced without distributing new credentials and provider-specific logic across every application.

What an AI gateway adds

An AI gateway gives applications 1 controlled entrance to multiple AI services. Depending on the product and integration, it can centralize credentials, rate limits, tenant quotas, routing, fallback, cost records, latency metrics, audit information, and data-handling policies. This is the digital equivalent of 1 order counter recording who ordered what, which barista received it, how long it took, and what it cost.

The interface deserves care. Jev is not a chat-completions model, and its Choice, Score, and Noul semantics should not be flattened into a pretend text response. A gateway that natively understands Jev can expose those fields directly. Otherwise, a small Jev adapter can translate an internal DecisionRequest into TypeSafe's System One API and map the typed answer back into the organization's contract. Keep probabilities, confidence, and the model version intact; they are part of the value.

Camel as the translation and integration layer

Apache Camel can provide the runner and translator behind that counter. A Camel route can accept the organization's stable DecisionRequest, obtain the TypeSafe credential from a managed secret, construct Jev's provider-specific JSON, call the hosted HTTPS endpoint, and map the typed result into a DecisionResponse. The same route can add timeouts, error handling, retries where they are safe (for example, on 429 and 529 responses), circuit breaking, metrics, and an explicit fallback or human-review path. Camel's components and Enterprise Integration Patterns are useful when a decision must also interact with queues, databases, event streams, or existing business services.

In the coffee shop, the gateway is the order counter: it checks who may order and records the transaction. Camel is the experienced runner behind the counter: it rewrites the standard ticket in the specialist supplier's format, sends it to the correct desk, and brings the result back without losing the confidence values. Jev remains the external specialist order taker. The registers do not need to learn that specialist's address, credentials, or private vocabulary.

What Model-as-a-Service adds

Model-as-a-Service (MaaS) turns selected capabilities into shared, discoverable API endpoints for internal teams. Red Hat describes MaaS as more technology-neutral than LLM-as-a-Service: it can cover LLMs, fine-tuned models, and predictive models. Red Hat's framing centers on privately hosted models, so adding an external service such as Jev stretches the pattern. That is workable, as long as the catalog entry is honest: it points to the organization-owned Jev adapter, and it clearly marks that the model runs at TypeSafe and that data leaves the organization. On Red Hat's own sovereignty spectrum, relying on a provider's closed model sits at the rented end.

For the coffee chain, MaaS is the company menu. Developers do not need to purchase a machine or negotiate with a supplier for every new application. They request an approved service, receive credentials or entitlement, and see its intended use, limitations, data location, ownership, cost, and service level. Platform teams gain a place for showback or chargeback, lifecycle management, and deprecation notices.

How this supports Jev now and another solution later

Suppose support applications call an internal semantic decision endpoint. Today, its Jev adapter sends state and bounded questions to TypeSafe. If a future locally deployable decision model meets the same quality bar, the platform team can add a second adapter, route a small percentage of traffic to it, compare results, and migrate deliberately. Applications keep sending the same business request. This reduces lock-in without pretending that providers are identical.

The abstraction should therefore be capability-based rather than provider-based. A generic askModel(prompt) method merely hides a URL. A decideDrink(state, choices) or assessComplaint(state) contract describes what the application needs and allows the platform to validate the response. Preserve an escape hatch for capabilities that genuinely cannot fit the common contract.

Where Red Hat OpenShift adds value

Red Hat OpenShift provides the operating platform for the organization-owned layers: the API or AI gateway, Camel routes, Jev adapter, policy service, evaluation jobs, audit pipeline, and client applications. Teams can manage these as containers with namespaces, secrets, service accounts, network policies (including egress rules for the TypeSafe endpoint), health checks, scaling, observability, and GitOps-based delivery. Jev itself remains TypeSafe's hosted service. It is not deployed through vLLM, llm-d, or OpenShift AI model serving.

This separation is the added value. Onboarding Jev becomes a focused platform change instead of a rewrite across every product: define the internal decision contract; add a Camel route or adapter; configure credentials and outbound access; expose it through the gateway; attach policy, quotas, and telemetry; run evaluation and security checks; then release it progressively. With those foundations already in place, a team can integrate a new service in days rather than distributing provider-specific code and secrets across many applications. "Days" is a practical target, not a guarantee; procurement, data review, evaluation quality, and production controls can extend the work.

Red Hat OpenShift also gives the platform team a controlled place to change suppliers or add alternatives. A new adapter can run beside the old one, receive shadow traffic, record quality and latency, and be rolled forward or back without changing each application. OpenShift AI serving remains relevant for other models whose weights are available and supported, but it is a separate path, not the way Jev runs. The common contract, gateway, and Camel integration are what let hosted services, internal models, and deterministic code participate in 1 governed platform.

As shown in Figure 3, Red Hat OpenShift hosts the gateway and integration layer while Jev remains an external service.

What to test before using it

Begin with 1 bounded decision, such as complaint routing. Build a labeled set that includes ambiguous orders, negation, missing details, prompt injection inside customer text, and uncommon cases. Compare Jev with your current LLM structured output and a simple rules baseline. Record correctness, calibration, latency from your own region, total cost, and human override rate. Keep precise arithmetic, dates, permissions, and side effects in code. Review the vendor's current API, data processing terms, and access conditions before implementation.

Sources and status

TypeSafe launched Jev on September 15, 2026, in early access. Its benchmark and pricing descriptions are vendor-supplied and might change. The API details in this article were checked against TypeSafe's documentation on September 21, 2026. The examples and diagrams are original explanatory material.

• TypeSafe launch announcement
• TypeSafe quickstart
• TypeSafe API reference
• TypeSafe confidence
• TypeSafe workflow evaluations
• Red Hat: What is Model-as-a-Service?
• Red Hat OpenShift AI overview
• Red Hat OpenShift AI installation and serving components
• Apache Camel core documentation
• Red Hat middleware and Camel overview

Building a resilient platform layer for System One decisions

System One models like Jev offer a compelling middle ground between rigid keyword rules and open-ended generative LLMs. However, making them production-ready requires more than firing off API requests. By decoupling application policy from model predictions and wrapping external services behind stable capability contracts on OpenShift and Apache Camel, you protect your core architecture from vendor lock-in. Whether Jev powers your complaint routing today or another decision service takes over tomorrow, building a governed platform layer ensures your application architecture remains resilient, flexible, and ready to scale.