DoorDash's catalog agent publishes the attributes it could not verify

Seven DoorDash engineers published a paper last month describing the system that fills in missing product attributes across a 31-million-SKU catalog.¹ Underneath its accuracy figure sits a publishing rule that deserves more attention than it has had. Their verifier returns one of four verdicts on every proposed value, and two of those four send the value live on the product page. One is PASS, which means the evidence confirmed it. The other is UNVERIFIED, which the paper defines as a value that is plausible, uncontradicted, and impossible to confirm for the exact product in question. A shopper reading that product page cannot tell the difference between a fact the system checked and a fact it merely failed to disprove.

The system is described as verify-before-write. Its own write rule publishes the unverified.

What does TRACE actually do?

TRACE is a two-agent pipeline for catalog enrichment, which means filling in structured product fields that a merchant left blank.¹ A ScoutAgent gathers evidence and proposes a value. A JudgeAgent then re-examines that value against the evidence and decides whether it may be published. DoorDash deployed it across 31 million products in four categories, and a five-week test showed that displaying the resulting attributes raised checkout conversion by 0.48 percent.¹

The evidence the ScoutAgent draws on comes in four tiers, in priority order: the merchant’s own catalog record, purchased data from commercial product-data syndicators, the product photograph, and last, a general web search. The paper is explicit that web search fills gaps and never corrects the merchant’s own data. That ordering matters for everything below, because the open web is the only tier where the agent has to work out for itself whether the page in front of it is even about the right product.

What does the identity check actually match on?

TRACE’s ScoutAgent matches on four things before it will use a web page as evidence: brand, product variant, size and pack count.¹ Its instruction reads “Before using image or web evidence, match the same brand, product variant, size, and pack count,” and it continues “Do not use evidence from a nearby variant.” A page that fails this check is discarded, and the attribute it would have supplied is recorded as identity_mismatch instead.

Identity matching asks a different question from ranking, and the paper says why. Topical relevance is not enough, because “a retrieved source may describe a closely related product or variant with different attribute values.” A page can be the best answer to the query and still be about the wrong thing.

The barcode is the first thing the ScoutAgent searches for, and it is optional as proof of the match. The search instruction lists five steps in order: the barcode first, in any of the standard product-identifier formats (UPC, GTIN or EAN), then brand plus product name plus size or variant, then model or manufacturer part number, then the official manufacturer page, and last a query for the attribute itself. The identity rule that follows says only that “Product identifiers and model/MPN may be used to establish the match.” May, not must.

That ordering cuts against the usual advice. Google strongly recommends a barcode for any product that has one, and strongly recommends the brand and the manufacturer part number on top of it, whether or not a barcode exists.³ The advice is sound, and this particular gate turns on something else. Here the descriptive fields do the work.

Do product pages actually publish those four things?

Mostly not, and the variant field is the worst of them. On September 9, 2026 I sampled 110 product pages across 11 manufacturer brands, spread across the same four categories the paper covers, and checked what each page publishes in its structured data. Not one of the 110 pages published a machine-readable variant structure. Two brands of the eleven published any globally resolvable identifier, covering 19 pages.

I went to manufacturer sites instead of retailers on purpose, because the agent’s instructions do the same. Its stated source preference is “official product pages and manuals, followed by major retailers, other retailers, and aggregators,” so the brand’s own page outranks every store that sells the thing.¹

What the page publishes	Pages	Share
A Product node in its structured data	88 of 110	80.0%
A brand value	78 of 110	70.9%
A sku, which is the site’s own internal key	60 of 110	54.5%
Machine-readable spec values (additionalProperty)	30 of 110	27.3%
A globally resolvable identifier (gtin*, mpn, productID)	19 of 110	17.3%
A variant structure (ProductGroup, hasVariant, variesBy)	0 of 110	0.0%

An independent check at web scale points the same way. Web Data Commons crawls the whole web and publishes how often each schema.org property appears. In its Product measurements, gtin13 reached 4.06 percent of the domains that annotate products. mpn reached 8.59 percent, and sku reached 60.52 percent.² The shape matches my panel closely. Internal keys are common, and identifiers that mean something to an outsider are rare.

Some of this is a platform default rather than a merchant choice. Shopify’s reference themes emit their product markup through a single template function, and the rendered example in Shopify’s own documentation for that function contains a brand but no sku, no gtin and no mpn anywhere in it.⁴

What happens when the agent cannot confirm the exact product?

