Version 1.6 · Published 30 August 2026

The WEM Verified Offer Standard

AI assistants are starting to answer “what should I buy?” — and to state prices as fact while doing it. Existing standards describe how an offer is expressed and how an agentic transaction is executed; what they do not define is the evidence an independent checker should hold before presenting a retail price as verified. These are the criteria WEM requires of itself, published so that someone who does not trust us can test them.

Scope. This standard governs whether WEM may describe a retail offer as verified. It does not govern product recommendation, merchant ranking, checkout or payment. Schema.org describes how offers are expressed; UCP and ACP define how agentic transactions are executed. This is the evidence layer underneath a stated price.

1. Resolved product identity

The offer is tied to a specific product identity: a global identifier (GTIN/EAN/UPC) where one exists, otherwise brand plus manufacturer model and the variant attributes that distinguish it, otherwise a retailer's own listing id already linked to a catalogue product. Where identity rests on a name match instead, the answer says so and is never presented as exact.

Normative requirement
A resolution made by title similarity alone MUST NOT be reported as an exact identity, and an offer MUST carry the method by which it was identified.

Most wrong price comparisons are not wrong prices; they are the wrong product. A 100ml bottle compared against a 50ml one produces a real number about the wrong thing, and no amount of price accuracy repairs it. Not every product carries a barcode, so the rule is a ladder rather than a gate — what it forbids is presenting the bottom rung as the top one.

Conformance: Every answer reports identity.method and identity.strength. A title match MUST be reported as inferred and MUST NOT be presented as exact.

2. Observed at the retailer's own surface, not submitted through a feed

The price was read by WEM from a surface the retailer serves to shoppers — their product page, or a first-party API that returns the customer-facing transactional offer. A price taken from an affiliate, comparison or promotional feed does not qualify as an observation, whichever transport delivers it.

Normative requirement
A verified price MUST come from an observation of the retailer's customer-facing or transactional surface. A feed MAY identify candidate products and offers, but MUST NOT be the sole evidence for a verified price — and an endpoint that serves syndicated feed data MUST be treated as a feed regardless of being called an API.

A feed is evidence of what a merchant said. An observation is evidence of what a shopper could actually see. Both surfaces belong to the retailer — the difference is not who controls them but what they bind: the page is the one a customer transacts on, while a feed is a copy prepared for redistribution that can drift from it without consequence. Detecting that drift is the whole job, and it cannot be done from the copy alone.

Conformance: A feed MUST NOT be the sole evidence for a verified price. An endpoint that serves syndicated feed data is treated as a feed regardless of being called an API.

3. Timestamped, and the age is disclosed

Every observation carries the moment it was made, and anything published says how old it is rather than implying "now".

Normative requirement
Every observation MUST carry the time it was made, and any published price MUST disclose that time or its age.

A price with no time attached is unfalsifiable — it cannot be shown wrong, so it cannot be shown right either. "Checked 4 hours ago" is a weaker claim than "live" and an honest one.

Conformance: Every answer discloses lastConfirmedAt so a caller can judge the age of the reading rather than being asked to trust it.

4. Labelled provenance, on every single row

Each observation records how it was made, and the label travels with it: retailer API, browser extension reading the page, or a human who opened it.

Normative requirement
Provenance MUST be recorded per observation at the moment of collection, not asserted per dataset.

Provenance is a property of the price, not of the dataset. Once observations of different kinds are pooled without a row-level label, no later filter can reconstruct how each price was obtained — so the label is written when the row is, or the row is not admissible.

Conformance: Every observation is written with its provenance label at the moment of collection. Published vocabulary: api:, extension, operator.

5. Availability stated only where it was checked

Availability has three states, not two: reported available, reported unavailable, and not reported. The third is recorded as unknown and never rendered as "in stock".

Normative requirement
Availability MUST NOT be inferred where the source did not report it. Unknown MUST NOT be rendered, ranked, or published as available.

A price for something nobody can buy is not a cheaper option. Defaulting unknown to available is the single easiest way to make a comparison look better than reality — which is why the rule forbids treating unknown as available rather than trusting the intention.

