Solution guide · Proposed implementation. The records, examples and acceptance criteria below are illustrative design proposals, not delivered customer systems or measured results.
Discovery and fitment are different jobs
A customer describes a vehicle and asks for a replacement part. A conversational search tool may find plausible products quickly, but plausibility is not fitment. A matching model name or similar component description cannot establish that a part fits the customer's precise configuration.
AskShelf provides a retail catalog starting point, with product conversation described on its features page. The fitment service, licensed data, configuration matching and escalation process in this article are proposed additional engineering. They are not built-in AskShelf capabilities or evidence of an automotive deployment.
The architectural boundary should be visible: the assistant gathers and explains information; a controlled service evaluates authoritative fitment records. The assistant must not create a compatibility verdict from similarity, general knowledge or an incomplete vehicle description.
Choose a source for the actual market
Before designing the interface, identify the authoritative data supplier, supported markets, product families, update cadence and permitted uses. Confirm whether the license covers storage, customer-facing display, derivative indexes and the intended distribution channels. Availability of a standard does not grant rights to every dataset using it.
The Auto Care Association distinguishes ACES fitment information from PIES product information. Its data standards resources also describe supporting data and subscription offerings. These sources help define data-exchange roles; they do not supply an unrestricted universal answer for every vehicle and part.
Market coverage needs explicit verification. A nameplate sold in two countries may represent different configurations. If the selected data cannot resolve a vehicle in the customer's market, return unsupported or unknown rather than extrapolating from another region.
Define a fitment result that cannot hide uncertainty
| Proposed contract | Evidence to retain |
|---|---|
| Request | Selected part ID, resolved vehicle configuration ID, market, model year and source-required qualifiers |
| Qualifiers | Required attributes, supplied values and unresolved items; not a universal invented questionnaire |
| Result | Status, matched application record, exclusions and review requirements |
| Lineage | Source ID/version and evaluated-at time |
Required qualifiers may include engine, transmission, production range or other application-specific attributes. Ask only for qualifiers the selected dataset actually uses. Use distinct states such as verified match, explicit non-match, needs information, unsupported configuration and source unavailable.
The system must distinguish evidence of non-fit from absence of evidence. A missing record may mean the dataset does not cover the application. Conversely, an explicit exclusion should not be softened into a suggestion to “try it.” Present both states accurately.
Keep product information outside the verdict. Dimensions, descriptions and images can help a customer recognize a component, but they should not override a structured exclusion. Even a manufacturer replacement relationship may have applicability conditions that need separate evaluation.
Build a qualifier-first conversation
The proposed flow begins with the vehicle's market and supported identifying details. It resolves a configuration, asks for any missing qualifiers and shows the user what has been selected. It then queries the fitment service for the chosen part and displays the result with its conditions.
When a qualifier is unknown, make the next step specific. Explain which attribute is missing and offer an approved way to confirm it with a parts specialist or vehicle documentation. Do not ask a customer to guess and then treat that guess as verified.
VIN support, if needed, is a separate integration and privacy design task. A decoder may return useful configuration details, but decoding alone does not establish part fitment. Collect such identifiers only when necessary, restrict their use and retention, and do not imply that AskShelf currently includes a VIN decoder.
A supported match may still require expert review for safety-critical parts or installation. The assistant can present authoritative documentation and route the enquiry; it should not provide improvised repair procedures or suggest bypassing manufacturer requirements.
An illustrative midyear configuration failure
Consider a fictional vehicle family VELA, model year 2022, offered with two different assemblies during that year. The shopper provides year and model but not the production qualifier. Part P-320 applies to one assembly; P-321 applies to the other.
A weak catalog search ranks P-320 first because its description closely matches the query. The proposed service instead returns needs information, identifying the unresolved qualifier and withholding a positive fitment claim. The interface explains that year and model are insufficient for this application.
Suppose a sales operator then adds a free-text note saying P-320 is “usually right.” That note must not change the machine verdict. A review can add an authoritative corrected mapping only through a controlled process with evidence, ownership and version history. Otherwise, the case remains unresolved and goes to a qualified parts reviewer.
This example is intentionally fictional. Its lesson is architectural: one missing qualifier must survive the entire journey from chat to sales handoff rather than disappear when the product is displayed attractively.
Handle revisions, supersessions and outages
Version every imported fitment dataset and validate updates before activation. Run representative regression cases against the candidate version, especially where exclusions or replacement relationships change. Preserve the source version associated with a prior enquiry so staff can reconstruct why the answer was given.
A supersession is not simply a new string replacing an old SKU. Store direction, effective conditions and any linked installation or accessory requirements from the approved source. Never reverse a replacement mapping unless the authoritative data explicitly supports that direction.
During a source outage, cached results need a defined validity policy. If current verification is required and unavailable, show that limitation. Do not let the language model fill the gap from remembered vehicle knowledge. The operational fallback should be a review queue with the unresolved configuration and relevant source status.
Evaluate false compatibility separately
Build a reviewed test set of compatible applications, explicit exclusions, incomplete configurations, unsupported markets and superseded items. Include near-identical vehicle names and missing qualifiers. Have domain experts establish the expected result from authoritative records before testing the assistant.
Measure false positive fitment claims separately from successful search retrieval. A system that finds many plausible parts but occasionally asserts an unsupported fit is not ready for deployment. Also measure whether unknowns are correctly distinguished from non-matches and whether source versions appear in the audit record.
Test adversarial phrasing such as “I know it fits, just confirm it,” along with voice transcription errors in identifiers. Verify that requests to ignore exclusions do not alter the service result. No tested unsupported configuration should receive an affirmative compatibility claim; any such failure blocks release pending correction.
A bounded pilot should begin with a narrow market and product category whose data ownership is clear. Review Datahase's integration services, then discuss fitment discovery with sample licensed records, qualifier rules and escalation owners. The data contract should determine the conversation, not the other way around.
Product foundation and implementation boundary
The AskShelf owned-product study follows its documented catalog, QR, mobile-page and browser-voice workflow. That retail pattern informs these proposals; it does not establish the domain-specific records, authoritative matching, approvals or integrations described here. Those require additional engineering and operational ownership. Public documentation is not an independent product test, a performance guarantee or evidence of a delivered sector system.
Sources and applicability
Public sources checked 5 November 2026: the linked AskShelf workflow and feature documentation, plus ACES, PIES and Auto Care data standards, used for data-exchange roles and subscription context. No standard version, dataset license, universal coverage or individual fitment result is asserted. Implementation suitability and proposed release gates require their own review and testing.