A compatibility matrix connects a specific accessory to a device model and generation, showing exceptions and confirming evidence. Build it from documentation, distinguishing confirmed, conditional, incompatible and unverified combinations.
Define the relationship
Choose one accessory and the models whose fit you want to verify. Record accessory identifier, device model, generation and relevant variant. Similar names or appearances do not establish compatibility.
The matrix answers “Does accessory A work with device B in variant C?”. It does not replace a complete product page or offer comparison. Parameters unrelated to fit stay in ordinary documentation.
Collect evidence and verification ownership
For every combination, find manufacturer documentation, an official compatibility list or a controlled test documented by an appropriate specialist. Record document URL or identifier, version, date and verifier.
A customer ticket can reveal an exception, but should not automatically prove compatibility across a generation. Confirm that customer's exact model and variant first. Do not extend a single test to devices that were never checked.
Use four explicit states
- Compatible: evidence confirms the stated combination.
- Conditionally compatible: a named condition, such as a particular adapter, is required.
- Incompatible: lack of fit is confirmed for this combination.
- Unverified: available evidence is insufficient.
Unverified means neither compatible nor incompatible. Do not replace it with a default “fits”. Put any condition in the same row so it cannot disappear elsewhere on the page.
Build a model, generation and exception row
A minimum row includes accessory, device, generation, variant, state, condition or exception, source and verification date. Preserve manufacturer identifiers. A shop code may supplement, but should not replace the model name customers need.
Fictional example: A1 fits M1 generation G1. M1 G2 requires adapter AD1. M1 G2-R is incompatible. M2 is unverified. These combinations receive four separate rows.
A real matrix needs evidence for every state. Do not publish the fictional example as actual compatibility. If a source names only the model, ask for generation clarification rather than filling the gap by guesswork.
Place exceptions beside the fit claim
Beside “fits M1”, state which generations were verified. Name the required component or configuration for conditional fit. A link to the full matrix should reach the relevant accessory table.
When publishing the same data in several places, update from a shared evidence set. Separate pages for every combination are unnecessary merely to repeat one row. A visible table and clear explanation can answer this need in one place.
Verify and maintain history
Before saving, check one positive, negative, conditional and unverified combination. Ask the owner to compare each with documentation. Watch for similar names, generation changes and regional variants.
When documentation changes, update affected rows and retain the change date. Translate labels and explanations without changing identifiers or state meaning. Another language is not a new compatibility confirmation.
The outcome is a verifiable answer about one device-accessory combination. In AI answer tests, evaluate that combination's state and condition; a product mention alone is insufficient.
