Separate the sellable SKU, vehicle, and fitment layers
A SKU is the item a customer can buy
Automotive catalogs become difficult to maintain when the item being sold and the vehicles it may fit are stored as one fact. A sellable SKU should describe the physical or digital item that can appear on an order: price, barcode, package, images, fulfillment relationship, inventory item, and the variant a customer can select. It answers “which item will be purchased?” It does not answer “which vehicles could ever use this item?” One brake pad SKU can relate to many vehicles, while one vehicle can accept several brands, materials, or package sizes.
Keep the stable key for the product and variant separate from a title that may change for language, merchandising, or legal review. A year or model name in a title is useful for reading, but it is not evidence of compatibility. The SKU must continue to point to the correct inventory item and order line when a label changes. Price, barcode, package instructions, images, and fulfillment rules belong to the sellable object so that an order, return, or support question can be reconstructed from the same product facts.
A vehicle is a normalized identity
A vehicle is the object that a part may fit, not a product option. A useful vehicle record can distinguish manufacturer, family, model, year or year range, trim, engine, body, drivetrain, market, regional name, and aliases. The same visible model name may refer to different engines or chassis in different years and markets. Free text such as “2020 X,” “X 2020,” and “X EU” should not become three values that a filter treats as interchangeable.
Give each vehicle a stable normalized key, a localized display label, and a controlled alias set. The key is for matching, the label is for customers, and aliases are for search and discovery; none should silently replace the others. If a vehicle data provider renames a model, splits a year range, or withdraws a record, create a new version or an invalid state. Do not quietly rewrite the identity that an earlier order displayed. Market, language, and time context should be stored explicitly rather than inferred from a model name.
A fitment assertion is an evidenced relationship
A fitment assertion connects a sellable SKU or variant to a normalized vehicle. It should carry the evidence reference, source version, effective period, review time, exclusions, confidence state, and owner of the review. Shopify can hold products, variants, inventory items, locations, and structured custom data, but it does not supply a native automotive fitment database merely because a merchant creates variants or tags. A reliable fitment experience requires an external or internally governed vehicle vocabulary, explicit relationship data, and a tested presentation layer.
Use this ownership table as an early design contract:
| Object | Question it answers | Facts to store | Responsibility it must not absorb | Primary reviewer |
|---|---|---|---|---|
| Sellable SKU or variant | What exact item can be purchased? | Price, barcode, package, media, fulfillment, and inventory reference | It must not infer the complete vehicle set | Merchandising and inventory owner |
| Vehicle identity | Which normalized vehicle is being selected? | Make, family, model, year, trim, engine, body, drivetrain, market, and aliases | It must not claim stock or delivery | Catalog data owner |
| Fitment assertion | Why is this item related to this vehicle? | SKU reference, vehicle reference, evidence, version, dates, exclusions, and review state | It must not replace order, payment, stock, or legal checks | Product and data owner |
Establish authoritative facts and stable keys
Record the system and person responsible for each fact
Begin with a fact-ownership map before choosing a filter app. The Shopify catalog can be authoritative for products and variants; inventory quantities come from inventory items and their location levels; a vehicle vocabulary may come from a licensed provider; and fitment assertions may come from a manufacturer catalog, installation manual, distributor feed, or an internal review. For every field, record who owns it, how it is refreshed, what delay is acceptable, what makes it stale, and how it can be withdrawn. If two systems claim authority, define a conflict rule and a review queue rather than letting the last file overwrite the first.
Every incoming relationship should carry a source name, source version, received time, original record reference, parsing state, and evidence location. “The supplier says it fits” is not enough as a durable explanation. An auditor or support person should be able to locate a catalog entry, manual passage, batch, or recorded review. If the supporting file is private, expose only a reviewed summary on the customer page and keep private addresses, customer identifiers, and unnecessary internal notes out of the public model.
Assign stable keys to vehicles and relationships
Use controlled values for make, family, model, trim, engine, body, drivetrain, and market. Store them as separate fields with a normalized key instead of using a long display string as the matching key. An alias table may support search and regional naming, but an alias change should not break the underlying vehicle key. If two regions use different names for an otherwise related vehicle, link the aliases with market context and show the appropriate label while retaining the original source wording.
A relationship key can combine a SKU or variant reference, a vehicle reference, a source version, and a relationship version. Duplicate imports should be recognized from this stable key. Exclusions, alternatives, and installation conditions should be separate properties rather than hidden inside a single Boolean named fits. A relationship with incomplete evidence should be unknown or needs_review; it should never be promoted to a positive answer simply to make a selector return a result.
Preserve history with version and validity fields
Give each relationship valid_from, valid_to, reviewed_at, and source_version fields. These mean different things: the effective period is when the business relationship applies, the end period is when it stops applying, the review time is when a person or process last checked it, and the source version identifies the material used. When an order is placed, the displayed vehicle and fitment result should be recoverable from the relationship version and the order snapshot. Updating a relationship must not rewrite the item, address, or customer selection stored on an earlier order.
When engine, year, or vehicle naming conflicts, put the relationship into a review queue and decide whether it should be paused. Do not let a newly received file overwrite older evidence without comparing trust, business time, and source version. The contract should state priority, review timing, pause conditions, and restoration evidence. Restoration should run the positive-fit, explicit-exclusion, and no-match cases again, because a repair that only checks one positive example can reintroduce a broad false match.
Choose a data model without putting compatibility into variants
Use products and variants for real purchase choices
Variants are appropriate when a customer is choosing a real sellable difference such as size, material, connector, finish, or package quantity. Shopify documentation currently describes a default limit of 2,048 variants per product and no more than three options; individual themes, apps, and channels may support a smaller practical set, including differences around 100 variants. A platform limit is therefore not a promise that every storefront surface can render, filter, price, and fulfill that many choices.
If year, model, engine, and trim are enumerated as variants, the catalog grows as a mathematical combination instead of as a list of evidenced relationships. Prices, inventory, images, channel feeds, and checkout choices then inherit relationships they were never designed to own. A variant should exist because a distinct item or package is sold, not because a vehicle vocabulary has many values.
Use reusable objects for vehicles and fitment
Fitment is normally many-to-many: one part can fit many vehicles, and one vehicle can accept many parts. A reusable vehicle object can hold the normalized identity. A fitment object can hold the relationship, evidence, restrictions, and status, while a product or variant metafield points to the relevant relationship. This is a modeling pattern built on Shopify capabilities; it does not mean Shopify ships a manufacturer-maintained automotive database.
The decision table below keeps object ownership explicit:
| Need | Product or variant | Vehicle metaobject | Fitment assertion | Reason |
|---|---|---|---|---|
| Choose a real sellable specification | Suitable | Not the owner | Not the owner | The choice needs price, barcode, inventory, and fulfillment |
| Store make, model, year, and trim | Not suitable | Suitable | Referenced by the relationship | A vehicle identity should be reusable |
| Relate one part to many vehicles | Creates excessive combinations | Referenced object | Suitable | A relationship is not a sellable option |
| Store exclusions or installation conditions | May become unstructured copy | Can store identity context | Suitable | Evidence and restrictions need versioning |
| Control stock and market availability | Suitable with catalog controls | Provides context | Cannot guarantee availability | Compatibility, market, and stock are separate gates |
Avoid a vehicle-and-part Cartesian product
Before importing, count real products, normalized vehicles, and evidenced relationships independently. Each SKU should reference only vehicles supported by an actual source. A vehicle may have many relationships, but each relationship must explain its evidence and conditions. If a manual supports one engine, body, or production month, preserve that constraint in the relationship; do not duplicate it across an entire year merely because the selector is easier to populate.
Test theme and channel constraints early
The productVariantsBulkCreate mutation can create variants and variant metafields, but it requires the relevant product and staff permissions. A successful mutation is not catalog acceptance. Test the actual theme, application, and sales channels for selection, add-to-cart behavior, price, inventory display, and order-line clarity. When a channel cannot render a large variant set, use a controlled selection or relationship layer while ensuring that the final order still references a real SKU and a reviewable vehicle choice.
Design the metafield and metaobject contract
Define the minimum vehicle metaobject
A vehicle metaobject can contain a normalized key, make, family, model, year start and end, trim, engine, body, drivetrain, market, localized display name, aliases, and source version. Use typed definitions and controlled values where available. A display label may be translated, but the matching key must remain stable across languages. Unknown data should remain unknown or missing; a guessed engine or trim is not a safe default. A precise year interval and an approximate “around 2018” statement should not enter the same exact-match rule.
Define evidence fields on each fitment
Each fitment object should reference at least one sellable SKU or variant and one vehicle object. Add relationship status, evidence type, evidence reference, source version, effective and review times, exclusions, installation notes, market scope, reviewer, and invalid reason. When multiple documents support a relationship, retain their individual states and let the rule layer determine what can be shown. A confidence field describes the strength of the current evidence; it is not a promise of installation success, shipping, legal suitability, or stock.
Expose only fields a customer needs
Metafields extend existing Shopify resources, while metaobjects define reusable structured entities. A Liquid theme can read permitted custom data, and a headless storefront can expose selected fields through the Storefront API. Publish only the vehicle label, relationship state, review date, conditions, and necessary warnings. Keep supplier credentials, internal file paths, private notes, and unnecessary personal data out of customer output. When an app is reinstalled, locate definitions by a stable namespace and key rather than assuming an internal definition reference will never change.
Use this field-level contract during schema review:
| Field group | Example fields | Type and rule | Customer exposure | Invalidation behavior |
|---|---|---|---|---|
| Vehicle identity | make, model, year_from, year_to, trim, engine | Controlled text, integer years, normalized key | Localized label and needed filter values | Missing a required field prevents exact matching |
| Relationship reference | variant_ref, vehicle_ref, fitment_status | Reference, enum, versioned relationship key | Fit, needs review, or does not fit | Unknown never becomes a positive result |
| Evidence | source_name, source_version, evidence_ref, reviewed_at | Short reference, version, timestamp | Safe public summary only | Withdrawn evidence pauses the relationship |
| Conditions | exclusions, installation_note, market_scope | Array or structured text | Shown before purchase and installation | A failed condition routes to review |
| Operational audit | owner, created_at, updated_at, invalid_reason | Owner and timestamps | Kept private | Retain the minimum audit trail |
Limit access before connecting the storefront
Include data definitions, application permissions, and theme read paths in the acceptance checklist. Record the scope, operator, version, and result for create, update, and delete actions. An error that exists only in a developer terminal cannot support a customer or reviewer. For a headless implementation, first check that the Storefront API returns only safe fields, then check filters and detail pages. For Liquid, test empty arrays, missing references, expired relationships, and long labels so that the page remains understandable.
Make imports, backfills, and replay reviewable
Start with a small, observable baseline
Split a historical backfill into observable batches. For each batch retain source version, start and end time, input count, accepted count, rejected count, parsing errors, and the input checksum. Begin with one SKU and a small vehicle set that exercises a positive fit, explicit exclusion, no match, and many-to-many links. Reconcile product, vehicle, and relationship counts before exposing a batch. Only a complete batch that passes the checks should become visible.
Batch processing is not a guarantee that every line succeeded. A download may expire, permission may change during a job, or one record may be malformed. Preserve the task reference, original file checksum, and parsing summary as soon as the file is received. If only some lines can be read, quarantine that batch and call it partial. A failed range should be replayable from the same input without creating duplicate relationships.
Make duplicate and out-of-order events idempotent
Deduplicate by the stable relationship key, then compare source version and business effective time. An older document that arrives later must not erase a newer fact. At the same time, arrival time alone is not enough: business time, source generation time, and receipt time can differ. Retain occurred_at, received_at, and loaded_at, and state which time the rule uses. A missing event, parse failure, or overdue refresh should trigger a bounded repair interval rather than an unbounded retry loop.
Reconcile rejected rows separately from accepted rows
Keep the original row reference, error category, minimum key, and retry relationship for every rejection. Typical errors include an unnormalized vehicle field, a reversed year range, missing evidence, a deleted SKU, an unknown market, or a reference to an object that does not exist. Reconciliation should compare source rows, metaobjects, product and variant references, and the storefront result. Equal counts are not proof of correctness; sample positive, excluded, and no-match paths as well.
Design the year, make, model, and trim selection journey
Move from a broad vehicle choice to an exact relationship
The customer flow should narrow the vehicle identity first, query fitment second, and apply catalog status third. If the first choice is a year followed by make and model, label each value as a filter or a confirmed part of the vehicle identity. The result should show the complete vehicle label, relationship review time, evidence summary, and conditions instead of only a green icon. Keep the selected vehicle context with the add-to-cart action so support, returns, and the order line refer to the same choice.
Handle names, ranges, and markets that differ
An inclusive year range must not silently include years for which no source provides evidence. If trim, engine, body, or drivetrain is missing, return a review state rather than assuming the most common configuration. The same model name may describe different specifications in different markets, so select the market context before presenting the final vehicle identity. When a model is renamed, let aliases assist search while the details view shows the normalized name and market context.
Give an unknown result a safe next step
No match is a safety state, not a reason to invent a likely part. Offer a new selection, a visible evidence explanation, a manual review route, or a VIN/manual check when the merchant's process supports it. Record only the vehicle fields, item, evidence version, and expiry needed for that review. Do not collect a complete address or an unnecessary identifier simply because a support form can accept it. An answer that is “needs review” is safer than a confident answer built from a partial vehicle name.
Put Search & Discovery limits into the design
Check filter counts and result ranges
Shopify Search & Discovery supports standard filters and custom filters based on product options, product metafields, variant metafields, and eligible metaobject references. The supplied first-party documentation currently describes limits of up to 25 configured filters and up to 100 displayed values per filter. It also describes cases where filters are unavailable for collections above 5,000 products or searches above 100,000 results. These are documentation facts to verify again before a release, not a reason to assume a particular theme will behave the same way.
Measure the real number of makes, models, years, and trims that a customer can encounter. If the value set is too large, group by a normalized hierarchy or use a relationship query. Do not shorten values until two distinct vehicles become indistinguishable. A visible count and an empty-state explanation help a customer understand whether no relationship exists or whether the filter surface has reached a display limit.
Do not mistake AND and OR for dependency
Different filters commonly combine with AND, while several values in one filter commonly combine with OR; some filter types offer an AND configuration. Four flat filters therefore do not automatically create a dependent “year then make then model then trim” selector. The interface must recalculate valid values or use a dedicated relationship query that understands vehicle identity and fitment conditions. Empty, expired, or market-hidden values need a clear state rather than silently disappearing.
Know when a dedicated search layer is needed
When the relationship requires ordered selection, interval intersection, exclusions, evidence version, or complex aliases, standard filtering may not be sufficient. A custom app or search layer can normalize the input and query the relationship, but it must still map the final result to a real product, variant, and relationship reference. It cannot bypass application permissions or expose unchecked supplier fields. Test a theme without filter support, an oversized collection, an oversized result set, a missing value, keyboard navigation, mobile layout, and a no-match fallback.
Check inventory and market availability after compatibility
Treat compatibility and inventory as separate gates
“Fits this vehicle” means that the relationship layer has evidence. It does not mean that the item is stocked at the needed location, published in the customer's market, priced correctly, deliverable, or legally suitable. Conversely, inventory does not prove that a part can be installed. Resolve fitment first, then check catalog publication, market, location, fulfillment, delivery, and order state. The page may truthfully say “fitment is confirmed, but this market currently has no sellable stock” without collapsing the two facts into one status.
Interpret inventory by location and state
Each ProductVariant has a one-to-one InventoryItem relationship, and inventory levels connect that item to locations. Shopify documentation describes states such as available, on-hand, committed, reserved, damaged, safety stock, and quality control. They are not interchangeable quantities and should not be added as if they describe the same promise. Cart and checkout events can change committed or reserved values. When stock changes during checkout, the process should recheck the current quantity and fulfillment location instead of treating a confirmed fitment as a stock reservation.
Put market catalogs into the acceptance matrix
Markets can affect language, currency, product availability, prices, and storefront settings. A catalog determines whether a product is published for a market and what price context applies. A relationship that is valid globally does not make the product visible in every market. A product excluded from a market may redirect a direct visit to the home page, so test search, collection, direct URL, price, stock, delivery, and local messaging together.
The following matrix keeps the facts separate:
| Scenario | Fitment result | Inventory and location | Market catalog | Customer result | Acceptance focus |
|---|---|---|---|---|---|
| Confirmed fit and sellable | Fits | Available at a valid location | Published | Show item, vehicle context, and purchase action | Keep vehicle selection on the order line |
| Confirmed fit but no stock | Fits | No available quantity or only reserved stock | Published | Show out-of-stock, substitute, or alert path | Do not turn fit into a negative result |
| Fits but market is unpublished | Fits | Stock exists elsewhere | Unpublished | Explain market restriction and support path | Check collection, search, and direct visit |
| Does not fit but is stocked | Does not fit | Available | Published | Block an unsafe purchase and explain evidence boundary | Inventory cannot override fitment |
| Evidence is incomplete | Needs review | Any state | Published | Offer manual or manual-based verification | Do not invent a positive result |
| Stock changes at checkout | Fits | State changes during checkout | Published | Recheck quantity, location, and price | Record final order facts |
Show evidence, installation guidance, and accessible states
Put evidence and warnings where the decision happens
Near the price and purchase action, show the selected vehicle, fitment state, review time, conditions, and exclusions. An evidence summary may link to a public manufacturer catalog or manual, but it should not expose private file paths, supplier credentials, or customer notes. A review state should be written in words rather than represented only by color. Fitment warnings, stock restrictions, and market limitations must be available to keyboard users, screen readers, and text extraction tools.
Put installation and return facts before purchase
Installation guidance should distinguish tools, skills, torque values, professional service, and vehicle-specific cautions. If a source does not give a measurement, do not manufacture a precise number. Explain the pre-install check, model differences, substitute item rules, damage risk, and support path for uncertainty. The return path should identify the useful item, vehicle, order-line, installation-state, and evidence details without requesting unrelated personal data. An order should preserve what was shown at purchase even if a later relationship version is corrected.
Design for keyboard, screen readers, and narrow screens
Every selector needs a visible label, logical focus order, keyboard behavior, and an error relationship. When results update, announce a meaningful status without moving focus unexpectedly. Long model names, exclusions, warnings, and errors must remain readable on a narrow screen. Test contrast, touch target size, disabled state, focus visibility, and zoom in the actual theme. A no-result screen should retain a retry action and support path; an empty space is not an explanation.
Make multilingual SEO and internal answers consistent
Fix definitions before translating labels
The terms vehicle, trim, and fitment should map to a controlled glossary and normalized keys before they are translated. A translation may change the visible label, but it must not change the relationship key or turn “needs review” into “fits.” Each language should explain that compatibility, inventory, and market availability are three different decisions. The English storefront can use this Shopify multilingual setup guide as a related reading path while keeping the link in the English language space.
Validate URL, canonical, and hreflang behavior
Markets can support localized domains or paths, canonical URLs, hreflang links, and international sitemaps, but those SEO mechanisms do not validate the truth of a fitment relationship. Render every language and check the title, vehicle labels, warnings, FAQ, and internal links. The canonical should describe the current language page, and hreflang pairs should resolve to the correct market. A changed path is not enough: also verify product availability, prices, and fitment wording after a market switch.
Keep FAQ and internal links in the same language
An English FAQ should answer the boundaries an English-speaking customer actually faces rather than copying another language and swapping a few labels. Every answer should distinguish platform capability, merchant data responsibility, and storefront behavior. For market context, read the Markets guide; for measurement choices, see the analytics guide; and for narrow-screen selection, see the mobile design guide. A related checkout flow guide gives another English-language path. These five internal links are intentionally all in the English URL space.
Use first-party references for platform boundaries
Official documentation should support claims about limits, permissions, resource fields, and market behavior. Implementation experience can explain a process, but it should not be presented as a Shopify guarantee. The supplied first-party references, verified on 2026-08-30, are:
- Shopify variants
- Adding variants and current limits
productVariantsBulkCreate- About metafields
- About metaobjects
- Data modeling with metafields and metaobjects
- Metafield definitions and access
- Category metafields
- Search & Discovery filters
- Inventory quantities and states
- Creating catalogs for Markets
- Markets overview
- International SEO for Markets
- Shopify webhooks
Build wrong-fit, return, and support paths
Treat a wrong-fit event as a repairable data event
When an item does not fit, first freeze the product, vehicle, relationship version, evidence version, order line, and displayed language from the time of purchase. A support person should not simply change the relationship to “does not fit,” because that would erase why the earlier result was shown. Create a new relationship version with the reason, effective time, markets, and customers who may need notice. Historical orders should retain their original snapshot; a corrected relationship applies to new browsing and future selection.
Give uncertain customers a human review route
When a customer knows only a model name, lacks a trim, or uses a regional alias, support can consult a manual, vehicle record, or manufacturer catalog. The form should collect only the fields needed for this decision and explain its purpose and retention. A human result needs a reviewer, evidence reference, expiry, and escalation rule. If sources conflict, state that the relationship is awaiting review rather than giving a positive answer that cannot be defended.
Feed return reasons back into data quality
Classify returns by missing vehicle field, model alias, expired evidence, stock state, market restriction, installation condition, or interface misunderstanding. Use the classes to repair the data contract and customer instructions; do not turn one return into an unsupported accuracy or revenue claim. During review, compare relationship version, product version, displayed language, and the choices the customer made. This shows whether the problem was an identity ambiguity, a stale source, a market gate, or a confusing screen.
Monitor stale relationships and prove a rollback path
Monitor age, gaps, and rendering failures
Track the last successful source version, the last review time for each relationship, rejected rows, unconfirmed selections, support queue age, and market rendering errors. A rise in no-match results may mean that a vehicle source changed, a relationship was withdrawn, or a selector failed. Slice the result by source, market, language, product, and theme version before deciding what to change. Do not replace relationship evidence with an undefined accuracy or conversion percentage.
Release in stages with an independent pause switch
Begin with a small set of products, vehicles, and markets. Exercise positive fit, explicit exclusion, no match, stock change, market-unpublished item, missing translation, and mobile keyboard use. Preserve the data-definition version, source version, theme version, app permission, and filter configuration for each stage. Relationship display, product publication, and storefront presentation should have independent pause controls. If evidence is withdrawn, pausing the affected relation is safer than continuing to show an outdated positive answer.
Rehearse failures and remove only new edges on rollback
Rehearse duplicate source events, out-of-order updates, a deleted record, withdrawn evidence, a partial import, an oversized filter value set, an oversized collection, a theme without filter support, and a stock change during checkout. Record discovery time, affected scope, pause action, restoration evidence, and reviewer. A rollback for a relationship-only change should remove only the newly added fitment edges. It must preserve products, vehicle objects, existing relationships, historical orders, slugs, titles, and dates. After removal, repeat customer visibility checks.
This failure matrix keeps response and recovery separate:
| Failure | Immediate action | Customer state | Recovery evidence | Forbidden shortcut |
|---|---|---|---|---|
| Duplicate or out-of-order input | Deduplicate by stable key and quarantine the older version | Show the last trusted state | Version order, reconciliation, and sample review | Overwrite by receipt time |
| Evidence withdrawn or stale | Pause affected relationships | Show that review is required | New evidence, owner, and review time | Keep a positive answer |
| Partial import | Quarantine the batch and replay only the failed range | Keep the old trusted result or show unknown | Batch completeness and rejected-row reconciliation | Publish a partial set as complete |
| Fits but market is unpublished | Keep fitment, block that market's sale | Explain market restriction and support path | Catalog, URL, price, and delivery check | Rewrite it as incompatible |
| Theme or filter layer lacks support | Use an explicit custom or human path | Keep vehicle context and no-match exit | Keyboard, screen reader, mobile, and empty-state tests | Pretend tags provide fitment logic |
| Wrong-fit return | Freeze the order snapshot and create a corrective version | Explain return and review steps | Old and new versions, order line, and notice | Rewrite the historical order |
Frequently asked questions
Does Shopify include a native automotive fitment database?
No. Shopify provides products, variants, inventory items, locations, metafields, and metaobjects, but creating a variant or adding a tag does not create a manufacturer, model, year, trim, exclusion, and evidence database. The merchant or an approved data provider must maintain vehicle identities, fitment assertions, source versions, review rules, and the customer-facing decision layer.
Should year, make, and model all be variants?
Only when the value represents a real sellable choice with its own price, inventory, fulfillment, and order meaning. If the value merely describes which vehicles a part may fit, use reusable vehicle data and fitment relationships. Enumerating every year, configuration, and part combination can create unsupported combinations and can exceed the practical limits of a product, theme, application, or channel.
Are product tags reliable compatibility data?
Tags can assist a search workflow, but free-text tags do not provide versioned evidence, exclusions, review times, or a many-to-many relationship. Use typed metafields and metaobjects for the relationship, with a status and evidence reference. Tags may be a normalized display or search aid only, and the result should be tested with an exact vehicle, an explicit exclusion, an alias, and a no-match case.
How should a stocked fitment result behave when the market is not published?
Show compatibility, inventory, and market publication separately. The customer may see that the relationship is supported while also seeing that the item is not currently sellable in that market, with a support route for price or delivery questions. Do not call it incompatible merely because a catalog excludes the market, and do not promise a purchase because another location has stock.
How should the data change after an installation or fitment concern?
Preserve the product, vehicle, relationship version, order line, and language shown at purchase. Handle the return and review first. When new evidence is confirmed, create a new relationship version with its source, reviewer, reason, and effective time. Do not rewrite the historical order or remove every relationship because of one case. Classify the cause so that aliases, missing configuration fields, stale evidence, or page instructions can be repaired.