--- title: AI Product Match Verification mark: Barcode verified version: "0.1" status: published published: 2026-11-05 publisher: wefetch --- # AI Product Match Verification · version 0.1 "Barcode verified" is the mark of this specification. It is free to any conforming implementation. The specification answers one question for an AI agent at the moment of purchase: are the product the shopper asked for, the product the merchant is offering and the product on the verified record the same barcode — and how does the agent prove it checked? This document defines what a verified product match is, what evidence it rests on and what a receipt for one must carry. It has six sections. A country profile (a node, at `.barcodeverified.org`) adds evidence for its market; it can never weaken this document. Missing required evidence prevents a verified result. ## 1. Match record A match record is one binding of words to a barcode, made by a matcher. | Field | Holds | |---|---| | words | The shopper's phrase or the merchant's offer line, as given | | kind | `phrase` (what the shopper said) or `offer` (what the merchant listed) | | barcode | The barcode bound, as fourteen digits; empty unless the outcome is `one` | | confidence | A number from 0 to 1: how sure the matcher is of this binding | | outcome | `one` (one barcode), `ambiguous` (the candidates are listed and none is chosen) or `unknown` (nothing on the record matches) | | candidates | When ambiguous, the barcodes that fit; never a guess between them | | country | The market the words were read in (two letters; the United Kingdom is `UK`) | | time | When the binding was made (UTC) | | matcher key id | The key id the matcher's receipts are signed under | | match hash | `sha256:` over the canonical form of id, time, words, country, barcode, confidence, outcome and matcher key id | A conforming matcher returns `ambiguous` rather than choose between candidates it cannot tell apart, and returns `unknown` rather than bind words to a barcode the record does not hold for the country. A pack, size, count or variant word that disagrees outweighs every word that agrees. The machine form is [Match record schema](/protocol/match-record.schema.json). ## 2. Verification policy ### 2.1 The four dimensions Each is read independently from what the record already holds for the barcode in the country. | Dimension | Question | Read from | |---|---|---| | Source authority | Who said it, and are they the authority for this field in this market? | The source page on each field; the node's authority table | | Disagreement | Do two sources differ on this field? | The field's source set | | Freshness | Is the read date inside this field's clock? | The read date on each field; the clock table (2.3) | | Authorisation | Has the brand claimed the seat that may assert this field? | The claim on the record; the seat | ### 2.2 The policy rule One result, one of four: - **verified** — every identity field was said by the field's authority in the node's table, no two sources differ, every field is inside its clock, and the brand has claimed its seat; - **listed** — the record holds the product for the country, but one of those is missing; - **stale** — a field is past its clock, or a refresh failed; - **unknown** — the record does not hold the product for the country, or the record is not answering. A signature proves who signed and whether the record changed since. The four dimensions say whether to believe it. ### 2.3 Expiry by field | Field | Clock | Rule | |---|---|---| | Barcode | Never expires | The identity. Once bound, bound. | | Identity (name, brand, maker, category, pack) | Long: 365 days | Re-read on the clock or on a brand correction | | Label and claims | Long: 180 days | Re-read on the clock, on a brand correction, or on a regulator change named by the node | | Price, stock, offer | Never verified from the record | Read live from the retailer or the hub, or unknown. A receipt never carries a verified price. | | Any field after a failed refresh | — | Moves to stale or unknown. Never stays verified. | A node may shorten a clock for its market. It may not lengthen one. ## 3. Receipt A receipt is the evidence that a match was verified: under which core version and which market profile, at what time, against which record and which match. The receipt format, its verify rules and the issuer keyring are published at [rco-barcodeverified.org](https://rco-barcodeverified.org). The receipts themselves live with each issuer. | Field | Holds | |---|---| | subject · subject_type | The barcode; `product-match` | | market | The country whose profile applied | | core_version · profile_version | This specification's version and the market profile's version, both pinned so the result can be reproduced after the rules change | | verified_at | The stated time of the check | | answer_hash · match_hash | The hash of the signed record supplied; the hash of the match record | | result | verified · listed · stale · unknown, with the four dimension readings | | prev_hash · hash · seq | The chain | | kid · sig | The issuer's key id and signature; the key id resolves on the keyring | A receipt is never revoked. A later receipt supersedes it and names the one it supersedes. Nothing is deleted. The machine form is [Receipt schema](/protocol/receipt.schema.json). ## 4. Conformance An implementation runs the conformance suite and, passing, is listed on the keyring as an issuer. The suite is listed at [Conformance](/protocol/conformance/). Each node scopes the suite for its market: which cases apply there and the market's own cases. ## 5. Pilot benchmarks The five numbers a lab or a retailer measures in a pilot are published beside this specification at [Benchmarks](/benchmarks/), never inside it. They are what a pilot measures. They are not part of what "verified" means. ## 6. Governance Publisher, version policy, how a profile is added, how a key is retired and how a second publisher would open a consortium are set out at [Governance](/governance/).