The Decision Model That Won by Saying What It Isn't Is Erasing Its Own Boundary

When writing business code or building agent loops, developers frequently run into high-frequency branching decisions: intent routing, state classification, risk scoring, and tool selection. Calling an auto-regressive large model that generates tokens one by one for every lightweight check like this brings high latency, high per-output-token costs, and the constant risk of out-of-bounds output formatting.

Decision models target this exact engineering pain point. The caller explicitly declares a set of typed questions or a candidate space; instead of generating free text, the model runs a single forward pass and directly returns option probabilities, scores, or typed values. Backed by a negative manifesto of “what I am not,” decision models like TypeSafe’s Jev quickly carved out a niche in the gaps between general-purpose large models.

Yet barely had the category found its footing when the shift began. Jev, the first to turn this interface into a commercial API, along with the products that followed, started packing new types into what was originally a minimalist interface: box for locating objects in images, text and date for extracting fields from documents, estimate for estimating probability distributions over continuous values, forecast for multi-step time-series prediction, and even refusal, the abstention channel deliberately excluded at the start.

Many developers see this as a natural expansion of product features, but on the scale of category definition, it points in the opposite direction. For a species built on negative boundaries, every new type added to the interface erases one of the “what I am not” lines originally drawn to define its circle. Once that circle is wiped clean, a distinct category that had just gained recognition degenerates into a general-purpose structured output layer.

It Won by Saying “What I Am Not”

Only by seeing how a technical category first caught fire in marketing can we understand what it later lost in expansion. For engineers calling APIs in business code every day, a new model that only pitches positive features struggles to stand apart from the existing LLM toolchain, let alone establish a new category in a short time.

Imagine if these models had launched with the positive slogan “I can output decisions.” It would have barely made a ripple in the market. Nearly every general-purpose LLM today, paired with structured outputs, JSON mode, or function calling, can return classification labels or Boolean judgments in whatever format the caller specifies. Positively claiming to “make decisions” creates no engineering differentiation.

What actually tore open a gap in the market was a crisp negative manifesto. Take the earliest example, Jev: in its launch blog post and primitives documentation, it repeatedly emphasized four “nots” to developers: I am not an auto-regressive model; I am not a slow-thinking System 2 model; I do not need time-consuming, compute-heavy deep reasoning; and I do not generate free text, attach explanations, or provide a refusal channel—I only choose from the candidate options you provide.

This negative positioning worked because it used the industry backdrop as a foil. At the time, nearly every mainstream large model on the market followed the auto-regressive generation path, competing on long-chain System 2 slow thinking and defaulting to paragraphs of natural language text. When every player is stacking capabilities in the same direction, positive claims about “what I can do” easily drown in the noise; declaring “what I am not” in rapid succession immediately drew a highly recognizable circle in a homogenized market. The category’s initial breakout was, at its core, a marketing triumph of negative positioning.

In their marketing, these models often borrow psychologist Daniel Kahneman’s dual-system theory, calling fast, automatic, intuitive cognition System 1 and slow, effortful, logical reasoning System 2. Vendors often write System 1 as System One and call themselves System One models. Yet claiming “I am System 1” on its own has limited persuasive power, because System 1 is merely a psychological metaphor that does not map onto code interfaces or system architecture. What actually convinced engineers was the declaration “I am not auto-regressive”—a claim that maps directly to verifiable engineering differences in time-to-first-token, throughput, and decoding paths.

This negative manifesto held together only because it defended a razor-thin product boundary: make only discrete judgments, choose only from caller-supplied options, and return only probabilities or scores. In Jev’s initial interface design, there were only three core question primitives: choice (selecting one from a finite set of candidates), noul (judging a proposition as true/false or positive/negative), and score (rating on a given scale). Every output fell strictly within the closed candidate space declared beforehand by the caller, with no free-text fields, no explanation fields, and no refusal type defined in the interface. The model did not chat, exchange pleasantries, or abstain; it acted purely as an intelligent conditional branch in code. That restraint was the premise of its existence as a standalone product.

