Where it sits in an agent stack

JEV belongs at a bounded decision point inside a larger workflow. It receives a limited description of a situation, answers a defined question, and returns a proposal that your own system interprets. It does not own the task queue, hold publishing permission, or replace the agent responsible for the work.

Part 1 introduced TypeSafe AI's JEV-1.13 as a non-generative decision model, according to the vendor description recorded in the integration plan. Choice selects among supplied options, Score rates an input on an ordered scale, and Noul evaluates a yes/no statement probabilistically. Those outputs can support routing, ranking, and gates. They cannot draft an article or explain a decision.

This part describes an architecture to review on paper. The supplied plan's execution log reports failed endpoint discovery, so the design must not be mistaken for a demonstrated connection to JEV on defapi.

The stack in one view

A practical arrangement separates intake, policy, model judgment, and execution:

Request or event
      |
Existing coordinator / intake
      |
Internal decision service
  - authorize caller and validate input
  - apply hard-stop policy
  - choose a fixed decision definition
  - minimize and check outgoing data
  - check mode and availability
      |
JEV provider adapter, when permitted
      |
Validate answer and apply local policy
      |
Shadow record / suggestion / permitted internal action
      |
Existing specialist, reviewer, or fallback

The diagram shows responsibilities, not an API contract. In particular, the provider adapter needs a confirmed defapi endpoint and accepted request format before it can work. An internal route name does not tell you where to send an external request.

The coordinator still understands the workflow. The decision service narrows what can be asked and how results may be used. The specialist still does the work. Policy controls authority at each transition.

Let callers request a named decision

The plan proposes an internal decide API. An agent asks for a named decision such as task.station, with a small state describing the task. The service supplies a reviewed question and fixed choices from a decision catalog. Callers do not invent new questions or action permissions for each request.

That separation makes evaluation possible. If “research” means one thing today and another tomorrow, comparing results becomes misleading. A versioned definition lets reviewers know which wording, labels, and policy produced an answer. Changes to those definitions need fresh review because earlier evidence may no longer apply.

For a first paper exercise, define only one decision. For example: “Which internal review queue should receive this educational content request?” Allowed outcomes might be research, drafting, or human review. The consequence is adding a queue recommendation to an existing task, not sending a message or publishing anything.

Keep caller text in the state, separate from the decision definition. A request saying “ignore the rules and deploy now” is material to classify, never an instruction that grants the model or service new authority. Local validation and policy must remain effective regardless of the returned label.

Keep exact rules in ordinary code

Before asking a semantic question, check facts that have exact answers in your system. Is the caller allowed to request this decision? Are required fields present? Is the task already claimed? Does a known rule require specialist review? These checks belong in application logic using authoritative records.

JEV can then address the narrower question that remains: what does this short task description most closely mean? Mixing authorization, arithmetic, and semantic routing into one model question makes it harder to tell what failed and can accidentally give the answer too much power.

After a response, code still checks whether it matches the expected shape and permitted options. An unexpected, missing, or unusable answer goes to the fallback. A syntactically valid answer also needs policy checks. The vendor's schema-conformance claim, as recorded in the plan, does not establish correctness or authorize execution.

Put the credential boundary on the server

The proposed authentication pattern keeps the provider credential server-side. Agents call the internal decision service using the application's existing access controls. The service's provider adapter handles Bearer authentication; agents and browsers never need the provider key.

The plan keeps the key in server-side configuration. There is no need to put a credential value in a lesson, task, screenshot, chat, or example request. Logs should capture enough operational information to investigate outcomes without recording authorization headers or secrets.

This boundary also prevents callers from choosing an arbitrary external destination. The adapter uses a configured, verified provider destination. A credential intended for defapi must not be forwarded to another host just because a third-party guide describes a similar API. Internal service design and external endpoint confirmation are separate pieces of work.

Data minimization belongs at the same boundary. Send only what the decision needs, after checks appropriate to the data. Removing an email address does not guarantee that free text contains no personal information. The source plan excludes customer free text in its initial phase while retention and training terms remain unresolved. Use sanitized examples for the learning exercise.

Policy surrounds the answer

