Jev and local AI: a stronger assistant without sharing business secrets

A local language model reads company documents, drafts answers and assists employees. Yet some of its work consists of small decisions: whether a page is relevant, which topic a document belongs to, or which tool to use next. Those decisions do not always need a long response from a large model.

Jev, TypeSafe’s model for structured judgments, offers an interesting division of work. It can handle selected decisions while the local AI writes and reasons over private business context. Here is where that combination might help—and how to design it without sending sensitive business information outside the company.

The supplied awesome-jev repository is an unofficial community directory. It helps discover projects, but inclusion does not establish production readiness. Technical statements below were checked against TypeSafe documentation on September 26, 2026. Awesome Jev: unofficial community directory ↗

A Jev request supplies context, called state, and questions. Choice selects an option, Score evaluates a defined rubric, and Noul returns a value between zero and one for a yes/no question. The output is designed for software to consume. TypeSafe: Jev and structured decision primitives ↗

Imagine a local model drafting a technology briefing. Jev could judge whether public pages address a general topic and contain useful practical information. Code assembles the shortlist; the local model then explains its relevance to the company.

This improves the surrounding workflow rather than changing the local model’s weights. Potential benefits include cleaner context, fewer lengthy generation calls for simple choices and clearer intermediate decisions. Better quality or lower cost must still be demonstrated on the actual task.

The local model can hold the company’s private context. An external assistant should receive only work that does not require that context at all.

This article considers TypeSafe’s official hosted API. It accepts state and questions at the external api.typesafe.ai endpoint. Installing its client library on an office server does not move inference into the office. TypeSafe: hosted System One API ↗

TypeSafe states that it does not train models on user data and separately offers enterprise zero data retention. Those concern processing and storage, not the absence of transmission. Our proposed architecture has a stricter rule: sensitive information must never enter the outgoing request, regardless of provider commitments. TypeSafe: data-handling commitments and enterprise ZDR ↗

Sending a contract “just for checking” and receiving a single score still sends the contract. A small response says nothing about the amount of input disclosed. An external leakage detector shown private correspondence already receives that correspondence.

Jev therefore cannot decide whether it is allowed to see a document. That decision must happen inside the company before the network request.

We propose two separate domains. Contracts, purchase prices, customer records, correspondence, task history and the internal knowledge base remain private. The external workflow uses only previously approved public material and general questions.

An employee asks the local AI for help. If outside information is needed, code selects an approved general task, sends public context, receives judgments and brings the results back. Matching those results to real projects, calculations and final writing stays local.

For example, Jev could screen public backup guides for whether they describe a recovery procedure. It does not need internal system names, database sizes, network diagrams or audit findings. The local assistant compares the selected guides with the company’s infrastructure afterward.

The query itself may also be sensitive. Interest in unusual equipment, a particular customer or a transaction deadline can reveal plans. Sensitive research should therefore use local selection even when its sources are public. Public availability and permission to reveal interest are separate checks.

The following are proposed pilot scenarios, not deployments we have carried out. Each starts with an explicit permitted input, followed by a test of whether Jev adds value.

A local model benefits from suitable sources. An official TypeSafe example adds a passage-classification stage between retrieval and generation. The pattern can be tested on public documentation; results from that example do not automatically apply to another collection. TypeSafe: classifying RAG passages cookbook ↗

Suppose an engineering team builds a general ventilation reference library. Search finds pages first. Jev then answers narrow questions: does a passage contain a maintenance procedure, state limitations or address a particular system category? Selected passages reach the local model with their source URLs.

An especially useful option is background preparation. Classify the public library against an approved general rubric before any employee asks a question. The employee’s live query never needs to leave the company; local retrieval uses the prepared attributes alongside its own index.

Private contracts, internal instructions, employee queries and their retrieved passages stay local. When those are necessary to judge relevance, use a local reranker or model. Sending private passages to an external reranker is still data transmission.

Jev can evaluate a published website page or text explicitly approved for external processing. Keep questions narrow: is the service clear, is there a next step, and does the page distinguish a feature description from a promised outcome?

The local model drafts improvements using internal positioning. Jev sees only the permitted public version and a general rubric. An editor makes the final decision; a score cannot replace product knowledge or factual verification.

Unpublished launches, budgets, customer segments and sales plans may remain commercially sensitive even if the final article will be public. A draft intended for publication is not automatically approved for disclosure to a provider.

A public catalogue may describe similar products inconsistently. Jev can suggest a category from a permitted list or assess semantic similarity between two public descriptions. Application rules then validate the proposal.

Only published names and specifications are needed. Stock levels, purchasing costs, supplier discounts, buying history and customer requirements stay out of the request. Mapping a public item to an internal identifier remains inside the company.

A high similarity score does not establish technical interchangeability. Dimensions, tolerances and mandatory requirements must be checked against the original specifications; a specialist reviews uncertain substitutions. The workflow prepares better catalogue information for a local model without delegating purchasing authority.