Conformance: Availability is three-valued: true, false, or null. Null means the source did not report stock. Unknown MUST NOT be rendered, ranked, or published as available.

6. Silence when the evidence is missing

Where an offer cannot meet these rules, it is excluded from verified results. Nothing is estimated, inferred, or filled in to complete a comparison.

Normative requirement
A missing value MUST NOT be estimated or substituted to complete a comparison. Where evidence is absent the answer MUST be an explicit no-verification result, not a plausible one.

The pressure in comparison is always to show something. A gap teaches a shopper that the absence means something; a plausible guess teaches them nothing and costs them the ability to trust the rest. An offer WEM cannot verify may still be shown as a discovery result — it is verified status it cannot have, and the two are kept apart.

Conformance: Where evidence is absent the answer is an explicit no-verification verdict — unknown_product or not_at_retailer — never a substitute price or a nearest guess.

7. The answer does not know what it earns

Ranking, selection and verification are computed without reference to commercial terms. Funding is disclosed; it never reaches the ordering.

Normative requirement
No commission, revenue-share or commercial-priority value MUST be available to the code path that verifies an offer or orders results.

Verification is only worth something if the verifier is not paid for the verdict. WEM is funded by affiliate commission and does not pretend that conflict is absent; it is a data-isolation property instead of a promise — the commercial value exists, and the ranking path cannot read it.

Conformance: No commission or commercial-priority value is present in the verification or ranking path. Ranking is by price alone.

8. Lawful to retain and to republish

An observation is only published where the source's terms permit retention and republication. Where they do not, the data must not enter the verification corpus.

Normative requirement
Data whose terms restrict the retention, comparison or republication a verified result depends on MUST NOT enter the verification corpus, and MUST be refused at collection rather than filtered at publication.

A verification corpus that cannot be shown is not evidence. Sources whose licences cap retention or bar comparison use are excluded before collection, because a clean provenance story does not create a retention right. Which sources those are is an implementation matter and changes as terms do.

Conformance: Licence-excluded sources are refused at collection. They never enter the verification corpus.

9. Total cost stated only where every component was observed

A verified offer reports the item price and, separately, postage, tax and mandatory fees. A component that was not observed is listed as unknown. The delivered figure is the item plus every stated extra — a floor when anything is unknown, never a complete total invented to fill the gap.

Normative requirement
An implementation MUST NOT present the item price as a complete total when postage, tax or a mandatory fee was not observed, and MUST NOT invent those amounts.

A shopper who is shown £229 as "what you pay" and then meets £18 postage at checkout was not given a cheaper option — they were given an incomplete one. The same honesty as availability: unknown is recorded, not guessed as zero.

Conformance: Every offer carries totalCost with item, shipping, tax, fees, delivered, confidence, and unknown. confidence is stated only when shipping, tax and fees were all observed. Otherwise delivered equals the item plus any stated extras and MUST be relayed as a floor.

The distinction that does most of the work

Criterion 2 separates two things the word “price” hides. An advertised price is supplied for distribution — through an affiliate, comparison or promotional feed. An observed price is captured by the verifier from the surface the retailer serves to shoppers, whether or not any commercial relationship exists.

A feed is evidence of what a merchant said. An observation is evidence of what a shopper could actually see.

Both surfaces belong to the retailer, so the distinction is not who controls them. It is what they bind: the page is the one a customer transacts on, while a feed is a copy prepared for redistribution that can drift from it without consequence. A feed cannot verify its own price — detecting that drift needs a separate observation path, and that remains true no matter how large the feed is.

What counts as the same price

A claimed price counts as matching an observation when it falls within £1 or 1% of it, whichever is larger. The floor exists so honest rounding is not scored as an error — "about £50" against £49.99 is the same price. The percentage is deliberately tight: 2% of an £849 phone would be £17, which is not a rounding difference but a worse deal, and calling it a match would hide the harm the check exists to surface. Every answer reports the band it applied as `toleranceApplied`.

Verification is not a price guarantee