For the single-step forward mechanism of these models, why their underlying technology lacks a moat, and the four historical waves of decision APIs, see the earlier mechanism and timing analysis; for detailed measurements on how a closed output space enforces a three-layer zero-hallucination boundary and probability calibration, see the earlier boundary testing article; and for where such high-frequency lightweight judgments sit within RPA semantic replay and business skill layering—and why high-frequency runtime calls carry commercial appeal much like UiPath moving the tollbooth to the runtime layer—see the earlier automation layering discussion. Returning to the category boundary itself, the initial strength of this category lay not in what it could say, but in what it could not say.

box Erased “Decisions Only”

Once an interface built on “making only discrete branching decisions in code” starts outputting rectangular coordinates inside an image, the first category boundary it drew begins to loosen. As soon as it steps outside discrete options into continuous visual perception space, the engineering contract behind the term “decision model” warps.

The landmark turning point arrived in Jev 1.14. To a primitive list that previously held only choice, noul, and score, the team added the box type. Per the official documentation, box locates a single object in an input image and returns a bounding box consisting of four edge coordinates expressed as proportions of the image dimensions, along with a confidence score.

Open the official box documentation and a striking rule stands out: “A Box answer is always a box. There is no ‘not found’ answer.” That sentence exposes the clash between the original decision contract and the new task. In discrete branching decisions, requiring the model to pick one of the supplied options without a “not found” state makes sense; in visual object localization, however, the target object may not be in the frame at all. The documentation provides no “absent” state; under its literal rule, even when the target is not in the image, the API still returns a box, compressing uncertainty into the confidence value and leaving downstream code to set its own threshold.

By its interface shape, box performs visual grounding in computer vision—that is, single-object detection: given a text prompt, it draws a bounding box around a target in continuous image coordinate space. That is a perception task, not a discrete judgment. Along the technical lineage of visual grounding, mature solutions predated decision models by years: as early as 2020, DETR formulated object detection as set prediction in a non-autoregressive architecture that directly outputs bounding box coordinates; in 2023, Grounding DINO extended this to open-set object detection; and subsequent multimodal models such as Florence-2 and Qwen2.5-VL built visual grounding in as a standard capability. Stuffing a single-object box into a decision API introduced no new primitive to visual perception.

Some might counter: box still does not generate free-text tokens one by one, and under the hood it still uses fast single-step or non-autoregressive decoding, so why can’t it count as a natural extension of a System One decision model? That argument conflates an underlying implementation property with a top-level category definition. “Not generating tokens” is an engineering implementation trait, not a cognitive mode. DETR has never generated text token by token since day one, yet nobody in the computer vision community has ever called DETR a “System One model” or a “decision model.” Once the interface crosses from a finite candidate set into continuous pixel space, the mathematical nature of the task changes.

The vendor itself was well aware of this boundary crossing. In the Jev 1.14 release blog post, the team noted that box was their first type not purely serving intelligent conditional branching, describing the addition as an exploration beyond simple decisions. The top of the box documentation is also labeled “Dreamer-ready,” indicating that image and Box questions had not yet met their own production-grade bar.

Those negative technical claims (not auto-regressive, no free-text output) still hold for box, but the core product boundary—“I only make smart-if discrete judgments”—was erased by the very people who drew the circle. On the surface, box added one more primitive type; in reality, it subtracted “decisions only.”

Clairic Erased “Discrete Choices Only”

The rigid constraint left behind by box—always returning a box, with no “not found”—is hard to make work in real production engineering. As soon as an interface is wired into document processing or data pipelines, callers immediately run into missing fields. Yet when a newcomer patches that missing-value gap while bundling text extraction, continuous distribution regression, and time-series forecasting into the same interface, the category’s second boundary disappears along with it.

Another product line from Cloudflare illustrates a different kind of type boundary. On Workers AI, they offer two models side by side: Clef handles traditional branching decisions, while Clairic targets structured extraction and prediction directly. According to Clairic’s official documentation, its request structure is organized around fields and expands the supported field types to nine at once: text, number, date, time, datetime, duration, list, estimate, and forecast.

To handle the missing fields common in real-world data, Clairic’s type design introduces a combination of p_null, confidence, and guess. Every scalar answer carries both a missingness probability p_null and a confidence score; the interface allows value to be null directly, while using the guess field to provide the value the model would have chosen had it not abstained. One response example in the official documentation is value: null, p_null: 1, guess: "INV-2291", confidence: 0.9995. This design separates “the target does not exist in the source text at all” from “the target exists, but the model is uncertain” into two independently readable signals.

