A typed model answer can be perfectly valid and still send a customer into the wrong workflow. A coding agent can obey every rule in its host application while an external provider runs a different inner loop. A “local frontier model” can advertise sparse active parameters while its full weights exceed the machine's memory by an order of magnitude.

These sound like separate AI debates. They are the same engineering question: where does a proposed control actually take effect, and what observation would prove it worked?

I have been watching people collapse six different promises into one green badge: output format, semantic correctness, business authority, tool execution, observed outcome, and available compute. That is how a system can be well typed, confidently scored, apparently guarded, and still be wrong where it matters. The right move is to place a control at each boundary that can enforce it, then compare complete, accepted work across candidate designs.

A type narrows the answer; it does not define the job

Jev's official documentation describes a useful interface: provide state and atomic Choice, Score or Noul questions; receive structured values your code can use. Choice and Score expose probability distributions and a confidence statistic. Noul returns a value from zero to one without that confidence field. Jev is a decision component, not a text generator or a drop-in coding agent. TypeSafe explicitly recommends a generative model for text, code and tool use around it.

This removes a real failure mode: if a downstream program expects a fixed choice, it need not parse a free-form paragraph and hope the answer respects its schema. But a Choice is relative to the options and state we supplied. Suppose a customer says their refund was approved but the payment did not arrive. The available choices are approve_refund, deny_refund, and review_refund. A result can be perfectly typed and confidently choose among those three while the right next operation is to inspect settlement and payment-processor state. The option set omitted the actual job.

The design fix is more specific than “prompt it better.” Define outside_scope or needs_evidence as real paths, route them somewhere accountable, and test unknown cases that should take those paths. Keep the refund entitlement and money-moving permissions in deterministic code. Treat the model's output as a proposed semantic classification, not authorization.

TypeSafe's Jev 1.13 limitations page is unusually useful because it identifies concrete cases to isolate: weak counting and arithmetic, text-like treatment of dates, multi-hop indirection, degradation from irrelevant state, adversarial content, and structural identities that separate model questions need not preserve. Those are not arguments that Jev is worthless. They tell you which questions belong in ordinary code and which slices require an independent acceptance set. Its confidence guide says thresholds depend on the domain. A concentrated distribution is a statistic of the options, not proof that the options were complete or that the selected action is permitted.

The same limit applies to constrained decoding with a general model. vLLM documents choices, JSON schemas, regular expressions and grammars as output constraints. These can eliminate malformed syntax at generation time. A schema that forces {"approved": true} does not establish what “approved” means in the business system. Grammar belongs at the decoder; policy belongs at the action boundary and with a named owner.

The certainty ladder from prompt to action

Where the runtime exposes token sampling, you can go further than asking politely for JSON. XGrammar's engine-integration guide shows a grammar matcher calculating a valid-next-token bitmask at each generation step. Applying that mask sets illegal token logits to negative infinity before sampling. That is a real format constraint for the grammar and tokenizer being used. By comparison, parsing a finished response and retrying on error detects malformed output after a generation; a prompt instruction merely influences it. A hosted API may expose a structured-output mode without exposing custom logits or masks, so verify the actual contract of that provider and version.

The useful design question is therefore not “which one guardrail do we need?” It is “which claim is this guard actually capable of proving?”

A recent label-swap preprint reports that some studied typed decisions change when polarity-bearing option names change despite zero format errors. It is a bounded experimental result, not a universal Jev failure rate. It suggests a cheap local probe: keep the case and written criteria constant, rename the options to neutral identifiers, and compare the resulting business branch. If the branch changes, investigate before promotion.

The model comparison must end at an accepted answer

Jev's vendor introduction reports fast model-call latency. That metric may matter greatly in an application that needs only a bounded decision. It can mislead when the user needs a complete answer. Consider the settlement complaint above:

The winner cannot be read from one isolated model timer or a generic leaderboard. Run the same held-out, independently labeled cases through all candidate paths. Count input preparation, network, generation, verification, retries, human review, final accepted answer and the wrong-branch cost. Record end-to-end p50 and p95, accepted-answer rate by slice, total money spent, escalation rate and operator recovery time. If the supposed fast path produces an extra explanation call and a manual queue, that cost is part of its performance.

Anthropic calls Haiku 4.5 its fastest tier. Qwen publishes small open-weight Qwen3 variants and a non-thinking mode. Neither source proves Haiku or Qwen beats Jev on the user's workflow. A local Qwen on a shop-floor gateway could avoid a remote round trip and keep plant data within a boundary; it could also lose badly on unfamiliar language or concurrency. Specify which Qwen weights, quantization, hardware and runtime, measure warm and cold performance, and include an out-of-scope route. “Small” is a system design hypothesis, not a benchmark result.

A hook cannot govern a loop it cannot intercept

The Avid Jev-harness build narrative is useful as an architecture example precisely because it draws a limit: the host can decide how to route a fresh task, while external coding providers retain their own tool loops. Its decision receipts are not a demonstrated coding-quality gain or a self-training system. I would not import its third-party scripts to make this point.

