← The field guide

Product compatibility data: prove the exact accessory match

Separate compatible products from related products. Use exact model pairs, revisions, adapters, and source evidence, with a downloadable decision ledger.

The short answer

A related product, matching dimension, or similar model name does not prove compatibility. Identify the exact accessory and target, check an authoritative statement for that pair and revision, and retain required conditions. Record supported, contradicted, or unknown rather than converting missing evidence into a yes or no.

Related products are not necessarily compatible products

A shopper may ask whether a tray fits a stand or whether a replacement part works with an older model. The task is a relationship between two exact products. A category recommendation or a family-level match leaves that relationship unresolved.

Schema.org offers isAccessoryOrSparePartFor for an accessory or spare-part relationship. Its isRelatedTo property expresses a broader relationship. These names describe data; they do not perform a fit test or establish whether the underlying assertion is true. The evidence method below is an editorial proposal, not a Schema.org requirement.

Source: Schema.org: isAccessoryOrSparePartFor; Schema.org: isRelatedTo

Write the pair before reviewing the claim

Capture the accessory identifier, target identifier, target revision, region where relevant, and any required adapter. Retain the source revision and exact location of the compatibility statement. A screenshot or document link without the applicable model details is difficult to reuse reliably.

A useful evidence record names the manufacturer table, specification, or other approved authority for that relationship. Preserve exclusions as well as inclusions. If two sources disagree, send the conflict to the accountable owner instead of selecting whichever statement permits the purchase.

QuestionEvidence to retain
Which two things are being matched?Exact accessory and target IDs, including revision or generation.
Under what conditions?Required adapter, supported configuration, and relevant exclusions.
Who supports the claim?Approved source, document revision, exact section or row, and review date.
What remains unresolved?A named missing fact or source conflict, with the next evidence needed.
Download the fictional compatibility ledger and blank record (JSON)

One document can produce three different decisions

Consider an invented manual stating that Tray A is specified for Stand 01 revision B without an adapter, excludes revision C, and says nothing about revision D. Those are three different evidence states, even though the model family and accessory name are the same.

The JSON ledger preserves the fictional statement and the reasoning for each pair. It is a template for review, not an automated compatibility service. Its null adapter field is accompanied by adapterRequirementKnown so that no adapter required cannot be confused with requirement unknown.

Requested targetDecisionReason
Stand 01, revision BSupported under the stated conditionsThe exact revision and adapter condition are explicit.
Stand 01, revision CContradictedThe source explicitly excludes this revision.
Stand 01, revision DUnknownThe source does not address this revision.

Do not fill the evidence gap with a plausible shortcut

Shared brand, visual similarity, matching outer dimensions, or frequent co-purchase can help locate candidate evidence. They do not settle the relationship. A revision can change a connector, interface, mounting pattern, or required part while preserving a familiar name.

Compatibility assertions should also keep direction and conditions. A statement that one accessory is intended for a target is not a license to substitute every related accessory. Do not generalize an accepted pair into an entire model family.

Make the agent’s answer auditable

For a supported pair, state the exact products, applicable revision, conditions, and source location. For a contradiction, identify the specific exclusion. For an unknown, identify the missing information and the source needed to resolve it. Do not summarize all three outcomes as a generic low-confidence recommendation.

Before publishing a product relationship or recommending an accessory, inspect the current source and the selected items. This ledger does not assess physical installation, certify fit, or replace manufacturer instructions. Its job is to prevent an unsupported match from quietly becoming a catalog fact.

Sources & scope

Primary references checked for this edition. The notes below distinguish source-backed facts from the frameworks and examples proposed in this guide.

  1. Schema.org: isAccessoryOrSparePartFor ↗

    Defines an accessory or spare-part relationship. It does not validate the claim; the ledger and decisions are original editorial examples.

    Checked September 20, 2026
  2. Schema.org: isRelatedTo ↗

    Defines broader product relatedness. It is not equivalent to an explicit compatibility relationship.

    Checked September 20, 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. Product compatibility data: prove the exact accessory match iamgeorgekelly. Updated September 20, 2026. https://www.iamgeorgekelly.com/field-guide/product-compatibility-evidence

Keep the source notes and example labels with an excerpt. For a provider requirement, follow the original documentation in Sources & scope.

Choose your next task ↗ · Browse the source directory ↗

Keep going

SKU vs GTIN: differences, barcodes, and variant IDsProduct dimensions vs package dimensions: compare units safelyDoes the product page match the variant you submitted?