Viewed purely as a type mechanism, introducing p_null does close the type gap seen earlier in box, where there was no “not found” and a box had to be returned even when nothing was there. But task boundaries matter here: p_null is a general type design built for structured information extraction, not a patch for visual grounding box. Once an interface uses text, number, date, duration, and list to pull fields out of unstructured inputs and judge whether they are empty, it is doing traditional document understanding and field extraction.

What truly flattens “discrete choices only” are estimate and forecast at the end of the type list. As explained in the Clairic launch blog post, estimate estimates a probability distribution over an unknown continuous quantity, returning a full distribution across a caller-specified [min, max] grid along with the median and the p10 and p90 quantiles; forecast targets time-series scenarios, returning a prediction interval for each future time step.

Placed back into standard machine learning task taxonomy: picking one item from a fixed enumeration is classification or discrete decision-making; pulling strings and dates out of a passage is information extraction; estimating distributions and quantiles over a continuous [min, max] interval is continuous regression or density estimation; and producing numerical intervals multiple steps into the future is time-series forecasting. They were never the same kind of task to begin with.

By the time we reach Clairic, the underlying engineering traits—“not auto-regressive, no free-form explanatory text”—remain intact, but the rule originally used to fence in the category—“discrete choices only, chosen strictly from supplied options”—is gone. Clairic restored null as a first-class state in the type system, and what it bundled in alongside it went far beyond judgment to include extraction, regression, and forecasting.

Why Everyone Is Expanding: One Possible Explanation

Watching Jev and its successors pack new types into their interfaces, it is easy to read this as feature creep or blame vendors for betraying their initial minimalism. My judgment is that the more important reason lies elsewhere: the original “discrete judgments only” boundary simply isn’t enough inside real pipelines.

A complete agent loop or automation pipeline needs more than binary or multi-way branch routing. The very same pipeline often has to extract fields from unstructured documents, draw bounding boxes around targets in screenshots or photos, estimate unknown continuous quantities, and produce interval forecasts several time steps ahead. If an interface can only answer “which branch to take,” callers still have to wire up separate visual detection, field extraction, and statistical forecasting components alongside it just to finish the workflow. A narrow boundary is sharper in marketing, but less complete in product delivery.

In my view, these products carry a counter-market dynamic: to tear open a gap in a homogenized auto-regressive LLM market, they had to draw a hard line of “I don’t do this, I don’t do that,” using a negative manifesto to catch fire in marketing, capture attention, and standardize a declarative request interface along the way. Customers, however, will not trim their real requirements just to preserve a vendor’s marketing boundary. If the circle-drawer clings indefinitely to “decisions only,” it effectively cedes the extraction, localization, and estimation needs sitting right next to branch decisions to more complete products; when successors and competitors add those types in, the product becomes whole, and the sharp edge built on “I do nothing extra” dissolves.

This explanation is consistent with product moves over the past few months, though public materials are insufficient to prove each vendor’s internal motivation. What can be confirmed is that the same interface shape now appears across products from OpenAI, Microsoft, Cloudflare, Perplexity, Liquid, and ScaleDown; some expand the type system while sharing the declarative shell, while others focus on interface compatibility. Microsoft-Decision-1 retains state plus noul/choice/score, with its documentation noting only that the request pattern resembles a system-one API; Cloudflare Clef pitches full compatibility with the Jev API, while Clairic uses fields to expand into extraction and forecasting; OpenAI Decisions adopts predicate/choice/score and adds a refusal type; Perplexity, Liquid, and ScaleDown each expose their own type surfaces as well. Taken together, these moves show a clear pattern of “shared interface shape, diverging type boundaries,” even if we cannot infer each vendor’s exact causal motive from the pattern alone.