TRACE publishes the proposed attribute value anyway. Two pieces of the paper, read together, establish that. The verifier’s instructions define its verdict on a web-sourced value like this: “Exact-product confirmation is PASS; an exact-product contradiction is FAIL/INCORRECT_VALUE; a similar variant, generic page, or no relevant result is UNVERIFIED.”¹ So landing on a near-miss page produces UNVERIFIED, and the paper is careful to distinguish that from being wrong: “FAIL requires positive evidence that the claim is wrong or fabricated.”

Then the write policy, stated as a formula, sends both PASS and UNVERIFIED to WRITE. Only a FAIL verdict or a confidence score below a threshold produces a block, and only evidence that is conflicting or ambiguous routes to a human. So four verdicts collapse to three actions, and the two that publish include the one meaning “I could not check this.”

In plain terms: the system does not distinguish, at the moment of publishing, between a value it confirmed and a value it could not confirm but had no reason to doubt. Both appear on the product page as ordinary structured facts.

The design is defensible, and the paper explains its reasoning. An earlier version used only PASS and FAIL, and it was too strict: of the cases where the verifier and human reviewers disagreed, 87.8 percent were values the machine rejected and humans judged correct.¹ Splitting that single rejection bucket into three is a sensible response to a measured problem. The consequence is still that “could not confirm” now ships.

How often does this actually fire?

Unknown, because the TRACE paper never reports how often its write policy publishes an UNVERIFIED value instead of a PASS. Three gaps sit between that rule and any estimate of how often it fires. Sitting last among the four evidence tiers, web search is reached only for attributes that the merchant’s catalog, the syndicated data and the product image all failed to resolve, and no figure is given for how often that happens. The split between PASS and UNVERIFIED among published values is never reported anywhere.

Because it measures the whole deployed system, the conversion result carries the same problem. None of the 0.48 percent can be assigned to this rule or to any other single part, and the paper’s own limitations section says so plainly.¹

Two more limits belong here. From one dataset of 500 products in groceries and alcohol, the headline 98.2 percent accuracy is human-checked, and no such figure exists for the electronics and home-improvement set or for the millions of products in production.¹ The paper also notes that its two agents run on models from the same family, so their mistakes may correlate and the verifier is a weaker independent check than two separate systems would be.

Is this one company doing something unusual?

No, and that is the reason to care about the rule instead of the company. Instacart has published its own attribute-extraction platform, reporting 95 percent accuracy on its first organic-attribute run.⁵ Walmart Global Tech describes the same work across hundreds of millions of data points, with a second model doing quality control on the first.⁶

Instacart also reports that letting the system read product images as well as text lifted recall by 10 percent, where recall means the share of correct attributes it actually catches.⁵ Some details appear only on the packaging, which is the same reason TRACE keeps image evidence in a tier of its own. Amazon, Shopify and Alibaba have each published work in the same territory, which I have not read as closely as the two above.

Filling catalog gaps with a language model is ordinary infrastructure at every large marketplace now. What differs between these systems is the publishing rule, and DoorDash is the one that wrote its rule down.

One disclosure on attribution. The paper never names DoorDash in its body text; the company appears in the author affiliation line and in all seven author email addresses.¹ I have found no trade coverage or company blog post about it, and no conference venue either, so this reads as an unremarked preprint rather than a launch.

What should a merchant actually do about it?

Three things, listed in descending order of how confident I am that each one helps. None of them is new work for a team that already maintains a product feed, and the first two are fields you probably already hold somewhere in your product information system. The third is a habit rather than a change to your pages.

Publish the four identity fields as text, and not only as pixels. Brand, variant, size and pack count are what the gate matches on, and a specification that lives only inside a product photograph is second-class evidence by the pipeline’s own design, since it holds image evidence in a separate and noisier tier from text. This is the recommendation I would defend hardest, because it follows directly from the instruction text.

Publish a real identifier anyway. It is the agent’s first search key even though it is optional as proof, it is what Google asks for,³ and on this panel it is the single rarest thing on the page. Adding it costs a feed field.

Treat an AI-enriched attribute on someone else’s product page as unconfirmed until you check it. If a marketplace lists your product with a specification you did not supply, the four-verdict taxonomy behind it sounds rigorous, and at the moment of publishing it comes down to a single question: did anything positively contradict this? Silence counts as permission.

A caution on the first two, and it is the honest boundary of this piece. The paper says nothing at all about consequences for the site the evidence came from. There is no claim about traffic, ranking, citation or credit anywhere in it, and no suggestion that clearing the gate benefits the page that cleared it. This is a system built to control the quality of one company’s own catalog. Reading it as a new ranking factor would be inventing a finding. What it does give you is an unusually clear look at the rule a machine is applying to your product data when nobody is watching, and that rule publishes what it could not check.