Input: an authorized catalog export, the receiving platform's current contract, and a bounded sample of public product destinations. Output: a validation report. Do not submit feeds, alter listings, or create purchases as part of a read-only review unless separately authorized.
Pin the receiving contract
Record platform, account environment, field specification, file format, and review date. The same concept can have different field names and units across providers. A valid merchant file is not automatically a valid commerce-protocol message or Schema.org record.
The human feed guide includes an example based on OpenAI's file-upload contract. Use the current official specification for ingestion, not our example as an exhaustive validator schema. Never infer that a required field is optional because a different provider permits omission.
Validate individual records
Check required fields, types, permitted values, unique identifiers, URL format, currency units, and non-empty descriptions. Match the item identifier to a purchasable variant. Flag unknown values explicitly rather than replacing them with plausible defaults.
Validate semantics as well as syntax. A price of zero may parse correctly while being commercially wrong. An in-stock flag can be valid vocabulary but stale information. A valid image URL can point to a different color or bundle.
Validate relationships and updates
Check variant families for stable grouping and distinct purchasable identifiers. Compare create, update, and withdrawal behavior against the receiving platform's actual contract. Ensure a partial failure cannot silently clear required values or duplicate the same item under a new identifier.
Trace each field to its authoritative source. Record export time, source update time when available, and platform acknowledgment time separately. Successful transport does not establish acceptance; acceptance does not establish display or recommendation.
Inspect a bounded destination sample
Include a normal product, multiple variants, a promotion, an unavailable item, and a withdrawn item where applicable. Confirm the landing page preserves identity, quantity or size, current offer, and the correct next step. Inspect the visible facts and any structured record for contradictions.
Do not complete a live checkout merely to validate a public listing. Use an authorized test environment or stop at the commitment boundary. Record the untested portion clearly so the report cannot be mistaken for a transactional certification.
Example report
{
"example": true,
"platform_contract": "not_selected",
"export_id": "example-export-001",
"checked_at": null,
"records_total": null,
"records_valid": null,
"platform_acceptance": "not_checked",
"destination_sample": [],
"findings": [
{
"item_id": "example-variant",
"check": "price_agrees_with_destination",
"result": "not_run",
"evidence": [],
"owner": null
}
],
"checkout_execution": "not_authorized_or_tested"
}Report structural failures separately from semantic discrepancies and uncollected evidence. A partially sampled destination set does not establish accuracy for the entire catalog. Keep a denominator for every rate and identify exclusions.
Repair and recheck
Fix the upstream source when possible, regenerate the affected record, and inspect the platform's response. Recheck the destination sample after a change that affects mapping or variant selection. Preserve failed records and rejection messages in an appropriate private operational log.
The output should identify the item, conflicting values, source of truth, proposed repair, owner, and verification step. Do not collapse these observations into an “agent trust” grade. Actual discovery and orders require their own evidence.