A Jev-first strategy: start with decisions, not chat

Chat assistants earned their place. They help people draft, summarise and find things. But ask a board what the organisation got for its Copilot or ChatGPT seats and the answers are usually survey scores and anecdotes. The value is spread across thousands of individual moments that nobody records. The cost is fixed per seat whether anyone uses it or not. The risk sits in whatever a person does next with a paragraph of generated text.

That is a hard base to scale from. You can't put a paragraph of prose into a control framework, and you can't easily measure its effect on a process.

What Jev-first means

A Jev-first strategy puts the operational decision at the centre instead of the conversation. It asks where work gets sorted, scored or checked by hand today, or sampled because reading every item costs too much. Then it answers each of those judgments with a small, typed model call.

Jev, TypeSafe's decision model in the System One category, answers one bounded question at a time. A Choice picks one option from a set you define. A Score places an item on a scale you describe. A Noul gives the probability that a stated condition holds. Each answer comes with a probability. It does not write replies or explain itself, and that is the point.

Around that call sit three other layers, each with one job:

• Rules in code handle anything you can write down: amounts, dates, allowlists, timescales.
• Jev handles the judgments rules can't express, such as which team a message belongs to or how severe a complaint reads.
• A frontier model is called only where text has to be written or the reasoning is open-ended, and only after policy decides it's warranted.
• A person keeps every action that is costly, irreversible or legally significant.

Why it changes cost, risk and explainability

Cost follows difficulty. Rules are nearly free, so they go first. Bounded judgments are cheap enough to run on every item. That filters the workload so the expensive layers, frontier reasoning and human attention, only see the cases that need them. The next article covers how to budget the whole path.

Risk is set in code. The model never decides what happens. Your policy reads a typed answer and a probability, then applies two tests: does the confidence clear the threshold set for this action, and can the action be undone without harm? Anything that fails either test goes to a person. The list of things the system can do is written down and finite.

Every decision leaves a record. Each record holds the evidence sent, the question version, the answer and its probability, the policy rule that fired and what the person did afterwards. That is more useful to an auditor than a model's account of its own reasoning.

What it looks like in an organisation

1. Inventory decisions, not use cases. Walk the high-volume processes and list the points where someone reads an item and sorts, scores or flags it. Note the ones that are sampled today.
2. Pick one decision with an owner. Good first candidates have stable categories, a reversible first action, labelled history and a manager who owns the queue. Twenty worked examples are in the use-case library.
3. Build one decision service in your tenant. A small adapter validates inputs, calls Jev with pinned model and question versions, checks the response and applies policy. Everything except the Jev call itself runs in your Microsoft estate.
4. Shadow before authority. Run alongside the current process, compare against three baselines and agree a stop rule before any routing is automated.
5. Reuse the service. The second decision reuses the adapter, the evaluation method and the governance. It should cost less than the first.
6. Keep chat for what it's good at. Copilot stays on desks for drafting and thinking. It just stops being the thing you expect to scale operations.

What it is not

It isn't a replacement for Copilot, and it isn't autonomous agents. It won't help with decisions that are hard for experienced people too, or with categories that change every week. It isn't a route to approving payments, selecting employees, diagnosing people or applying sanctions. Those stay out of scope until a bounded pilot has earned the evidence, and some should stay out for good.

It also fails in predictable ways. If the evidence a decision needs isn't available in text, a clearer question won't fix it. If nobody will label a few hundred historical cases, you can't set a threshold honestly. If no one owns the queue, no one will act on the results.

Five questions for the board

1. Which single decision are we piloting, and who owns it?
2. What is the answer allowed to trigger, and what is it never allowed to trigger?
3. What are we comparing against: current manual handling, existing rules, or both?
4. What result stops the pilot?
5. What does the decision record contain, and who reviews it?