A verified offer states what WEM observed and when. The retailer is authoritative at checkout: they set the price, hold the stock, and may change either between our reading and your arrival. WEM never takes payment and guarantees no price.

How to check this without trusting us

Every claim above is a behaviour, so it can be tested from outside. WEM’s MCP server and /api/verify are public and need no key. Each of these takes about a minute.

  • Ask for a price WEM cannot evidence

    Call verify_offer (or POST /api/verify) for a product WEM does not hold.

    Criteria 1 and 6: the answer is `unknown_product` with no price, never an estimate or a nearest guess.

  • Check a price that has moved

    Claim a price that differs from the retailer’s current one.

    Criterion 3: the verdict is `price_moved` and carries `lastConfirmedAt`, so the age of WEM’s reading is visible rather than implied.

  • Look for stock WEM never checked

    Read `inStock` on any offer from a provider that does not report availability.

    Criterion 5: the value is `null`, not `true`.

  • Resolve a product by name rather than barcode

    Pass `title` instead of `gtin` to verify_offer.

    Criterion 1: `identity.strength` comes back `inferred` and the summary says the match was made on the product name.

  • Diff the live answers against the published examples

    Fetch /standard/verified-offer/examples.json and compare its shapes with what the API returns for your own calls.

    Every criterion at once. The examples are worked fixtures over a synthetic catalogue. A difference in shape from the live API is a defect on our side. They are not live market quotes.

  • Read a total that is missing postage or tax

    Look at `totalCost` on any offer from a retailer that did not state postage, tax or mandatory fees.

    Criterion 9: confidence is `unknown`, those components are listed on `unknown`, and `delivered` equals the item price. Relaying that figure as what the shopper will pay does not conform.

  • Run the published conformance suite

    Fetch /standard/verified-offer/conformance.json and evaluate its cases against examples.json. No account required.

    All nine criteria. The suite is the same object CI asserts. Partial adoption is useful; only every case passing is conformance.

The note beside each criterion is a conformance test — what an implementation must expose or refuse. Those are descriptions, not evidence. The checks above are the evidence, because they run against the live service rather than asking you to take our word for it.

What WEM does not claim

  • Not every price on the internet. WEM observes a bounded set of retailers and says nothing about the rest.
  • Not a live quote. An observation has an age; the retailer sets the price at checkout, and WEM never takes payment.
  • Not certification of anyone else. The standard describes what WEM will publish. No third party is audited or endorsed by it today.

Using it

The standard is free to read, cite and apply. If you build commerce data and want to state that you meet it, do — and say which criteria you meet, because the ones a dataset fails are usually the informative ones.

Conformance. An implementation conforms to version 1.6 only if all nine normative requirements are satisfied for every offer it describes as verified. Partial adoption is welcome and useful, but it is not conformance, and should be stated as the specific criteria met rather than as compliance with the standard.

Machine-readable: schema.json defines the verified-offer object, and examples.json carries a worked fixture for every verdict, including the two that refuse to confirm, and conformance.json is a nine-case suite a third party can run against those fixtures. Each response is produced by the same verifier the live verify_offer API uses, over a synthetic catalogue, so the shape cannot drift from what the API returns. The prices in the fixtures are not live market observations.

Agents can call the criteria rather than read them: WEM’s MCP server exposes verify_offer, which answers whether a specific price is supported by observation. It never invents or infers a price; it returns an explicit non-confirming verdict instead, and the three are not the same claim. unknown_product and not_at_retailer mean the claim could not be checked — unchecked, never false. price_moved is stronger: the product and retailer resolved, and WEM’s own reading differs from the claim.

Cite it as: The WEM Verified Offer Standard, version 1.6, wem3.ai/standard/verified-offer.

Change control

Criteria are versioned. Clarifications that do not change what qualifies are published as minor versions; any change that would let data qualify which previously did not requires a new major version, and the superseded edition stays citable. The URL does not move.

