---
name: "product_compatibility_checks"
description: "Check product compatibility before a recommendation or sale: build a compatibility matrix from model numbers, dimensions, versions and connector types, parse a customer item into the fields the matrix needs, run the fit check with hard blocks and soft warnings kept separate, and state what was not verified instead of guessing a fit. Use when asked if a part, case, cable, charger, accessory or component fits, works with, or is compatible with a specific model, vehicle, device or system."
---

# Product Compatibility Checks

## Purpose

Answer one question honestly: does this candidate work with this specific host item, on evidence, field by field. A compatibility answer is a claim a buyer spends money on, so it needs the same discipline as any other factual claim. Build the matrix from maker sources, parse the customer item into the fields that matrix needs, run the check, and report blocks, warnings and unchecked fields as three separate lists. When a hard field was never checked, the answer is unverified, not probably fits.

## Workflow

1. Name the pair. Write down the host (the customer item the candidate must work with) and the candidate (the part, accessory or product being considered). One pair per check. A verdict for one candidate says nothing about the next candidate on the shelf.

2. Parse the host first. Build the host record before looking at candidates, using the field order in `references/matrix-and-parsing.md`: exact identifiers, physical fields with units in the field names, connector split into shape, protocol and power, version fields, qualifier fields, and the buyer requirement fields. Leave a field out when you do not have it. Missing is a state the check can report, a guessed value is a false result.

3. Build or load the matrix. One row per acceptance rule per candidate, in the format in `references/matrix-and-parsing.md`, starting from `assets/compatibility-matrix-template.csv`. Every row carries a source and a check date. Maker fitment lists, maker spec sheets, standards body databases and, for vehicle parts, ACES shaped fitment data (year, make, model plus qualifiers) are sources. Marketplace listings, reviews and forum posts are leads for where to look, never sources for a row.

4. Set severity before running anything. Hard for identifiers, geometry, electrical limits, protocols the job depends on, and anything where a wrong fit causes damage. Soft only for features the buyer called optional in their own words, cosmetic matches, and tested-on limits where the maker has not claimed incompatibility. Write the reason in the row note. If you cannot tell, treat the row as hard.

5. Run the check. Use `bin/fit_check.py` with the matrix CSV and the host JSON:

   python3 bin/fit_check.py --matrix assets/compatibility-matrix-template.csv --host host.json

   Add `--candidate <candidate_id>` to check one candidate. The script normalises case and spacing, compares numbers numerically, and does no fuzzy matching, on purpose. Read the per field output, do not just read the verdict line.

6. Read the verdict the way the script defines it. COMPATIBLE means every hard row passed with no soft warnings. CONDITIONAL means no hard block and nothing hard left unchecked, with soft warnings the buyer must hear. NOT_COMPATIBLE means at least one hard row failed, however many rows passed. UNVERIFIED means a hard field could not be checked. Unverified is a final answer for this run, not a soft yes.

7. Fill the gaps you can, then stop. If an unverified field can be settled from a maker page, a certifying body database or one question to the customer, settle it and rerun. If it cannot be settled in this run, report it as unverified and name exactly what would settle it, for example the model number from Settings, General, About on an iPhone, or the engine code on a vehicle record.

8. Report in the Output Contract order. Blocks first, then warnings, then unverified fields, then sources. Never lead with a pass count. Five passes and one hard block is a not compatible result, and phrasing it as mostly compatible misleads the buyer.

Worked runs with real script output, one for a parts store and one for a phone accessory store, are in `references/worked-examples.md`. Read them before your first live check.

## Output Contract

For each candidate checked, deliver:

- Verdict: one word, COMPATIBLE, CONDITIONAL, NOT_COMPATIBLE or UNVERIFIED.
- Hard blocks: each failing hard field, with the host value, the accepted value, and what it means in plain words.
- Soft warnings: each failing soft field, kept separate from the blocks, with the decision it puts in front of the buyer.
- Not verified: each hard field that could not be checked, and the specific thing that would settle it.
- Evidence: the source and check date for every row that decided the verdict.
- Next step: the candidate to check next, the question to ask, or the lookup to run. One concrete step, not a general offer to help.

For a matrix building job with no live customer, deliver the matrix CSV, the field list it needs from a host record, the source for each row, and a note naming the fields you could not source.

## Operating Rules

1. Connector shape is one field. A USB-C plug that fits says nothing about data protocol or power delivery, which are separate specifications with separate limits. Check shape, protocol and power as three rows with three sources. The same split applies anywhere a single word hides several facts, such as wireless, smart or universal.
2. Identifiers match exactly or they do not match. Marketing name, model name, part number and model number are different fields. Region variants can share a marketing name and differ by model number. Never merge identifiers to make a check pass, and never accept a close model number as the same product without a maker document saying so.
3. Dimensions are a set, not a size. Screen diagonal is not a body dimension. A fitted product needs every relevant measurement plus layout fields such as camera position, buttons and ports. One matching measurement is evidence for that row only.
4. Qualifiers decide real fitments. Year, make and model style lookups are a starting filter, in auto parts and everywhere else. Engine, drivetrain, trim, revision, region and handedness fields are where wrong parts get sold. Ask for them by name, customers rarely offer them unprompted.
5. Certification claims get a database lookup by exact model number. A logo word or a listing claim is not a record. A missing record is reported as not verified. It is not reported as a pass, and it is not reported as proof the product is uncertified.
6. Severity is set from the buyer stated need before the check, and never changed after a result to make the result easier to sell. If the buyer upgrades a nice to have to a requirement mid conversation, change the row, rerun the check, and show both runs.
7. State what was not verified, every time. Name the field, not a general disclaimer. A compatibility claim needs a reasonable basis before it is made, so an unchecked hard field ends the claim, not the conversation. Offer the lookup or the question that settles it.
8. Sources outrank listings. Maker of the host, maker of the candidate, then standards and certification bodies, then retailer fitment tools as a cross check. When two maker sources disagree, the field is unverified and both sources are named. Do not resolve a disagreement by picking the answer the customer wants.
9. Keep example data labelled. Sample matrices and worked examples in this skill use invented example values to show the logic. Never copy an example row into a live matrix, and never quote an example value to a buyer as a real product fact.
10. Plain language in the report. Name the field and the values, skip jargon the buyer has not used, and give the reason a block matters (the cutout lands wrong, the engine differs, the cable carries a slower protocol) instead of a bare code or score.