Verifiable extraction: why 'where did this number come from' is becoming a buying spec

An extraction API takes a page and hands back an object: a price, a date, a list of board members, a revenue figure. Most of them stop there. The object is clean, it validates against your schema, and it gives you no way to check whether any single field is right. If the model read the wrong table, the JSON looks identical to the JSON you wanted.

That gap is the thing to watch in the second half of 2026. A verifiable extraction is one where every field carries a pointer back to the exact place on the page it came from, so a person, or a downstream agent, can confirm it without re-reading the source. Search APIs have quietly had a version of this for a while. Schema extraction, the part AI builders lean on hardest, mostly does not. The vendors closing that gap are turning provenance into a line item you can shop for.

The clean-JSON problem

The shift to plain-English extraction made the interface simpler without making the output any easier to trust. As covered in natural-language web scraping in 2026, you now describe the fields you want instead of writing selectors, and a model fills them in. The failure mode moved with it: a selector that breaks throws an error, but a model that misreads a page returns a confident, well-formed answer that happens to be wrong.

You can see the shape of the problem in how the schema endpoints are built. Firecrawl's structured extraction, per its own roundup of extraction tools, accepts a JSON Schema and returns an object shaped like it, and it strips HTML attributes before the model ever sees the page. That is reasonable for token efficiency, but it means the output has no thread back to the DOM node, the table cell, or the paragraph a value was lifted from. You get structured output and nothing to audit it against.

For a one-off scrape that is fine. For an agent that reads a filing, extracts twelve numbers, and acts on them, it is the whole risk surface.

Where provenance already exists, and where it doesn't

The odd part is that the search-API side of the same market solved a version of this first. Exa's Contents API returns query-aligned highlights: passages selected against your question, so the same URL yields different excerpts for different queries. Its own docs make the efficiency case plainly, that roughly 500 characters of highlights carry the same retrieval accuracy as the first 8,000 characters of the page. The side effect matters more than the token savings. When a search API answers, it can show you the sentence it answered from. That is provenance, even if it is sold as relevance.

Schema-guided extraction is where the thread goes missing. The interface asks for typed fields, the model returns typed fields, and the passage each value came from is discarded on the way out. Two products in the same market, two different defaults: one returns a citation, the other returns an assertion you have to take on faith.

The document layer set the bar

The clearest picture of what field-level provenance looks like in production is coming from document extraction, where the stakes (financial filings, healthcare records, regulatory documents) never allowed the untraceable version.

Reducto's Deep Extract returns schema output with sentence-level bounding boxes, which it frames as exact citation and RAG source tracking: every extracted value maps to a region on the page, so a reviewer can jump straight to the source span. It is not alone in the shape. Landing AI's document extraction leans on visual grounding, mapping each value to a region, and Mistral's OCR release adds bounding boxes and per-field confidence scores. Vision-based extraction turns out to be a natural home for provenance, because the coordinates are already there.

The proof that this is more than a demo came from an independent test. LongExtractBench, run by micro1 in June 2026, put extraction systems against 225 complex documents averaging around 358 pages each. Reducto posted 99.6% precision, 99.6% recall, and 99.3% leaf accuracy, and it was the only system in the test that finished all 225 documents without failing on one.

Read that last clause first. On long, messy inputs the interesting number is not the accuracy on the documents a tool completed, it is how many it refused or crashed on. Completion rate quietly measures the same thing provenance does: a system that can point at where every field came from is one that actually parsed the whole document rather than skimming it. The headline accuracy is downstream of that.

Why an AI builder should care

Start with retrieval. If you are building a pipeline that shows sources, field-level provenance is the difference between citing a document and citing the exact line. The extraction step feeding your RAG pipeline is usually the weakest link in the chain, and it is the one users never see until a wrong number ships with a confident footnote.

It also changes what an agent can do on its own. An agent that gets a value plus a source span can re-read that span and check itself before acting. An agent that gets a bare value has to trust it or extract again from scratch. Provenance is what makes a cheap verification pass possible instead of a full re-run.

The cost math shifts too. When extraction is untraceable, a bad field means re-running the whole page and hoping. When each field carries a source, you re-check only the low-confidence ones, which matters on high-volume jobs where blind retries are a quiet line item.

There is an audit dimension on top of all that. Provenance is what lets you answer "where did this number come from" months later, which is exactly the kind of traceability the compliance conversation around AI-sourced data keeps circling back to. That is a longer story, but the plumbing starts here.

How to buy for provenance

You do not need a new vendor category. You need to add one question to the evaluation you already run.

• Ask what comes back besides the value. Bounding boxes, a source span, a character offset, a confidence score: any of these is a thread back to the page. None of them proves the field is right, but all of them make a wrong one catchable. A vendor that offers nothing is asking you to trust the model blind.
• Test it on your ugliest inputs, not the demo. The extraction benchmarks worth knowing measure quality on clean articles and product pages. Your own test should use the documents that actually break: nested tables, footnotes, multi-column layouts. That is where a traceable answer earns its keep.
• Score completion, not just accuracy. Borrow the LongExtractBench framing and count how many documents a tool returns nothing on or errors out on. A high accuracy score over a small finished subset is a worse signal than a slightly lower score across the whole batch.
• Know when it is overkill. Pulling a title and a price off a product page does not need bounding boxes. Provenance earns its cost when a wrong field is expensive to catch later, which is the case for agents, financial data, and anything a person will have to defend.

What to watch

Two things. First, whether the web-extraction vendors follow the document-extraction ones. The search side already cites passages and the document side already returns regions, which leaves the pure schema-from-HTML products as the holdouts. The pressure to close that gap is building from both sides.

Second, whether provenance becomes a benchmarked axis rather than a feature bullet. Right now completion rate and source accuracy live in one independent test. When they show up in the standard extraction leaderboards next to precision and recall, "show me where this came from" will have finished its move from nice-to-have to spec. For anyone shipping agents on extracted data, it is worth pricing in before then.