The short answer
In five deliberately authored source/feed pairs, all ten individual records cleared the selected local review. Comparing the paired snapshots produced one match, one price update and three holds. A record-level pass does not establish agreement, current evidence or known stock. These are synthetic counterexamples, not merchant error rates or provider acceptance tests.
Two checks answer different questions
This casebook composes two existing local tools instead of adding another product-feed validator. The first reviews each full product record independently. The second compares source and feed snapshots. The original observation is the disagreement between their decisions on the same deliberately authored inputs.
The single-record stage runs reviewInput with method copy and empty supplied evidence. It checks a selected canonical-field and positive-USD subset. It does not compare the two records, retrieve their URLs or read their capture times. All ten records contain an explicit positive sale price below the regular price. No mapping is applied.
| Stage | Input | Question answered |
|---|---|---|
| Single-record review | One product object at a time; no external evidence | Does this record trigger an issue in the selected local rules? |
| Snapshot comparison | A paired selection of item ID, price, sale price and availability, with observation times | Do the comparable supplied facts agree within the chosen evidence policy? |
Source: George Kelly: executable single-record product review, version 1.1.0
Keep the comparison protocol explicit
The runner selects exactly item_id, price, sale_price and availability from each full record. It preserves every value, including leading zeros and unknown availability. It adds no defaults. Each side carries its own supplied capture time and fictional evidence reference.
Every pair is evaluated at the frozen reference time 2026-09-21T16:00:00Z, with a chosen maximum observation age of 24 hours. That is the casebook policy, not a provider deadline. Each snapshot contains one item. The existing checker profile is named openai-native-stable; using that label does not test a provider upload contract.
The checker returns match, update_needed or hold. A hold suppresses proposed changes. Comparison evaluates only the selected fields; a match still leaves the product description, image and other omitted facts outside its scope.
Download the existing snapshot comparison module (.mjs)Source: George Kelly: executable feed snapshot comparison, version 1.0.0
Observed results: ten record passes, one snapshot match
The recorded local execution returned clear for both individual records in every pair. The paired comparison returned one match, one update_needed and three holds. The table gives the complete five-pair denominator; counts describe this constructed set only.
A clear result means no issue in the named single-record checks. It does not mean the record is true, fresh, accepted by a provider or safe to publish. The source and feed labels are supplied roles, not authenticated authority.
| Case | Source / feed record review | Paired comparison | Decisive evidence |
|---|---|---|---|
| C00 · Matching control | clear / clear | match | Same values, exact ID and recent supplied observations. |
| C01 · Different current sale price | clear / clear | update_needed | Source says 12.00 USD; feed says 14.00 USD. Both are below the 18.00 USD regular price. |
| C02 · Matching but old observations | clear / clear | hold | Both captures are 48.5 hours old at the reference time; policy permits 24 hours. |
| C03 · Different exact item IDs | clear / clear | hold | The source ID 00127 is not the feed ID 127. |
| C04 · Matching unknown availability | clear / clear | hold | Both records say unknown; equal uncertainty does not establish known stock. |
Inspect the authored inputs before interpreting the result
The fixture file contains five complete pairs, expected decisions and the fixed comparison protocol. C00 is a control. C01 through C04 are selected counterexamples, not records sampled from a merchant catalog. Products, sellers, URLs and evidence references are fictional.
The sale-price case changes only the source sale_price from the control. The stale case changes capture times. The identity case changes exact IDs. The availability case changes both values to unknown. Keeping the other conditions stable makes each contrast inspectable.
Expected outcomes and execution observations are stored separately. The same author selected the cases and the local checks, so this is a reproducible worked experiment rather than independent validation. No model was called and no destination received a feed.
Download all five paired inputs and expected decisions (JSON)Interpret each result at its actual scope
C01 isolates a consistency problem: two amounts can each satisfy the local monetary rules while disagreeing about the same current sale. The runner reports the field difference; it does not prove that the supplied source price is authoritative.
C02 and C04 isolate evidence problems. Matching old observations do not become current by agreeing. Matching unknown values do not become known by agreeing. C03 isolates identity: a comparison must resolve the exact item before treating its price or stock as a competing value.
C00 is deliberately limited too. The selected inputs agree under the local rules, but every fact is synthetic and every evidence reference is unauthenticated. A control match cannot establish a live offer or destination acceptance.
Reproduce the complete result locally
Save five files in one folder: product-data-conflict-casebook.mjs, product-data-conflict-cases.json, product-data-conflict-results.json, product-feed-review.mjs and feed-freshness.mjs. The first three are the casebook runner, fixtures and saved results; the final two are the existing comparison modules linked above. Use Node.js 22 or later.
Run node product-data-conflict-casebook.mjs to print the full report. Run node product-data-conflict-casebook.mjs --check to compare it with the recorded result. The commands perform no network requests and write no files. The runner needs both shared modules alongside it.
The output records rule versions and SHA-256 hashes of the fixtures, runner and both modules. It uses the supplied frozen reference time rather than the current clock, so unchanged files produce the same report. A source change causes --check to fail even if the five decisions remain the same; inspect that change before recording another edition.
Exit code 0 means execution or exact replay verification succeeded. It does not mean all product comparisons matched: the published result intentionally includes update_needed and hold. Exit code 1 indicates a command, file, parsing or replay-verification error. This runner reproduces the fixed casebook; use the linked freshness guide to prepare a check of your own data.
Download the casebook runner (.mjs; needs the four files named above)Use the result as a regression case, not an error-rate claim
This result supports a narrow engineering conclusion: passing these single-record checks is insufficient to establish agreement under the paired comparison rules. It does not estimate how often merchants have these problems, prove which source is right or compare AI systems. Reporting four nonmatching pairs as a real-world failure percentage would misuse the deliberately selected cases.
A real operational study would need authorized independently selected records, retained source captures, declared decision criteria, a separate reviewer and observable destination results. Those measurements have not been performed here. Preserve the synthetic edition when adding real evidence so that the denominators and claims remain distinct.
First edition: September 22, 2026. The article, frozen inputs and executable result describe the same five-pair casebook.
Sources & scope
Primary references checked for this edition. The notes below distinguish source-backed facts from the frameworks and examples proposed in this guide.
- George Kelly: executable single-record product review, version 1.1.0 ↗
Primary method artifact executed in this casebook. Defines the selected record checks; it is not provider documentation or independent validation. Exact bytes are identified in the recorded result.
Checked September 22, 2026 - George Kelly: executable feed snapshot comparison, version 1.0.0 ↗
Primary method artifact executed in this casebook. Defines exact-ID, USD, evidence-age and availability rules. The 24-hour limit is chosen for this experiment. Exact bytes are identified in the recorded result.
Checked September 22, 2026
AI-assisted research and drafting. Provider-specific claims link to primary sources. Frameworks are editorial proposals; worked examples are illustrative and are not employer performance results.
Editorial policy & corrections ↗Cite this guide
George Kelly. Why a product feed check can pass while the records disagree iamgeorgekelly. Updated September 22, 2026. https://www.iamgeorgekelly.com/field-guide/product-data-conflict-casebook
Keep the source notes and example labels with an excerpt. For a provider requirement, follow the original documentation in Sources & scope.