Every part of this series has added a condition. The state must be minimised. The question must be bounded. The output must be measured. The policy must stay authoritative. Uncertainty must have somewhere safe to go.
That can make a decision service sound like more trouble than it is worth. Sometimes it is. The aim of this final part is to make that call deliberately: to say when a typed decision service such as Jev is the right tool, when something simpler or something human is better, and how to find out cheaply which case you are in.
Kloofvale Local Municipality is fictional, and its systems and figures are illustrative. This is an independent CloudNala analysis; we have no commercial relationship with Jev AI or TypeSafe.
In plain language:
Use a decision model for a judgement you make often, can describe precisely and can afford to get wrong safely. Use something else for everything else.
The selection test
A workflow is a good candidate for a decision service when all of these are true:
- It contains a repeated judgement, made many times a week, not a few times a month.
- The valid answer shape can be defined: a set of options, an ordered rubric or a clear yes-or-no question.
- The input is natural language or messy state, so fixed rules cannot do the job well.
- Uncertainty is useful to the application, because it changes what happens next.
- There is a safe fallback for when the signal is weak or the service is down.
- The outcome can be measured, so you will know whether it helped.
- The organisation can accept the data and provider boundary described in Part 8.
Kloofvale's Fix-It triage passes every line. About 1,400 reports a week, four routes, messy multilingual text, a triage queue that already exists, and a clear outcome: urgent reports reaching the right department sooner without anything being lost.
Use deterministic code when
- The decision is exact arithmetic.
- A law or policy defines an unambiguous rule.
- A database lookup provides the answer.
- A permission system already knows whether the action is allowed.
- The input can be validated with a schema or a regular expression.
Do not ask a model whether a transaction exceeds a fixed limit. Compare the amount with the limit in code. Do not ask it how many days a report has been open. Subtract the dates.
TypeSafe's own notes on Jev 1.13 support this. They say the model "can be quite literal", "may struggle with tasks that require additional levels of indirection" and "struggles with tasks that require numeric precision". They also say it does not count reliably, reads dates as text, and, in its own words, "Jev is not a calculator." Those are practical reasons to keep calculations, exact comparisons and long chains of reasoning outside the decision model, and to say so in the design rather than discover it in production.
Use a general-purpose language model when
- The output is explanatory or generative.
- The user needs a drafted response.
- The problem requires multi-step synthesis or research.
- The answer space cannot be bounded without losing what makes the answer valuable.
The two kinds of model can work side by side. Once Jev has routed a Fix-It report to water, a general-purpose model might draft the acknowledgement to the resident in their own language, for a person to check before it goes. Each component does the job it is suited to.
Keep a human decision when
- The volume is low.
- The judgement changes someone's rights or materially affects them.
- The organisation cannot define what an acceptable error looks like.
- The evidence is incomplete or contested.
- The process is deliberately discretionary.
- The review itself creates important relationship value.
Kloofvale applied this test to its monthly park-maintenance report as well. It is written once a month, by one person, and the judgements in it are few and easy to check. There is nothing worth automating, so it stays exactly as it is.
A decision matrix
| Problem | Best starting point |
|---|---|
| Exact age eligibility from a date | Deterministic code |
| Route a free-text support message | Jev Choice candidate |
| Draft a compassionate customer reply | General-purpose LLM with review |
| Execute a refund | Authorised application workflow |
| Decide whether a refund request is explicit | Jev Noul candidate |
| Resolve a complex regulatory dispute | Qualified human supported by evidence tools |
| Score incident severity against a rubric | Jev Score candidate |
| Build and review the integration | BMAD plus coding-agent and CI controls |
A four-week pilot
A pilot should be short, bounded and able to stop. The four weeks below are the shape Kloofvale used for Fix-It triage.
Week 1: Define
- Choose one low-risk decision. For Kloofvale, routing to the four departments.
- Name the business and technical owners.
- Define the state, the question, the answer space and the fallback.
- Build a labelled baseline set from past reports, with names, numbers and addresses removed.
Week 2: Evaluate offline
- Test the Choice, Score and Noul wording against the tuning set.
- Measure errors by class and by language cohort.
- Shuffle the option order to check for first-option bias.
- Compare candidate models only if there is a reason to.
- Reject the use case if the signal is not useful.
Week 3: Shadow
- Run the decision service beside the call centre.
- Do not let it control any action.
- Measure agreement with the call-centre staff, confidence, latency, cost and the review demand each threshold would create.
Week 4: Limited production
- Automate only the lowest-risk, highest-confidence path.
- Keep the review queue and the fallback visible.
- Monitor business outcomes and overrides.
- Decide whether to expand, revise or stop.
Each week ends with a gate that can stop the pilot. Stopping at the end of week two because the signal is not good enough is a successful pilot. It cost two weeks and a labelled data set the municipality will use again, rather than a production incident.
Production-readiness checklist
Before a decision workflow controls anything, work through this list.
Decision design
- One bounded decision per question
- The right primitive chosen: Choice, Score or Noul
- Criteria that a business owner and the model can both understand
- An unknown or review route
- Documented costs for each kind of error
Data
- State is minimised
- Sources and freshness are known
- Sensitive fields are redacted or excluded
- Language cohorts are represented in the evaluation set
- Retention and cross-border rules are approved
Control
- The signal is separate from permission
- Deterministic policy is tested without calling the model
- High-impact actions have explicit controls
- Human review has capacity and a service level
- The safe fallback works with the model switched off
Engineering
- The API key is server-side and rotatable
- Response schema validation is enforced
- Timeouts, retries and a circuit breaker are configured
- Idempotency protects downstream actions
- Model and question versions are logged
Evaluation
- A locked regression set exists
- Precision, recall or scoring error is measured
- Calibration and threshold behaviour are checked
- Drift and override rates are monitored
- Business outcomes feed back into evaluation
The CloudNala view
Jev does not make an application intelligent by itself. It gives the application a narrow, probabilistic signal in a form software can consume.
The value appears when the surrounding system is disciplined: the state is minimised, the question is well defined, the output is measured, policy stays authoritative and uncertainty has somewhere safe to go. That discipline is not specific to Jev. It is what any decision service, from any provider, needs before it is trusted with real work.
BMAD can help a team design and build that system. Jev can supply a decision inside it. Neither removes the need for engineering judgement, governance or ownership.
Key points
Use it for repeated, bounded, measurable judgements. With a safe fallback and a provider boundary you can accept.
Use code for anything exact. Arithmetic, dates, limits, lookups and permissions belong in deterministic logic.
Use a general-purpose model to explain or draft. It can work beside a decision model, doing a different job.
Keep people on rights, discretion and rare cases. Volume and consequence decide, not novelty.
Pilot in four weeks with gates. A pilot that stops early on evidence has done its job.
Sources and further reading
Product details in this series were checked against public documentation on 13 October 2026. Product features, models, endpoints, response formats, pricing and terms can change; recheck them before implementation or procurement.
- Jev AI: developer documentation, Agent Skill overview, enterprise, pricing, privacy policy and terms of service
- Jev AI Agent Skill repository
- TypeSafe: introduction, System One concept, question primitives, API reference, models, confidence, Jev with coding agents and model jaggedness for Jev 1.13
- BMAD Method: documentation and releases
A few cautions carry across the whole series:
- Jev AI and TypeSafe are distinct. Jev AI describes itself as independently operated and not affiliated with, operated by or endorsed by TypeSafe. Confirm which account, endpoint, model, terms and support arrangement apply to you.
- The model line-up can change. Jev AI presents about a dozen decision models behind one interface, and availability and behaviour can shift.
- Documentation is not assurance. Public pages do not replace a security assessment, a data processing agreement, a service commitment or sector-specific legal review.
- Pricing is time-sensitive and shown in dollars. Recheck it before budgeting.
- The examples are original scenarios. Kloofvale is fictional, and nothing in this series claims that any named South African organisation uses Jev.
Previous: Part 9, cost, reliability and operations. This is the final part. All parts are on the series page, starting with Part 1, Jev in plain English.
How CloudNala can help
We help organisations decide where AI judgement belongs, where deterministic rules should stay and where people must keep the decision, and then build the control, evidence and operating model around whichever answer is right. A typical engagement starts with one repeated decision, a labelled set of real cases and a safe fallback, and runs the four-week pilot to a clear expand, revise or stop.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Decision Review or write to us at consult@cloudnala.co.za