Executable

Can a shopping assistant match this exact bag to a catalogue entry?

ALS-COFFEE-1.3-IDENT-001

This question is asked as a test and produces a result for a real page.

Assertion

product_identifier_published is_present true

Applicability

applies when
the product page publishes readable Product structured data
signal
presence of a JSON-LD Product node

Accepted evidence

  • structured_identifier — a GTIN in JSON-LD whose check digit validates after separators are stripped, or an MPN that is not a placeholder and is not the seller's own internal object id for this product

Explicitly insufficient evidence

What does not count, and why. Published because the omission is where a check quietly becomes a claim.

  • a placeholder value such as N/A, TBD, PLACEHOLDER or YOUR-MPN-HERE, in any punctuated or suffixed form
    A merchant filling a required field with nothing is how these values arise, and a value that identifies nothing cannot do the job the row promises.
  • an all-zero GTIN
    All zeros satisfies the check-digit arithmetic and identifies no product, so the arithmetic alone is not a sufficient test.
  • a value with the right length and a wrong check digit
    A mistyped or invented identifier resolves to nothing in any catalogue, so length is not evidence of validity.
  • an internal SKU published in the GTIN field
    A seller-private stock code is not a global identifier and cannot match this product to any external catalogue entry.
  • an identifier that is the seller's own internal object id for this product — the value the storefront also uses as its own product or variant key — published in the MPN field
    This is the same rule as the internal-SKU-in-the-GTIN-field clause in this same list, applied to the field where the defect actually occurs. A seller-private stock code is not a global identifier and cannot match this product to any external catalogue entry. That reason is field-agnostic: it is a statement about the VALUE, not about which key carries it. Scoping it to the GTIN field left the MPN branch accepting any non-placeholder string, including the integer a storefront mints to key its own product record and then republishes as `mpn` — a value that resolves to nothing outside the one store that minted it, which is the precise thing this row's question promises it can do.
  • an identifier stated in prose rather than in structured data
    The engine reads identifiers only from structured data, and prose identifiers are not machine-consumable in the way a shopping assistant needs.

Conflict rules

  • When the GTIN is invalid but a real MPN is present — then the row passes on the MPN alone, and the engine names which identifier it read precedence: structured_identifier
  • When different variants carry different barcodes — then the engine reads the product-level node only; per-variant identity is a known limitation published as a blocked entry

What a pass licenses

A pass establishes: That the page publishes a structurally plausible product identifier that is not a placeholder, is not the seller's own internal object id for this product, and, for a GTIN, has a valid check digit.

A pass does NOT establish: That the identifier is correct, unique to this product, allocated to this seller, or resolvable to any catalogue record anywhere. Nor that the disqualification added at v1.3 was DECIDABLE on this page: the rule is a property of the value — that it is the seller's own key — and it can only be read where the storefront itself publishes that key somewhere legible. A seller-private code that appears nowhere else on the page is indistinguishable from a real manufacturer part number and is not disqualified. A pass is therefore the absence of a disqualification we could decide, never evidence of one we could not.

Discrimination

Measured fail rate: 97.4% (74 of 76 adjudicated)

95% interval: 90.9% – 99.3%, against a 15-85% target band (wilson95 vs target band)

Verdict: Not discriminating — the whole 95% interval lies outside the target band, so almost every store answers the same way. This is evidence for a retirement decision and is not the decision.

Re-measured against the v1.3 wording on an engine that implements it. 74 of 76 adjudicated rows fail, against 72 of 76 before — the two rows that moved are the two whose MPN is the storefront's own product object id. The verdict is unchanged at not_discriminating, and it may still not be acted on as a retirement: it is above the band, and every bias declared on the in-document record still applies.

This rate replaces an earlier one: 94.7% (72 of 76)

It was measured against the v1.2 wording on an engine that did not implement it, and the document declares it a FLOOR in those words. Rule D is the engine change that record says had not shipped; this is the run against the v1.3 wording it says had not been made.

Its verdict was Not discriminating, which is unchanged.