Create fully synthetic requests: asking for instructions, clarifying a deadline or checking compatibility. Jev proposes categories or rubric scores, which the team compares with human labels and the local model’s answers.

This can expose ambiguous instructions and help evaluate routing or prompt examples. Jev remains a second opinion, not ground truth. Humans label the control set; performance on real private cases is evaluated locally.

Synthetic must mean fictional. Replacing a name in a real complaint preserves its circumstances, amount and dispute. Uploading a conversation to an external service with an instruction to anonymise it has already disclosed the conversation.

A local agent can plan the task while Jev chooses among a bounded set of permitted links on a public site: manual, limitations or examples. Code executes only an allowed operation, and the local model reads the result.

Use a separate browser process without work logins or corporate tabs. Send only a restricted text representation of the approved page. A full desktop view, an authenticated account’s DOM, chat history or CRM fields are outside this scenario.

Jev 1.13 accepts text rather than images or audio. A screenshot or voice demonstration must use another component to prepare the text, whose data path also needs inspection. English is its main training language; Russian-language performance requires a separate evaluation. TypeSafe: model version, text input and language support ↗

Even a public form can send a message or place an order. A first pilot should therefore stick to reading documentation. Actions with consequences require their own permitted execution path and confirmation.

Consider a fictional request: a customer has delayed payment, wants an extension, and the contract contains an unusual clause. Replacing the customer name with CLIENT_17 still exposes the dispute and clause. An exact amount and date make the record more recognisable.

You could reduce it to a general question about classifying an extension request. But if preparation already determines the category, an external model contributes little. If the decision requires the actual disputed clause, keep the whole task local.

Reducing context sometimes creates a useful external subtask and sometimes destroys the meaning of the task. There is no need to force Jev into every workflow. Local processing can be simpler and more appropriate.

Embeddings, summaries and pseudonyms should not automatically be treated as safe substitutes. Assess what a recipient can learn from the entire package, including instructions, examples, option names and a sequence of requests.

For a pilot, we would propose a dedicated outbound gateway: the only application component permitted to contact Jev. It builds requests from allowed fields and sources rather than accepting a model’s assurance that a payload is safe.

• Store public material separately from private documents. A trusted process assigns permission; text on a page cannot assign that permission to itself.
• Restrict the request schema, field sizes and source types. Never attach conversation history, files or private records automatically.
• Check state, questions, criteria, examples and URLs. URLs can contain internal identifiers and service parameters.
• Use local secret detection as an additional barrier. Uncertain classification blocks transmission and selects local processing.
• Keep the API key out of model context. The model cannot expand the permitted fields, and alternative outbound paths must also be restricted.
• Record the policy version, operation identifier, size and validation outcome. Do not indiscriminately copy request bodies into external analytics.

These are proposed integration requirements, not built-in Jev features or a guarantee against leakage. Verify actual outgoing traffic, including retries, error handling and monitoring.

Choice and Score include confidence derived from the answer distribution. It is not independently established accuracy on your company’s tasks. Noul has no separate confidence field. Tune thresholds against labelled control examples. TypeSafe: confidence and probability distributions ↗

A confident public-article category can become a suggested tag. Equally confident tool selection does not authorise file deletion or a customer email. Code checks permissions and the allowed action independently.

Jev 1.13 documentation notes limitations with precise arithmetic, date comparisons, indirect reasoning and adversarial content. Keep calculations and access rules in code; an outside page must not become an instruction to an agent. TypeSafe: Jev 1.13 known failure modes ↗

Compare the same tasks with the local assistant alone and with Jev on the permitted external stage. Build human-labelled reference answers and include ambiguous cases and instructions planted in public text.

Measure final answer quality, useful-source retrieval, time to an accepted result, spending, large-model calls and human review effort. Also require no prohibited content in captured outgoing traffic. A fast API response alone is not evidence that the full workflow improved.

Test service outages. A timeout must not trigger a larger context upload or a switch to another external provider with full history. Continue locally, request human review or stop with a clear status.

At the time of checking, the documented version is jev-1.13.0. Pin a version for a reproducible pilot: a latest alias can change its answers after an update. Re-evaluate thresholds before switching. TypeSafe: model version, text input and language support ↗

The current AI Office prototype includes document workflows, retrieval with access controls, verifiable calculations and proposal approval before creating a local task. Jev integration, the proposed gateway and public browser-agent workflows are not implemented. They are possible extensions that require separate engineering and evaluation.

Our first candidate would be a public reference library. Jev helps classify approved open material against a general rubric, while the local AI combines selected sources with authorised internal context. Private documents are never sent out for selection, and Jev’s answers cannot unlock additional data.

A public catalogue or editorial workflow could follow. If a company permits no external calls, use a local classifier, reranker or deterministic rules for the same role. The division of work remains useful without Jev.

For AI Office, the value lies in controlled specialisation: one component writes and reasons, another provides narrow judgments, code enforces rules, and people approve consequential actions. Start with one public source, one rubric and a clear quality criterion. Evaluate that workflow before deciding whether the external assistant belongs in the company’s infrastructure.