Extraction model definition

An extraction model answers typed questions about an input with values: a total copied off an invoice, a due date computed from it, an estimate the document implies but never states. The answer is only as good as the state you hand it. In Sanity, content is already modeled as named, typed fields, so that state is a GROQ projection of the few fields the question concerns rather than a rendered page, and the typed value that comes back writes into a field of the same type.

What is an extraction model in AI?

An extraction model takes an input state and a map of named, typed fields, and returns one value per field in a single forward pass, generating no tokens along the way. You declare what you want (an invoice total as a number, a due date as a date, a list of contacts as a list of strings) and the model decodes each answer under the rules of that type.

Cloudflare's documentation puts the purpose plainly: extraction models "turn information into specific values your application can use, such as an invoice total, a due date, or an estimated payment amount. They return typed values rather than choosing from a fixed set of options or producing open-ended content."

One naming collision is worth clearing up. An extraction model in this sense has nothing to do with model extraction attacks, where someone reconstructs a model by querying it repeatedly. The two share a word and nothing else.

What kinds of values can an extraction model return?

An extraction model returns four kinds of value, and the difference between them is where the value comes from. Cloudflare's documentation names all four.

Extraction returns a value explicitly present in the input, such as the total printed on an invoice. Text answers come back as a span, a stretch of the input identified by its start and end character offsets, with a confidence attached. Computation derives a value from facts in the input, so the result does not have to appear anywhere in it: how many days an invoice is overdue, given its due date and a current date you supply. Estimation predicts a value the input does not determine, such as when an unpaid invoice will actually be paid, and returns a distribution inside bounds you declare, with a median and an 80% interval. Forecasting predicts a sequence of future values, returning a value for each step in the period you ask for, such as an outstanding balance for each of the next four weeks.

When a field asks for something the input cannot settle, an extraction model returns null rather than guessing. Clairic reports the probability of absence as `p_null`, a number from 0 to 1 that the value simply is not in the input. Lists return an empty list when nothing matches. Estimates and forecasts still return predictions even on thin evidence, with a correspondingly wide interval.

How is an extraction model different from an LLM's structured output mode?

An extraction model and an LLM in structured output mode both hand your code JSON, but they get there differently, and the difference shows up in what you can do with the result.

Structured outputs constrain a language model's decoding so that every token it generates keeps the output parseable against a schema. It is still generating text one token at a time; the text just happens to fit. An extraction model generates no tokens at all. As Cloudflare's changelog for Clairic describes it, the model "reads your input in one pass and decodes each answer under the rules of its type, so every answer is a valid value of the type you asked for, or null when the input does not determine it."

Two practical consequences follow. First, the values carry calibrated probabilities: a confidence per answer and a missing-value probability, so your code can route low-confidence fields to a human instead of treating every answer as equally solid. A structured-output LLM gives you a value or an absent key with no signal either way. Second, there are no output tokens to pay for. Cloudflare lists Clairic at $0.10 per million input tokens with no output charge, as of 19 October 2026.

An extraction model also differs from a decision model, the other kind of System One model. A decision model picks among options you list and returns a probability for each. An extraction model returns values you could not have enumerated in advance, which is exactly the case questions like "what is the invoice total?" fall into.

Where did extraction models come from?

Extraction models were introduced as a class by Cloudflare on 19 October 2026, when it previewed Clairic and described it as "a new class of System One-style models." Until then, every System One model was a decision model: you gave it a state and a set of options, and it gave probabilities over those options.

Cloudflare's own framing of the lineage: "Jev and Clef take an input state and a list of questions and give probabilities against the inputs and your listed questions. Clairic is the first model in a new class: System One extraction models. It is still fast, typed, and cheap, but it answers with values directly extracted from the input, computed from it, or predicted beyond it."

Clairic is the first extraction model, not a synonym for the class, in the same way that Jev was the first decision model rather than the definition of one. Cloudflare also describes how the three model types chain: extraction models turn raw input into typed values, decision models turn values into decisions, and LLMs turn decisions into words.

Field-level extraction with per-field confidence is not itself new. Document AI and intelligent document processing platforms have shipped confidence-scored field extraction for years. What the System One framing adds is the general-purpose form: a schema supplied at request time, answered in one pass without generated tokens, with estimation and forecasting sitting alongside plain extraction.

What are extraction models used for?

Extraction models are used wherever an application needs specific typed values out of input that was not written for machines. Three patterns cover most of it.

Invoices and forms are the obvious case: totals, due dates, purchase order numbers, and contact details, each returned as the type your database column expects. Cloudflare's support-email example shows the computation side at work, adding $649.00 and $52.10 in tax to return 701.1, a figure the email itself never states.

Pulling fields out of unstructured content into a content model is the second. A pasted press release, a supplier PDF, or a long body of prose contains an effective date, a product name, and a region, none of which is addressable until it exists as its own field. Extraction turns that prose into fields a query can filter on.

Enriching documents already in a system is the third: adding dates, entities, and derived numbers to records that are otherwise fine. This is where the destination matters as much as the model. Sanity is the AI Content Operating System, with content modeled as named, typed fields in a schema defined in code, so a value an extraction model returns lands in a field of the declared type and is queryable afterwards rather than re-parsed at read time. Functions, which run on Sanity's infrastructure in response to document create, update, and delete events, are where that call and that write would sit.

Can an extraction model be wrong?

Yes. An extraction model guarantees the shape of its answer, not the truth of it, and every maker in this space says so directly. Cloudflare's changelog for Clairic is blunt about it: "Every answer is well formed, not necessarily correct."

The same goes for constraints. Cloudflare's documentation gives a good example: restricting an estimated payment date to November guarantees the returned date falls in November, but the invoice could still be paid in December. Bounds control the output space, not reality.

Cloudflare also publishes limits for the Clairic preview, and they are worth knowing before you design around the class. One- and two-step calculations such as totals, differences, conversions, and date arithmetic are described as reliable; long chains of dependent steps and aggregations across many table rows are not yet, and Cloudflare's advice is to extract the inputs and do the math in code. Estimates are best when the input contains evidence such as comparables or history, and the interval runs wide without it. Forecasting is described as basic: next-step forecasts follow recent patterns, but forecasts several steps out flatten toward the average. Intervals are trained to be calibrated but can run narrow on unfamiliar data.

All accuracy and performance figures published about extraction models so far are self-reported by the model's maker, and no independent evaluation of Clairic existed as of 19 October 2026. The practical response is the one Cloudflare recommends: use the confidence, the missing-value probability, and the intervals to decide what to automate and what to send to a human.

Last updated: October 22, 2026