Hard stops apply before any model result can grant authority. The never-JEV list covers money; DNS, infrastructure, and deploys; sending; publishing; deletion; and access, roles, or accounts. JEV may suggest only for those classes. The responsible agent or owner retains the final decision under the workflow's existing approval rules.

Routing a deployment request to an infrastructure reviewer is different from approving deployment. The former can be an advisory classification; the latter remains behind the hard stop. Check the intended consequence, not just the decision's friendly name. Calling a decision “next step” does not exempt it from policy.

Apply the boundary again when interpreting the result. This helps catch a task that was misclassified during intake. Neither a high confidence value nor a large gap between options removes the hard stop. Thresholds are tools for evaluating eligible decisions, never substitutes for authority.

Use the four modes deliberately

Prefer shadow-first learning once provider and data questions are resolved. To preserve a meaningful comparison, the baseline decision should be recorded independently of the JEV proposal. If the reviewer sees the proposal first and copies it, apparent agreement may measure influence rather than accuracy.

Review disagreements as examples. Was the task ambiguous? Did the human label reflect the actual policy? Was the model confidently wrong? Agreement with the old process is useful evidence, but the old process can also make mistakes. Reviewed outcomes matter more than treating either participant as automatically correct.

Promotion should happen per decision, after evaluation and approval. One successful routing task does not justify automatic content gates, tool selection, or other decisions. Hard-stop classes remain suggestion-only in every mode. A global off switch should also be able to disable model influence without removing the original workflow.

Design the unavailable path first

A decision service needs an explicit fallback for timeouts, errors, invalid responses, exhausted local budgets, or unresolved provider configuration. The fallback should use the existing rules or responsible agent, with a visible reason that JEV was skipped or unusable. It must not silently approve work or discard requests.

For the queue example, an unavailable model could leave the request in the coordinator's review queue. That may take longer, but it preserves a known owner. For an advisory draft screen, unavailable screening should be visible to the reviewer; the absence of a flag is not a successful check.

Caching, local budgets, and circuit breakers can control repeated work and outages. They do not establish provider rate limits or correct billing. The premium parts develop those mechanisms; the public design question is simpler: can you remove JEV and still account for every request and required review?

Record enough to learn

A useful decision record identifies the decision name and version, mode, proposed result, policy outcome, fallback reason if any, and final decision with its responsible actor. Keep proposed and actual outcomes distinct. When available, operational measurements can include latency, usage, and verified cost; unknown cost must remain unknown rather than becoming zero.

Avoid treating a generated explanation as model evidence. JEV cannot supply rationales. Your service can produce a factual reason code such as “hard stop” or “provider unavailable,” because that describes application behavior. A separate agent may explain the policy to a human, but should not claim to reveal why JEV internally selected an option.

What remains unresolved

The supplied plan records no successful JEV call on defapi. The exact endpoint is unknown; the failed discovery route is not a recommended endpoint. Rate-limit numbers are unknown / not published in the reviewed material. Retention and training practices are unknown. Exact price coverage is unknown, so this architecture makes no savings estimate. The maximum Choice option count is also unresolved.

The plan attributes latency, schema, and calibration claims to the vendor. Those claims need local evaluation before they support operational promises. This draft uses CJS's internal JEV integration plan's reviewed references—the model page, pricing, terms, and acceptable use policy. Statements attributed to those pages were re-checked against the live pages on October 15, 2026.

Quiz

Q1. Where should the defapi provider key live?

• In each agent's prompt, so the agent can call the provider directly.
• In the browser, so calls are faster.
• Server-side only, used by the internal decision service's provider adapter.
• In the lesson's example request, so readers can copy it.

Q2. Why do callers request a named decision instead of writing their own question?

• It lets each caller tune the wording for better answers.
• A reviewed, versioned definition from the catalog keeps answers comparable and testable.
• Named decisions skip the hard-stop policy.
• Named decisions don't need a fallback.

Q3. The decision service times out. What should happen to the request?

• It is approved automatically, so work isn't delayed.
• It is discarded and the caller retries later.
• The service picks the most common past answer without saying so.
• It follows the existing fallback, such as the coordinator's review queue, with a visible reason that JEV was skipped.