The schema is green. The action is wrong.
An AI answer can be impossible to parse incorrectly and still be the wrong instruction to execute. The more confidently a team talks about “constrained” models, the more I want to see the boundary where the constraint acts. Is it a sentence in a prompt? A mask on the sampler's next token? A typed decision over a fixed set? A validator over the complete record? A service permission? Or a readback of the thing the user actually cared about?
Those are different mechanisms. Each can be valuable. They do not add up to certainty merely because the final screen is green.
This is a deeper follow-up to my earlier field note on Jev and whole-path model economics. There I argued that a typed model decision and a small generative model should be compared on accepted end-to-end work, including retries, review and wrong-branch cost. Here I want to locate the actual enforcement points. The model can own a narrow judgment; software must still own eligibility, authority and evidence of effect.
A valid answer can propose a forbidden action
Consider a fictional enterprise account workflow. A customer asks an agent to send an export of audit evidence to an external partner. The model returns this perfectly valid structured result:
{"route":"share","reason":"Customer requested partner delivery"}
The JSON schema permits exactly `share`, `review` and `decline`. The response parses. It uses the right keys and enum. The application then discovers that the customer contract has a signed amendment: external transfer is suspended until a named data-processing review is complete. The model may never have seen the amendment. Even if it did, a fluent reason is not a transfer permit.
This is a system design problem, not an exotic model hallucination. If the model decides the route from an incomplete case packet, the grammar has done its job while the workflow has failed. If the permission check happened before a policy update and the action happens after, the system has a stale-authorization problem. If the transfer call returns success but no recipient-side record exists, it has an observation problem. Each failure lives at a different boundary.
The right implementation does not ask a model to be an invisible compliance department. It gives the model a bounded semantic question, verifies case evidence, checks a current authoritative record at dispatch, uses a credential limited to the allowed operation, and reads back the resulting state. The owner of the policy is a person or governed business process, not the model's prose.
What a token mask actually buys
XGrammar's engine integration documentation gives a concrete view of constrained decoding. A grammar matcher computes which tokens can legally come next. The engine applies that bitmask to the logits, setting invalid-token logits to negative infinity before sampling, then advances the matcher with the chosen token. In that configured inference path, invalid continuations are prevented at generation time. This is stronger than telling a model “please output JSON” and stronger than discovering malformed JSON only after generation.
The details matter. The tokenizer, grammar compiler, matcher state, engine path and stop handling are part of the claim. A self-hosted runtime such as vLLM exposes structured-output modes including choices, schemas, regular expressions and grammars, with backend and feature constraints. That does not imply every hosted API gives an application arbitrary access to internal logits. OpenAI's current Structured Outputs guide exposes a supported schema contract, distinguishes it from JSON-only mode, and documents refusals and incomplete responses that the caller must handle. The provider owns its sampler; the application gets the public API contract.
Nor does a grammar make the content correct. Both `{"route":"share"}` and `{"route":"review"}` can be legal strings. No token mask knows which contract amendment is current unless a separate authority has supplied and enforced that fact. A schema may include an `evidence_id` string, but a syntactically valid ID is not proof that the evidence exists, is current, or supports this action.
I think of decoder control as a form guarantee at a particular inference boundary. Useful, precise and much narrower than “the AI cannot be wrong.”
Jev's confidence is not outcome calibration
TypeSafe's Jev interface asks for state and atomic Choice, Score or Noul questions. A Choice offers a distribution across the developer's listed options; its confidence documentation describes the confidence field as a statistic derived from that distribution. Noul does not carry that confidence field. This is an honest and useful surface for a decision component.
The dangerous leap is to read a concentrated distribution as observed correctness. It tells us how the model distributed probability over the options we gave it, for the state we gave it. If “wait for the signed amendment” is missing from the list, a decisive answer among the remaining routes is still a bad branch. If an amendment arrived after the state snapshot, the model's input is stale. If the business owner changed the meaning of `share`, the same enum can route to a different effect.
The vendor's Jev 1.13 limitations are unusually practical: it recommends code for arithmetic and date comparisons, warns about multi-hop indirection, irrelevant state and adversarial content, and says separate questions need not preserve structural identities. Those facts argue for small, literal questions and independent outcome tests. A recent label-swap preprint reports decision changes under polarity-bearing option names on its studied cases despite zero type errors. That is a bounded research result, not a universal Jev failure rate. It supplies an inexpensive local experiment: rename options to neutral IDs while holding the case and written criteria fixed, then inspect whether the business branch changes.
Calibration needs a protected set of cases with independently adjudicated outcomes. For each slice that matters, compare the model's stated probability or confidence bucket with observed correctness and cost. An unknown or out-of-scope case must have a real route. No confidence threshold is meaningful if the option set excludes the correct operation. And a threshold should control escalation; it should not mint a transfer permit.
The ladder of enforcement
| Layer | What it can enforce at its boundary | What remains unproved |
|---|---|---|
| Prompt or `AGENTS.md` | Influence a model's proposal | That every tool path obeyed it |
| Grammar or token mask | Supported output form as sampled | Correct branch, complete facts, authority |
| Parser and semantic validator | Reject missing fields, incompatible values, stale evidence IDs | That a policy owner actually permitted the effect |
| Current authorization check | Deny a disallowed operation for a principal, object and policy version | That the external operation succeeded |
| Scoped service credential | Limit what a compromised or mistaken caller can request | That a permitted request was wise |
| Independent readback | Observe persisted target state and reconcile it to the request | General correctness of future cases |
The order matters. A post-generation validator is still valuable even with constrained decoding, because refusals, truncation, backend differences and transport errors need explicit handling. The semantic validator should bind a proposed route to a specific source version and evidence record. The authorization check should run at the last point the host owns before side effects, with a current policy snapshot. A permit should be narrow in customer, recipient, operation and expiry. If a provider's private agent loop can call tools outside that host boundary, put the limit at a service it cannot bypass; do not claim a `PreToolUse` hook covers an inner loop it never sees.
The external transfer case needs another choice: when one layer cannot verify its prerequisite, does the workflow stop visibly, ask for evidence, or take a separately authorized fallback? Silent success-shaped continuation is the failure mode.
The fallback route is part of the grammar claim
The configured primary decoder is not the whole service. XGrammar describes mask computation, application, token acceptance and, in speculative decoding, rollback after a rejected draft suffix. That gives an integration team more than a final JSON string to test: it can inspect which tokens were accepted, whether matcher state advanced with them, and whether a rejected speculative branch was actually rolled back. This is an engine test proposal, not an allegation that a named runtime has a rollback defect.
Now inject a primary-route timeout. Does the retry use the same grammar and schema version? Does it move to a different vLLM structured-output backend, a provider's strict-schema API, or prompt-only formatting? A successful parse of the retry cannot prove that the original token-mask guarantee applied. I would attach a route receipt to every answer: endpoint and backend version, grammar or schema version, constraint mode, response state and fallback reason. If a verified constraint is unavailable, return an explicit unavailable state or a separately validated fallback. The public OpenAI Structured Outputs contract also makes refusal and incomplete responses first-class caller concerns; neither should be coerced into an approval-shaped default.
Price the completed decision, not the first model call
Typed decision models and small generative models can be compared only after defining the same accepted deliverable. Jev returns typed Choice, Score or Noul judgments rather than a customer-ready paragraph. Anthropic's model guidance and Qwen's model repository describe different generative deployment options; those documents do not determine which route is faster or cheaper for this workflow. If the product needs both a route and an explanation, a Jev path may need a writer and a consistency check. A small generative path may produce both in one call and still need its own semantic check. Neither architecture wins by definition.
I would run a matched, owner-labeled case set through a deterministic rule, a typed-decision-plus-writer route, a named small hosted generator and a named local generator on specified hardware. Measure cost and p95 time until the exact answer is accepted, including network, cold starts, concurrency, retries, reviewer minutes and reopened cases. Keep a separate harm-weighted line for a wrong branch that slipped through acceptance. Jev's published limitations make numeric comparisons, indirection and irrelevant state explicit case slices, not footnotes. The result is a workload-specific route frontier, not a universal model ranking.
A handoff transfers work; the service still decides authority
An agent-to-agent handoff can pass an excellent summary and still lose the authorization boundary. The OpenAI Agents SDK handoff documentation distinguishes input filtering and handoff callbacks; it explicitly places checks on parsed handoff fields before side effects and notes that tool-input guardrails do not cover handoffs. Its context guide separates application-local state from model-visible text and says protected operations must be authorized in their own implementations. Those are useful control surfaces, but a message from an intake agent is not a permit for a publishing or transfer agent to use a broad service credential.
For a consequential effect, bind the approved artifact version, acting identity, owner or subject, operation, recipient and expiry to a permit the target service verifies. RFC 8693 defines token-exchange semantics for delegation and impersonation, including actor, audience and scope concepts; it is one possible identity-stack mechanism where supported, not a plug-in guarantee for agent frameworks. In a safe canary, prove an authorized delegate can act once, then change the object after handoff, expire the permit, retry and use an alternate tool. Require service denial and no target-state change on each forbidden path. That test asks the world whether authority survived the handoff exactly.
Ten small experiments before believing the architecture
These are proposed probes, not claims that Eric's production services were tested.
- Feed the same fictional cases through prompt-only JSON, strict hosted schema mode and a named self-hosted grammar backend. Count malformed, refused, incomplete and valid-but-wrong outcomes separately.
- In a disposable local decoder, deliberately remove the grammar mask on one generation path, force a retry through a fallback, and reject a speculative draft suffix. Verify the test detects the lost constraint, records the fallback route and checks matcher rollback; a parser-only check is insufficient.
- Change the schema so the correct out-of-scope route is absent. Measure confidently wrong in-schema answers.
- Present Jev with neutral option IDs, then polarity-bearing names, with identical criteria. Compare the business branch on protected cases.
- Calibrate confidence by case slice and consequence, using independently labeled outcomes. Include missing amendment, stale amendment, conflicting source and unfamiliar language. Compare the full accepted-work cost of typed-decision-plus-writer and named small generative routes on those same cases.
- Supply a syntactically valid but nonexistent or expired `evidence_id`. The semantic validator must reject it before authorization.
- Update the signed policy record between model choice and dispatch. The last host-owned check must reject the stale proposal and log the reason.
- Use a disposable canary sink that records a receipt when called. First prove an authorized control produces a receipt; then try an out-of-scope transfer through direct tools, a delegated agent handoff and an alternate provider route. Change the approved object and expire the permit. The service must prevent any new receipt even when a hook does not run. Keep traces plus external readback; use no production credentials.
- Simulate an API timeout after a transfer request. The workflow must distinguish `UNKNOWN` from `FAILED`, reconcile by idempotency key or target readback, and avoid a blind retry.
- Check the recipient-side record, not just the sender's “success” text. An owner reviews mismatches and defines rollback or containment.
The experiments should run on synthetic, consent-safe data and a disposable target. The companion code for this issue is intentionally narrower: it validates a fictional proposal, source digest, current policy version, scope and expiry without calling a model or transfer service. It is a demonstrator for one host-owned gate, not a product authorization system.
The rule
Use a token mask when you need to make malformed output impossible in a runtime you control or through a provider contract you have verified. Use held-out outcome tests and a semantic validator to decide whether a valid answer is useful. Use current service authorization and narrow credentials to prevent unauthorized effects. Use independent readback to learn what happened.
The sound bite is simple: constrain the form where tokens are sampled, constrain authority where actions happen, and verify the result where the world changes. None of those controls can substitute for the others.
The approved daily written reads are available in this journal; social and video links are added only after public readback. The public Week 11 engineering field-notes companion contains a synthetic host gate, two owner-labeled fixtures, ten local tests and ten proposed probes. This article and public overview claim no production transfer, Jev benchmark or live model comparison.
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.