Manufacturer part number
Issued by the manufacturer of this product. Identifies the product as the maker names it.
Agriculture verticalReference data
Reference decoder / typed relationship harness
Structure OEM, Aftermarket and Cross-Reference Part Data
Part numbers are often the fastest way to identify agricultural spare parts, but real catalogs can contain several identifiers for the same product context.
OEM numbers, aftermarket references, supplier numbers, replacements and compatibility relationships need a structured model if they are going to support search and product matching.
ENRIVAQ is designed to enrich and organize those relationships as part of the wider product record.
Reference Decoder / Typed Identifier RecordONE TEXT FIELD → SEPARATE ROLES
As delivered
1183-A / ART-1183A / OEM 55-2210 / repl. 55-2190 / fits several typesCatalog record
One product identity
Each reference is attached to the record with an explicit role.
- mpn
- 1183-A TYPED
- supplier_ref
- ART-1183A TYPED
- oem_ref
- 55-2210 TYPED
- superseded_by
- 55-2190 FOR REVIEW
- fitment
- no structured entries WITHHELD
Until each value has a type, the catalog cannot tell an OEM number from a replacement or a supplier reference.
Identifier roles
Different identifiers serve different roles
An OEM part number usually originates from the original equipment manufacturer. An aftermarket product may have its own manufacturer number while also referencing one or more OEM numbers for identification or cross-reference purposes.
These values should not all be stored as one undifferentiated text field.
OEM reference
Originates from the original equipment manufacturer and can support identification or cross-reference.
Supplier reference
Issued by a distributor or supplier feed and used to connect incoming data to the catalog record.
Aftermarket reference
A separate manufacturer/reference identity that may be related to one or more OEM references.
Identifier relationships
Model the relationship instead of repeating numbers in descriptions
A structured record can separate internal SKU, manufacturer part number, OEM reference and other catalog identifiers.
Where the business supports explicit relationships such as replacement or supersession, those should also be modeled clearly.
Reference Wiring HarnessTYPED EDGES, NOT PROSE
has_identifier
mpn1 : 1references
oem_ref1 : Nequivalent_to
aftermarket_refN : Nsuperseded_by
sku (new)1 : 1fits
machine family1 : NThe exact relationship set belongs to the business data model. Each edge must keep its type, target and cardinality.
Cross-reference problems
Similar numbers do not automatically mean the same part
Cross-reference data may be outdated, partial or context-dependent.
It should be validated as product data, not copied because two sources list similar references.
The workflow should preserve uncertainty when evidence is insufficient.
CandidateWhat the evidence showsVerdict
Listed by two catalogs, neither citing the manufacturer.
FOR REVIEWDiffers by one character from a known number.
REJECTEDValid for an earlier machine generation only.
SCOPEDSource last updated before the part was revised.
REJECTEDConfirmed against the manufacturer document.
ACCEPTEDconfirmed against manufacturer sourceuncertain, not publishedinsufficient evidence, dropped
Product matching
Use identifiers together with product context
Part numbers are strong signals, but product identity can also depend on manufacturer, product type and technical characteristics.
Combining those signals can help reduce the risk of attaching specifications from a related but different part.
Identity FingerprintNUMBER ALONE IS NOT IDENTITY
Candidate A
Number and context agree
MATCHED- number
- agrees
- manufacturer
- agrees
- type
- agrees
- attributes
- agree
Candidate B
Number matches, maker differs
NOT MATCHED- number
- agrees
- manufacturer
- differs
- type
- agrees
- attributes
- not compared
Candidate C
Number matches, attributes differ
FOR REVIEW- number
- agrees
- manufacturer
- agrees
- type
- agrees
- attributes
- differ
Compatibility data
Connect part references to application data only when verified
Compatibility relationships can improve the usefulness of a spare-parts catalog, but they are particularly sensitive to product identity.
Where verified application data exists, it should be represented as structured relationships rather than generated prose.
Product identity confirmed
The record is the part it claims to be, not a similar one.
Reference relationships validated
OEM and aftermarket edges have passed review.
Verified application data exists
The business maintains the fitment model for this family.
Structured relation output
Publish typed entries, never generated fitment prose.
Validation
Make uncertain reference relationships visible
If two sources disagree about an OEM reference or replacement relationship, the system should surface that conflict.
Technical identifiers should not be accepted solely because they appear frequently online.
RelationshipSource A saysSource B saysResolution
The validation stage separates supported relationships from those that still require review.
Example record
Show how one product carries its reference passport
Use a real part and show the typed identifier, replacement and compatibility pockets attached to the product record.
Reference Passport DossierOEM AC820825 · aftermarket product AD-164502 · Kverneland Optima / Optima HD / Optima PH application on the replacement source
Manufacturer part number
AC820825
OEM reference(s)
AC820825
Aftermarket reference(s)
AC820825
Replacement / supersession
Optima / Optima HD / Optima PH on the aftermarket listing
Compatibility
Optima / Optima HD / Optima PH on the aftermarket listing
The same data can also be exported as a structured table. Exact relationship types belong to the business data model.
Controlled next step
Use one difficult reference chain as the test case
Choose a part with several OEM or aftermarket numbers and review how the relationships can be structured.