The biases declared on that record, published unedited:

  • deflates fail rate, 3.9474pp
    Measured false-pass rate of this engine on this entry, from the row-by-row audit of the same run (experiments/v3-2/verdicts.json): 3 of this entry's 4 pass rows were confirmed wrong. Correcting them moves rows from pass to fail, so the measured fail rate is BELOW the true one.
  • deflates fail rate, UNQUANTIFIED
    THE REQUIREMENT THIS RATE WAS MEASURED AGAINST IS NOT THE REQUIREMENT THIS VERSION STATES. The measurement was taken against the v1.2 wording, whose `accepted_evidence` qualified an MPN only as "not a placeholder"; v1.3 additionally disqualifies an MPN that is the seller's own internal object id. Tightening what counts as accepted evidence can only move rows from pass to fail and never the reverse, so the measured fail rate is at or below the rate the v1.3 requirement would produce on the same sample. UNQUANTIFIED, and deliberately NOT netted against the audit bias declared beside it: the two overlap — all 3 of this entry's confirmed false passes are of this same class — so summing them would double-count, and no artifact in this repo adjudicates each pass row against the v1.3 wording, because that needs an engine that implements it and an adversarial pass, neither of which ships with v1.3.

⚠️ MEASURED AGAINST THE v1.2 WORDING, NOT THIS ONE, AND CARRIED RATHER THAN RESTATED. This rate was produced on 2026-07-27 by an engine reading the v1.2 evidence rule, and the verdict `not_discriminating` was reached on that looser reading. Against the requirement as v1.3 states it, 94.7368% is a FLOOR. It is carried rather than deleted because deleting a measurement to avoid having to state its scope is how a document ends up with no measurement at all; it is declared as an instrument bias above. THE GRAMMAR'S RE-MEASUREMENT PATH IS DELIBERATELY NOT USED: `supersedes` records a measurement that a REPLACEMENT has displaced, and there is no replacement — no run has been made against the v1.3 wording, and no engine change ships with it. Filing this one as superseded with nothing in its place would delete the only measurement this entry has. Recomputed by `standards/coffee/issue_v1_3.ts` from experiments/v3-2/standard_run3.jsonl through the shipped `verdictFor` in standards/discrimination.ts; no re-run, no network, no spend. Cross-checked against experiments/v3-2/discrimination.json and standards/coffee/v1.0/fitness.json. Every count, rate, interval and verdict above is byte-identical to the record v1.2 published, which this transform re-derives from experiments/v3-2/standard_run3.jsonl and asserts rather than assumes.

Authored expectation: no prediction, confidence low. The numeric band this standard used to carry is not published at this grammar version.

Small roasters overwhelmingly sell without barcodes and Shopify does not require one, so most coffee pages should fail, while packaged-goods sellers reaching grocery channels will have them. The band is high and the upper bound is set at the target limit because a rate above it would carry little information.

The numeric fail-rate band this reasoning was authored with is NOT carried at grammar 1.2 and is not reproduced here. Authored bands held 1 of 10 against this category's own sample and every miss was HIGH, so a direction derived from the band would inherit the error that condemned it (SCHEMA.md §9.3 step 3). The band survives in ALS-COFFEE v1.1 (standard_hash f8ec2780f60c38931913e5b6cd37506500c8462709209de7180ba6691d6137e7), which is byte-frozen and still served.

For a shopper

This is the field that lets an assistant tell your bag apart from a similarly-named one, and it is why searching by product name sometimes surfaces the wrong seller. You can look for it yourself in the page source, though most small roasters publish none.

For a merchant

Publish a valid GTIN or a real manufacturer part number in the Product structured data, and never fill the field with a placeholder, because an unusable value is worse than an absent one for a machine consumer.

Grounding

  • Google Merchant Center product data specification (retailer_help_centre)
    that the dominant product-feed specification treats a global trade item number as the field that identifies a product to an automated consumer, which is what makes its absence a machine-buying defect rather than a cosmetic one
  • GS1 general specifications overview (trade_body)
    that a global trade item number is allocated under a defined numbering system with a computed check digit, which is the basis for validating a published value rather than accepting any digit string