Opticat item search MCP reviewPhase 1 discovery, validation, and path forward
View Demo
Library contents
All library documents

Interchange validation design

Five-gate identity, category, relationship, specification, and application standard.

mdCurrent70 lines · 4 min read
discovery/product/interchange-validation-design.mdView source on GitHub

Executive conclusion

An interchange answer is safe only after the source part is resolved to a complete catalog identity. A matching number, brand name, or third-party cross-reference is not enough by itself. The production MCP now treats interchange as a gated workflow: source identity → explicit catalog relationship → candidate category/specification review → vehicle application verification. The first three gates can be automated from OptiCat data; the final vehicle check must use the intended vehicle before the application recommends installation.

The five gates

Gate Question Production rule
Identity Which exact source part is this? Require source brand/line, part number, and product type. Return catalog identity choices when ambiguous.
Category Do source and candidate perform the same function? Compare returned partTypeId or normalized part-type name. A conflict rejects the recommendation.
Catalog relationship Does the source catalog explicitly relate the parts? Use only typed PIES interchange relationships from getAutoCarePartDetails. Similar digits are never evidence.
Product evidence Do comparable returned attributes agree? Retrieve bounded candidate details. Show matching fields, conflicts, and fields that cannot be compared because units/data are absent.
Application Does the candidate fit the intended vehicle/configuration? Use the fitment-verification journey. An interchange is not automatically an application guarantee. 
flowchart TD
    Q[Customer asks for an equivalent] --> I{Complete source identity?}
    I -- No --> C[Show brand / line / category choices]
    C --> I
    I -- Yes --> R[Read explicit PIES interchange relationships]
    R --> E{Requested target returned?}
    E -- No --> N[Report no returned mapping without a brand-wide claim]
    E -- Yes --> D[Retrieve candidate product details]
    D --> P{Category agrees?}
    P -- No --> X[Reject candidate]
    P -- Unknown --> U[Conditional: missing category evidence]
    P -- Yes --> S{Comparable specification conflicts?}
    S -- Yes --> H[Conditional: human/manufacturer review]
    S -- No --> V[Catalog-confirmed interchange candidate]
    V --> F[Verify candidate against intended vehicle]
    F --> A[Customer-facing recommendation with evidence and qualifications]
Diagram source (Mermaid), shown as text.

OptiCat operation sequence

  1. getAutoCareSearchResults resolves exact source brand code, number, and part type.
  2. getAutoCarePartDetails reads the source PIES record and typed interchange relationships.
  3. getAutoCarePartDetails is repeated for a bounded candidate set to compare category and returned attributes.
  4. getAutoCarePartApplications, through the fitment-verification tool, validates a selected candidate against the intended base vehicle.

The MCP returns catalog_confirmed, conditional, or rejected for the product-evidence stage. catalog_confirmed still carries a required vehicle-application check; it does not mean “safe to install on every vehicle.”

NAPA 7042 assessment

The supplied logic correctly identifies the central risk: 7042 is not a universal identity. The public NAPA record confirms NBH 7042 is a molded coolant hose, while K&N’s official HP-7029 page lists both NAPA 7042 and Baldwin P7364 as oil-filter cross-references. Those facts support category-first clarification and a common-anchor method. They do not support hardcoding a universal 7042 → P7364 rule.

  • Verified: NAPA NBH 7042 molded coolant hose.
  • Verified: K&N HP-7029 specifications and cross-references list NAPA 7042 and Baldwin P7364 in the cartridge-oil-filter group.
  • Not yet verified from an official Bendix product record: the document’s specific Bendix H7042 passenger-car brake-hardware assertion. Keep it conditional unless OptiCat or an authoritative Bendix catalog returns the relationship.

The safe customer response to “What is the Bendix equivalent for NAPA 7042?” therefore starts by correcting the source/target roles and asking for the NAPA line or product type. It must not select Bendix H7042, Baldwin P7364, or any other candidate from the four digits alone.

Customer-facing response design

The answer should show:

  1. Interpretation: source part, requested target brand, and any assumption.
  2. Clarification when material: complete source line/category choices from the catalog.
  3. Returned alternatives: exact target brand/part and relationship type.
  4. Validation status: category agreement, matching specifications, conflicts, and missing checks.
  5. Next safe action: verify the selected candidate against the exact vehicle; open full product details and assets.

The bot should be eager about returned evidence but conservative about the recommendation. It can say “the source catalog explicitly lists this candidate,” while separately saying “vehicle application has not yet been verified.”

Reuse across interchange initiatives

This design applies to filters, hoses, brake hardware, electrical parts, bearings, and OE/aftermarket alternatives because the gates are data-driven rather than category-specific. Category-specific comparison policies can be added later—for example, thread and bypass-valve fields for filters or position and included hardware for brake components—without weakening the shared identity, relationship, and application controls.

View Demo