Build a Jev harness you can inspect

An agent proposes a refund. Before it runs, your system needs to answer several different questions. Does the request concern a duplicate charge? Does the customer own the account? Is the refund allowed under your policy? Has this exact refund already been issued?

Those questions should not all be delegated to the same component. Account ownership comes from authentication. Duplicate execution comes from transaction state. Refund limits come from policy. A model can help interpret the customer's description.

That separation is where a useful Jev harness begins.

LangChain's introduction to building a harness with Jev describes using typed decisions inside an agent loop. This guide extends that idea into an application design: every decision should have a source, a scope, and a recorded consequence.

Give the model a bounded job

Start with a specific ambiguity. For example: does a message explicitly report a duplicate charge? This is narrower than asking whether a refund should happen. It also gives you a labeling task that another person can understand.

The current LangChain integration exposes TypeSafeClassifier and typed question constructors. An illustrative call is:

from langchain_typesafe import Noul, TypeSafeClassifier

classifier = TypeSafeClassifier(
    questions={
        "reports_duplicate_charge": Noul(
            instructions=(
                "The customer explicitly reports being charged more than once "
                "for the same purchase. A pending payment alone is not enough."
            )
        ),
    }
)

response = classifier.invoke({
    "customer_message": "Two completed charges appeared for my one order.",
})
probability = response.nouls["reports_duplicate_charge"].noul
print(probability)

Install langchain-typesafe and configure TYPESAFE_API_KEY before running it. This snippet follows the documentation and has been syntax-checked; it has not been run against the hosted API for this article. There is deliberately no invented output beneath it.

That probability is evidence for a triage decision. It does not establish that two charges actually settled. Fetch the payment records to answer that.

Make the harness five explicit steps

Collect facts. Build a small state object from the request and trusted systems. Preserve whether a field came from a customer message, a database, or an agent's suggestion. Do not put credentials in the model input.

Check eligibility. Reject actions outside the authenticated user's scope. Enforce known limits in code. The model should not be able to reinterpret a forbidden action into an authorized one.

Classify ambiguity. Ask the focused question. Apply a timeout and validate the returned type and range. A missing or malformed answer is an unavailable decision, not a probability of zero.

Apply policy. Decide whether to route automatically, request review, or gather more evidence. Name and version this policy separately from the model. Reviewers need to distinguish “the model changed” from “the operating threshold changed.”

Execute once. Bind approval to the exact action arguments and relevant state revision. If the target or amount changes, reassess. Use an idempotency key so retries cannot create a second refund.

Review is a state, not an error message

LangChain's experimental AutoModeMiddleware can block selected tool calls. Its documentation explicitly distinguishes blocking from human approval. A review workflow needs its own durable state: pending, approved, rejected, expired, and superseded.

When a reviewer approves a proposed action, save what they approved. Recheck prerequisites immediately before execution. A decision made against yesterday's balance is not authorization to act against today's balance.

The companion policy example demonstrates one small part of this arrangement. It validates probability inputs, requires an evaluated policy, and sends ineligible or unavailable decisions to review. It cannot grant access or execute a tool.

Record enough to reproduce the branch

A useful trace contains the input digest, model identity, question revision, raw answer, policy revision, selected branch, and eventual outcome. Store sensitive source material only under the application's access and retention controls. Public analytics should receive aggregate events rather than customer messages.

Before rollout, replay a labeled set through the complete harness. Count missed cases, unnecessary reviews, timeouts, repeated execution attempts, and stale approvals. Then run in shadow mode alongside the existing workflow.

A fast classifier can make this architecture practical. The harness earns trust by making each resulting action explainable and recoverable.

Jev is a TypeSafe AI model. This independent JevLM guide describes a proposed application pattern, not a benchmark or a claim that our local model is Jev.