refusal is a useful example. The initial version of Jev did not have this type; OpenAI Decisions does. Public materials do not explain why OpenAI added it, nor do they tie it to Clairic’s p_null. What can be said is that refusal, too, has been turned into a typed branch inside the schema. This has created a split between the interface layer and the semantic layer across the industry: Cloudflare Clef explicitly claims full compatibility with the Jev API, but sharing a declarative shell does not mean callers can migrate simply by swapping the base URL. Interface compatibility is not semantic equivalence across probabilities, nulls, and refusals: p_null, confidence, estimate, and refusal differ across vendors in how they define missingness, probability distributions, and calibration semantics.

What Was Lost Is Not the Market, but the Power to Define the Category

Why be pedantic about what a technical category is called or where its boundary lies? Because in software engineering, a category’s boundary determines where developers place a component in their system architecture diagram. When a category can no longer articulate how its task boundary differs from the structured output of a general-purpose model, it gets demoted in the architecture from a standalone first-class component to an ordinary decoding parameter beneath a general model gateway.

Comparing these interface designs side by side makes it clear how the circle originally drawn by saying “what I am not” was erased layer by layer:

Reading down this table, the trajectory is unmistakable. The category’s original positive definition was “judgment,” ringed by guardrails of “not auto-regressive, not slow thinking, no free-text generation.” Put these expansions together—visual grounding box, field extraction and regression forecasting in Clairic, and the varied interfaces across other vendors—and the positive core of “judgment” is gone, leaving only the negative attribute of “no free-text generation” standing in place. In my view, for the decision models discussed here, those negative attributes alone are no longer enough to distinguish their task boundary from other structured prediction interfaces.

As the interface accumulates more and more supported types, to the caller it increasingly resembles the very thing it originally defined itself against. Today’s general-purpose auto-regressive LLMs, paired with a JSON schema and structured outputs, can likewise take a context passage and a field declaration and return classification choices, extracted text, dates, numerical intervals, or even refusal states. As the tasks carried by the outer interface converge, the difference between these models and “general LLM + JSON schema” narrows down to whether the underlying engine uses non-autoregressive single-step decoding or auto-regressive token-by-token decoding. What used to be a difference in category has degenerated into a difference in underlying implementation attributes.

What this category lost in its feature expansion, then, is not the market, but the power to define the category. In my view, a blurred category boundary does not mean the engineering demand for low-latency, low-cost, strongly typed calls goes away; yet as a standalone category, the “decision model” can no longer say “what it is not.” By pulling visual detection, field extraction, numerical regression, time-series forecasting, and refusal channels into its embrace, it dismantled with its own hands the very fence that made it stand out in the first place.

If we were to give it an honest, positive technical name based on the engineering tasks it actually performs today, it should be called typed prediction with abstention, or non-autoregressive structured prediction. Typed prediction with abstention means the model directly outputs structured values, distributions, or null/abstention probabilities within a caller-declared type space, without generating free text. The exact label matters less than the substance: once marketing metaphors like “System One” are stripped away, only three positive contracts truly underpin the engineering value of this interface: first, the output space is explicitly declared by the caller; second, the model decodes the output directly without generating free text; and third, the type system must natively express missingness, uncertainty, and probability distributions.

Stepping back to this technical reality clarifies its economic position in the value chain: the outer JSON interface shape has no exclusive moat, and anyone can build a compatible API; what actually determines which model stays in production remains probability calibration quality, vertical domain data, human-in-the-loop review, and depth of integration into automation workflows—a point examined in full in the earlier timing and moat analysis.

From a business standpoint, for a pioneer like TypeSafe, losing the power to define the category is not necessarily a bad thing—though that is a scenario projection, not an established revenue fact. What may die is the early marketing shell of the “System One decision model” used to break into the market, not the product itself. If a vendor can extend the same declarative interface across extraction, localization, estimation, and forecasting, and get customers to pay for those tasks, the addressable business surface may be larger than “decisions only.” What truly needs defending are calibration, data, human review loops, and workflow integration; an artificially drawn “decisions only” line was never the reason customers keep paying.

More accurately, this category erased the boundary it originally drew through one scenario-driven expansion after another. For technical taxonomy, whether a category can still hold the circle it drew may matter more than how many new types its API can output tomorrow; for the companies inside it, however, the death of a category name does not mean the death of the business. This judgment applies specifically to these decision models, not as a universal historical law for all technical categories.