A one-line customer message can create several back-office decisions: “Please change the delivery address. Has it shipped yet? If it has, leave it as it is.” The team has to understand the request, check the real shipment state, verify who may edit the order and record what happened.
Asking one model to do all of that mixes a language judgment with system authority. A safer design lets AI answer narrow questions about meaning, then lets Odoo rules and an accountable person decide what may happen to the record.
Jev is TypeSafe AI's decision model. It evaluates typed questions against a supplied state and returns structured answers that software can use. Its useful role here is not writing a customer reply. It is helping a workflow decide which queue a message belongs in, how ambiguous the classification is and where a person should review it.
This article describes a proposed workflow and pilot. It does not claim that Enersys has deployed Jev in a client project.
Separate meaning from permission to change a record
In the address-change example, Jev does not need every Odoo field and should not receive permission to edit a delivery. Its role can be limited to evaluating questions such as:
- Is this a change-address, delivery-tracking, cancellation or other request?
- Where does its urgency sit on the team's defined rubric?
- Does the request depend on a shipment condition that must be checked first?
Code then reads the shipment state from Odoo. If the delivery has not left, the workflow can create an activity for an authorised employee to validate the new address and confirm it with the customer. If it has shipped, the workflow follows the carrier and business policy for that state. The model never has to guess whether the parcel shipped because the operational system holds that fact.
The distinction applies beyond this example. Jev can help answer, “What is this person asking for?” Code determines, “What actions are allowed in the current state?” A named owner decides, “Should this exception be approved?”
Choice, Score and Noul have different jobs
TypeSafe provides three question types and can evaluate several questions independently against the same state. Its introduction recommends one narrow judgment per question. When a decision depends on several factors, the factors should be evaluated separately and combined in code.
Choice selects one option from a fixed list. It suits queue selection such as change_address, track_delivery, cancel_order or other. The response contains the selected option, the probability distribution across options and a confidence value.
Score places the state on ordered, described levels. A team could define urgency from “may wait for the normal service cycle” to “review before the warehouse cut-off”. Those levels need operational descriptions that people interpret consistently. Score should not calculate a discount, stock quantity or monetary amount.
Noul evaluates a yes-or-no question as a number between 0 and 1. One example is, “Does this request contain a condition that depends on shipment state?” Noul does not return a separate confidence field, so a threshold tuned for Choice should not be copied across to it.
None of these question types replaces a business rule. If an address change requires four conditions, code should check those conditions against real fields. Hiding all four inside one long natural-language question makes the control harder to test and audit.
Confidence can route work, but it does not certify one answer
For Choice and Score, confidence is derived from the shape of the probability distribution. A result concentrated on one answer has higher confidence than a result spread across several plausible answers. TypeSafe's confidence documentation describes how software can use the value to proceed, ask for more information or route to review.
Calibration has a narrower meaning than many teams assume. It describes groups of predictions, not a guarantee that one result with 0.9 confidence is correct. TypeSafe makes that limitation explicit in its AI primer.
A team should therefore derive thresholds from its own error costs. A delivery-tracking queue may tolerate a different threshold from an address change after a delivery record has been created. Thai-language thresholds need Thai test data. They cannot be inferred from English results or copied from a documentation example.
Keep exact rules in code and Odoo
TypeSafe's page on Jev 1.13 limitations says the model struggles with exact numeric work, counting, date comparison, multi-step indirection and large states filled with irrelevant detail. That gives the architecture a useful boundary.
Code or Odoo should continue to own:
- available-to-sell inventory, quantities, discounts, tax and net totals;
- whether a delivery state is before or after the permitted edit point;
- cut-off times, promised dates and policy windows;
- user permissions, company boundaries, warehouse access and record rules;
- duplicate prevention through references and idempotency keys.
Jev accepts text input according to its model reference. An image of a shipping label, an audio message or a PDF needs a text-preparation step first. OCR or a generative model may be useful when the source demands it. If the source is already text, adding another model only creates another failure and cost point.
The same model reference says English is Jev's strongest language and other languages need testing on the user's own content. Thai chat abbreviations, misspellings, street names and mixed Thai-English text therefore belong in the evaluation set.
Run a pilot small enough to answer one question
A sound first scope is “classify after-sales messages into an owned queue”. Jev does not edit records, approve refunds or change Odoo document states.
Start with historical messages that the organisation is permitted to use. Remove or substitute personal data where possible. Process owners then assign labels that correspond to queues someone actually owns. Include short messages, misspellings, mixed languages, several intents in one message and cases with insufficient information. If historical labels were created only to close tickets quickly, review a sample before treating them as ground truth.
Lock a holdout set before changing questions or thresholds. A time-based split can show how the approach handles newer message patterns and reduces the chance that near-duplicate messages from one conversation appear in both development and test data.
Compare at least three approaches on the same material:
- keyword or regular-expression rules maintained by the team;
- a small language model returning the same label schema;
- Jev using only the Choice, Score or Noul questions required by the scope.
Overall accuracy is not enough. Record errors by queue, especially work sent to the wrong owner, cases that should have stopped but passed and messages a person must reopen. Assign costs in operational terms. Sending a parcel to an old address has a different consequence from placing a tracking question in a slower queue.
The pilot should also measure human review rate, time from intake to creation of an Odoo activity and the full cost of the path. Report median and slow-tail latency, including retries, timeouts, OCR and other model calls when they exist. Cost should include model use, employee review, rule maintenance and correction of bad routes. Token price alone does not describe the business cost.
Begin in shadow mode. Show the proposed route beside the human decision without changing the live queue. Once the team understands the errors and sets thresholds from each queue's cost, it can enable low-risk routing. Decisions that affect money, dispatch, access or personal data should retain a named review point.
Settle integration and data questions before the pilot
Teams using the Vercel AI SDK can call Jev through experimental_evaluate with typesafe-ai/jev, as shown in the AI Gateway evaluation documentation. Because the interface is marked experimental, the team should pin versions, regression-test changes and keep a rollback path for an operational workflow.
On data handling, TypeSafe's Privacy Policy says its services are hosted in the United States, the service collects submitted Input, does not train or fine-tune models on that Input and retains personal data for as long as reasonably necessary for its service or business purposes. Its legal documentation says zero data retention is available to enterprise customers, so a project should not assume ZDR is the default. Hosting Odoo on Thai cloud infrastructure does not keep data in Thailand after a workflow sends that data to Jev.
Before testing, the data owner should approve which fields leave the system, how long they are retained, what must be logged and how deletion is handled. Start with de-identified text when it can answer the evaluation question. If real names, addresses or order details are required, review the contract, processing terms and data path with the organisation's privacy owner.
Enersys has worked on bringing Shopee and TikTok channel data into Odoo and on a manufacturing Odoo programme covering 156 users with an MES connection. Those experiences show why exceptions, data ownership and hand-offs matter more than the model name. They are established Enersys contexts, not evidence that Jev was used in either project.
The pilot should end with a measured decision: which queues, if any, receive less repeated reading, and at what error rate, review load, latency and total cost? Keeping Jev as a routing suggestion without approval authority is a valid result when the evidence does not support further automation.
Primary sources
Read how to design a Shopee and TikTok connection to Odoo
Read the Odoo readiness lessons from a 156-user manufacturing scope with MES
Talk to Enersys about Odoo and AI workflow design