Before promising that a hook “enforces” agent behavior, draw an authority map for every runtime in use. At each boundary ask: who sees the request, who can deny it, what happens when denied, can another route bypass that point, and which independent state can we read afterward? A PreToolUse hook can be strong where the harness actually invokes it. A markdown instruction is an influence. A command wrapper or service permission can enforce at a different layer. An external provider's inner tools need their own observable gate or a narrower credential and sandbox. The test is an actual harmless denied action through each route, followed by a readback proving the effect did not occur.

Routing also has a time-of-check/time-of-use problem. An automatic selector can choose a tool bundle under policy version one; the tool definition, permission, availability or user's explicit route can change before dispatch. Bind the proposal to a versioned eligibility snapshot. Revalidate the selected route, schema and authority at the last host-owned dispatch point. If the fingerprint is stale, stop or take a visible owner-approved fallback. A resumed session or explicitly pinned provider should bypass automatic reselection by enforceable code, not by a hopeful prompt.

The boundary is tangible in agent frameworks. The OpenAI Agents SDK handoff docs describe a handoff as a transfer to a registered agent, with optional input filters; tool input guardrails apply to function tools, not the handoff itself. They advise checking authorization in on_handoff before side effects. That is exactly the sort of per-surface behavior a team must inspect in its actual harness instead of assuming a global rule catches everything.

Inject a packet, not the organization's entire memory

A second failure mode is missing information. RAG can retrieve the closest text and still miss the one exception a domain owner knows changes this case. Dumping every past agent conversation into the worker also fails: irrelevant history can hide the decisive fact, and the worker may treat a fluent summary as if it were policy.

I prefer a role-held context pattern for high-value boundaries. A specialist agent has durable responsibility for a domain and a small, versioned memory. At the point of decision it sends the worker a decision packet: the current rule and source, the exact case facts used, unresolved exceptions, age/version, proposed action, and what independent readback would show success. The worker receives only the packet needed for this decision. The host checks provenance and expiration; a protected test plants a case where naive retrieval omits an exception. A person owns the policy itself. This is context injection with an explicit verification contract, not a belief that a second agent becomes an oracle.

This also protects the scarce resource: human attention. If four agents can prepare four plausible decisions per minute but one engineer can review only one, the organization has a growing liability queue. Add agents only when the accepted-work rate rises after review and rework. A decision log is useful for replay, but it does not teach a router that a new policy works; version the routing change, compare on protected holdouts, and keep rollback possible.

Sparse activation is not a Mac mini deployment plan

Hardware is another place where the control surface is physical. Moonshot's Kimi K3 model card lists 2.8 trillion total parameters and 104 billion activated parameters per token, with MXFP4 weights. A bare four-bit calculation is 2.8 trillion × 0.5 bytes = 1.4 trillion bytes, about 1.4 TB decimal before overhead, caches, activations, runtime and serving headroom. Apple's current Mac mini technical specifications list a configuration up to 64 GB unified memory. The full K3 model plainly cannot reside in that memory. The 104B active figure describes conditional computation, not the full weight store. Disk offload is technically a different question, with throughput that must be measured; it is not a credible basis for a frontier-speed claim without a real benchmark.

Moonshot's technical article recommends supernode configurations of 64 or more accelerators for efficient inference. That is the vendor's architecture recommendation, not evidence that every deployment requires exactly 64. For local work, choose a genuinely small model that fits and test its accepted throughput. For K3-level work, compare an API or suitable accelerator service. The architecture decision depends on the actual workload, latency and total cost, not the emotional appeal of “open weights on my desk.”

Ten probes before committing to the architecture

These are proposed experiments, not results I claim to have run on Eric's production systems. Each is small enough to stage on a disposable copy or harmless route, with an expected observation set before the model is asked to judge itself.

1. Freeze a consent-safe case set with routine, rare, multilingual, adversarial and missing-state examples. Have a business owner label the expected outcome, not merely the output format.
2. On a fixed Jev build, compare schema validity with semantic correctness as distinct columns; include cases whose correct action is outside_scope.
3. Rename Choice options to neutral identifiers without changing the written criteria. Examine branch changes case by case.
4. Compare deterministic rules, Jev-plus-writer, Haiku and one named local Qwen build on the exact same case set. Measure end-to-end p50/p95, accepted answers, retries, review and total cost.
5. Run the local build on the intended gateway at warm start, cold start and realistic concurrency; include missing network and unusual language.
6. Through every host/provider route, attempt a harmless forbidden tool action and read the target state independently to prove denial.
7. Pin a human provider, resume a prior session, and launch a fresh unpinned task. Verify automatic routing touches only the eligible fresh task.
8. Change a harmless tool schema or permission between selection and dispatch. Verify the stale fingerprint blocks or visibly falls back before side effects.
9. Give a specialist role one documented policy exception; let the ordinary retriever miss it. Verify the packet contains the source/version and that a protected outcome test catches the wrong branch.
10. Replay a decision receipt under a changed policy version against untouched holdouts, including review queue time and rollback. Promote only with an accountable owner's decision.

No single experiment proves universal correctness. Together they discriminate a format guarantee from a business result and expose the enforcement layer you actually own.

My rule: put format constraints in the decoder, business authority in code with a named owner, action limits at the tool or service boundary, evidence outside the worker, and the workload on hardware that fits. Choose the route that delivers the most accepted end-to-end work under those controls.

The field kit

The companion folder for this week holds runnable examples, decision records, evidence and limits. The repository release log is updated after each article's live readback.