01
Stock enquiries
A lookup or a stock movement?
Distinguish a question about availability from an action that changes a record. Apply a separate permission check before any change.
Jev integration · Decisions with structure
Turn a request into the right next step.
A question, an action and an unclear request need different responses. Use TypeSafe’s Jev to help choose a defined route, then let your application check access, apply the rules and handle what comes next.
Discuss a Jev integrationRequest routingDifferent requests. Different routes.
The request“Where is item A17?”
RouteStock lookupDefined outcome
Check access → retrieve location
Read-only information request
Put it in the context of your work
Picture this in your business.
Different businesses. Familiar problems. Here are a few useful places to start.
02
Service requests
Who needs to deal with this?
Map a supported request to a team or workflow, and ask for clarification when essential context is missing.
03
Decision support
Which option fits the criteria?
Evaluate candidates against explicit requirements, then test the routes against ordinary and difficult cases before expanding the pilot.
The problem
Give each part of the system a clear job.
Jev is designed to return structured decisions from a supplied state and typed questions. In an assistant, a conversational model can handle dialogue while Jev helps identify a route. The application then checks permissions, retrieves the relevant information and decides which workflow may run.
What we can build
Where a Jev integration may fit.
- Intent classification. Distinguish a request for information from a request for action or human help.
- Workflow routing. Map a supported intent to a defined next step.
- Candidate evaluation. Explore scoring or selection against explicit criteria, with business rules applied separately.
- Review handling. Use uncertainty signals alongside validation and permission checks to decide when a person should look.
- Application integration. Connect the decision layer to an existing interface, API and monitoring view.
How it works
One request. A defined route.
A team member asks where to find material for a job. The system identifies the request, checks the user's access and runs an approved lookup. It presents the retrieved information or sends the unresolved request to a person.
A useful next step
A pilot built around your own examples.
We define the supported routes, assemble representative requests and test both clear and ambiguous cases. The pilot records what route was chosen, whether the result was useful and when human review was needed.
Thresholds are selected from evaluation results and the consequences of a mistake. A confidence value does not replace access control or establish that a decision is correct.
How this service works
From a natural-language request to a defined application route.
An operational application needs to separate stock questions from stock changes.Follow the example through five stages, with a clear output at each step.
01Understand
Map the requests and the existing application.
We inspect the workflows, available context and application rules. A question about an item and a request to move it may sound similar, but they need different routes and different permissions.
What you take away
A request catalogue and an application-boundary map.
The starting pointStart with the inputs.
01User request
02Application context
03Access rules
The question to resolveA lookup, an action or a question to clarify?
02Agree
Define the routes before connecting the model.
We agree the supported request types, expected structured outputs and what happens when details are missing. Access checks and state changes remain in application code, with the exact integration reviewed against Jev’s current interface.
What you take away
A route contract, integration scope and validation rules.
The agreed scopeA focused first result.
- Route a stock-location question
- Separate stock-movement requests
- Ask for missing item details
Keep the boundaries clear
A route never replaces the application’s permission and action checks.
Confirm access, dependencies and costs before work starts.
03Build
Build the connection inside the workflow.
A reviewable slice turns a request into a defined route and passes the validated result to the application. You can inspect the context, route and next action while the integration is being developed.
What you take away
A reviewable integration with explicit application handling.
A view to reviewMake the work visible.
First working view
01Request · Where is item A17?
02Defined route · Stock lookup
03Application · Check access, retrieve location
Review together → refine the important details
Check it against the purpose
Does this view make the next decision clearer for the person using it?
04Test
Try ambiguous, unsupported and action requests.
We test representative requests against the expected routes. Malformed outputs, missing identifiers and disallowed actions need a visible fallback rather than a guessed or unchecked operation.
What you take away
Routing checks, output validation and fallback behaviour.
The checks that matterThe condition changes the decision.
The input or conditionWhere is item A17?
Expected resultStock lookup
The application checks access before retrieving location.
Agree the check. Inspect the result. Keep exceptions visible.
05Hand over
Document the contract and its dependencies.
The handover explains routes, context, provider configuration and the application checks around each action. Changes to the route set or model integration need review and regression checks.
What you take away
A route guide, dependency inventory and maintenance plan.
Ready for everyday useThe result comes with context.
Route contract
Supported requests, required fields and the application handler for each route.
Application checks
Where permissions, validation and approval are enforced around actions.
Dependencies & review
Integration configuration, supported interfaces and checks after a route or provider change.
The next stepKnow how to use it.
Know who owns it.
Know who owns it.
Maintenance and continuing support are agreed around the project.
See the wider approach to scope, collaboration and handover.
How we work togetherA few useful answers
Questions before
the first conversation.
Do we need to replace our conversational AI?
Not necessarily. A structured decision layer can be evaluated alongside an existing conversational interface.
Can Jev directly authorise an action?
Authorisation belongs in your application. A model output may suggest a route; the software must still check whether the user and workflow are allowed to take it.
What happens when a request is ambiguous?
The application can ask for clarification, collect more context or hand the request to a person.
Are you an official TypeSafe partner?
EfiOps is an independent integration provider. No official partnership or endorsement is claimed.
The next useful conversation
What decision would your software benefit from making?
Bring a few real examples and the possible outcomes. We can evaluate whether Jev is a useful fit.
Discuss a Jev integrationStart with what needs to changeA report I keep rebuildingA task I keep repeatingA website we’ve outgrownSomething else entirely