1.630 August 2026
A verified answer now reports Total Cost with the same honesty as availability: each offer carries the item price, any stated extras, and a list of components that were not observed. When postage, tax or mandatory fees are unknown the delivered figure equals the item price and confidence is unknown — a floor, not a complete total. Answers also carry an evidence receipt that cites the answer already returned (ACP suggested_price names: observed_at, source, amount). It is not a new observation. It is signed only when a dedicated HMAC key is configured; otherwise unsigned (fail closed). No criterion was weakened and 1.5 stays citable.
1.529 August 2026
The scope of a "cheapest" answer is now machine-readable. Responses carry a comparison set stating how many offers and distinct retailers stood behind the answer, and an exhaustive flag that is permanently false. Nothing changed about which offers qualify: the summary already said "the cheapest verified offer WEM holds", and this states the same bound in a field, because a caller reading the structured answer alone had nothing to stop it relaying an unqualified "cheapest". No criterion was weakened and 1.4 stays citable.
1.429 August 2026
Conformance notes replace implementation pointers. No criterion was weakened. The page now states the required behaviour (identity method, three-valued availability, silence when evidence is missing, commission isolated from ranking) without naming internal predicates, ranking tools, or storage defaults. Worked examples use synthetic retailers and products. 1.3 is unchanged and stays citable.
1.329 August 2026
Published the price-match tolerance, and corrected the worked examples. The tolerance was already derivable from two numbers in examples.json, so it was public whether or not the page said so; stating it deliberately makes it part of what "confirmed" means, and makes any future change to it a versioned one rather than a silent one. The examples previously printed a catalogue slug beside identifiedBy: "gtin", which taught the wrong call — passing a slug returns an identity method of "slug", not "gtin" — so each request now shows the identifier it claims to have used, with a check-digit-valid barcode. Minor version: nothing that previously failed now passes, and the bar is unchanged.
1.228 August 2026
Machine-readable conformance, and a tightened criterion 2. Published schema.json and examples.json, both generated from the code that answers the live API rather than written by hand. The examples are worked fixtures over a synthetic catalogue — shapes and verdicts match production; the prices are not live observations. Named source exclusions stay out of the public artefact (criterion 8: which sources fail is an implementation matter). Added an explicit definition of full conformance — previously the page invited implementers to state which criteria they met without defining what meeting the standard was. Criterion 2 now says an endpoint serving syndicated feed data is a feed whatever it is called, closing the relabelling gap. Corrected the description of non-confirming verdicts: price_moved is a finding, not an absence of evidence, and grouping it with unknown_product understated it. This is a minor version because every change narrows what qualifies or clarifies without moving the bar; nothing that previously failed now passes.
1.128 August 2026
Clarifications following technical review; no criterion was weakened. Narrowed the opening claim to acknowledge schema.org, UCP and ACP; added the scope statement and RFC 2119 wording; corrected criterion 2 to distinguish a retailer’s authoritative surface from a feed submitted for redistribution, and removed an incorrect generalisation that comparison feeds are paid per click; corrected criterion 4’s claim about pooled data; stated criterion 5’s three states explicitly; removed named providers from criterion 8; relabelled implementation pointers, which are not externally auditable in a private repository, and added the public checks above.
1.028 August 2026
Initial publication.

Common questions

What is a verified offer?
WEM publishes the Verified Offer Standard at https://wem3.ai/standard/verified-offer. A price is verified only when WEM holds an observation that meets those criteria — product identity, amount, source, and time — and stays silent where evidence is missing. Affiliate feed rows and unobserved listings are indicative, not verified. Checkout still happens on the merchant; WEM is not merchant of record and does not guarantee the price at payment. Agents can call the public verify_offer tool; humans can read the standard and the evidence-receipt fields observed_at, source and amount.
Are all prices on WEM verified?
No. A price is verified only when an observation meets the published criteria. Affiliate feed rows and unobserved listings stay indicative. WEM stays silent where evidence is missing rather than inferring a price.
Does a verified offer guarantee the checkout price?
No. A verified offer states what WEM observed and when. The retailer is authoritative at checkout: they set the price, hold the stock, and may change either between the observation and your arrival. WEM never takes payment.

Related: the pre-registered Black Friday methodology applies this standard to a specific study, committed before the data was collected. WEM is funded by disclosed affiliate commission — how that works.