# Can a Product Tell Software Which Parts and Services It Needs?

Source: https://activatedigital.ai/knowledge/guides/product-parts-services-resolver
Last verified: 4 September 2026
Summary: Product identity can already resolve compatible parts and services in bounded systems. The missing cross-brand layer is a permissioned product-to-action contract.

## In 60 seconds

Yes. In bounded product ecosystems, software can already use a product identity or configuration to resolve **which parts fit**. It can also resolve **which services apply and what the next machine-readable step is**. eBay's vehicle-parts compatibility APIs are a clear current example: software can compare a candidate part with structured vehicle attributes and return compatibility information.

- eBay's Browse API can return a compatibility status for a candidate part against supplied vehicle attributes.
- The GS1-Conformant Resolver Standard 1.2.1 lets one product identity lead to multiple typed resources, from repair instructions to service APIs.
- Correct fit is a data decision and entitlement is an authority decision. A compatible part does not prove a warranty right.
- Overall position as at **4 September 2026**: NOW bounded, with cross-brand agent action EMERGING. No standard contract for product actions exists across brands.
The harder cross-brand problem is not basic discovery. It is the full chain from **this exact product** to **the correct service**, then to **the required evidence or entitlement**, then to **an authorised action**.

A compatible part does not prove a warranty right. A service URL does not mean the caller may book or invoke it. An API or agent tool does not know product entitlement simply because it is callable.

## The questions that get mixed together

The parts question is really several: which product or configuration this is, which parts and services fit it, what is actually available, whether this person has the right to use it and how software may safely act. A [resolver](https://activatedigital.ai/knowledge/passport/from-question-to-published-passport) can lead from the product to the right resources, but it doesn't settle the rest. The value comes from joining those answers without pretending they are the same thing.

## eBay proves machine-operable compatibility today

The strongest current evidence is vehicle fitment.

[eBay's parts compatibility documentation](https://developer.ebay.com/api-docs/user-guides/static/trading-user-guide/compatible-parts-api-support.html) describes structured compatibility information for supported vehicle-parts categories. Its [Browse API documentation](https://www.edp.ebay.com/api-docs/buy/static/api-browse.html) includes compatibility behaviour that can return a compatibility status for a candidate item against supplied vehicle attributes.

The compatibility decision isn't trapped inside a human-readable description such as “may fit some 2019 models”. It can be exposed to software in structured form.

So a machine can ask a bounded question:

**Does this candidate part fit the vehicle configuration I have supplied?**

That is already a real product-to-decision pattern.

It is also a useful warning. Compatibility is only as good as the underlying configuration and fitment data. The wrong vehicle variant, incomplete attribute set, bad catalogue mapping or outdated fitment relationship can still produce the wrong answer.

For safety-critical parts, “probably compatible” is not an acceptable substitute for a sufficiently governed fitment rule and exception process.

## Product identity can become a service resolver

The next step is broader than parts fitment.

A persistent identifier can resolve to service resources associated with a product. The [GS1-Conformant Resolver Standard 1.2.1](https://ref.gs1.org/standards/resolver/) supports multiple typed links around an identified entity. So one identity can lead to different resources rather than one permanently fixed destination.

A product identity could resolve to resources such as:

- care or maintenance information;
- repair instructions;
- compatible parts or accessories;
- authorised service locations;
- recall or safety information;
- registration or support journeys;
- machine-readable APIs where a provider exposes them.
The existing article on [what a product code can do after the sale](https://activatedigital.ai/knowledge/guides/product-code-after-sale-services) owns the human-facing service-routing question. This page goes one step further: can software resolve **which service or part applies to this product** in a form that another system can act on?

The answer is **yes in bounded systems** and **not yet universally across brands**.

## Compatibility resolution and service entitlement are different decisions

Suppose software correctly determines that Part X fits Product Y.

That does not establish:

- that Part X is currently available;
- that the user may order it under warranty;
- that an independent repairer is authorised to perform the service;
- that the product is still covered by a service contract;
- that the caller is the owner;
- that the action is safe in the current product state;
- that an automated agent may complete the transaction without confirmation.
Correct fit is a **data decision**. Entitlement is an **authority decision**.

The existing Knowledge guide on [identity, authentication and ownership](https://activatedigital.ai/knowledge/passport/identity-authentication-and-ownership) owns the wider identity boundary. The [right-to-repair page](https://activatedigital.ai/knowledge/regulation/right-to-repair) owns the regulatory repair context. Neither should be collapsed into compatibility logic.

## What is missing between discovery and action

GS1 resolvers can expose machine-discoverable resources around a product identifier and the [Model Context Protocol tool specification](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/server/tools.mdx) lets software discover and invoke structured tools, but no standard product-specific contract joins those two halves across brands. [What has to be settled before software may act](https://activatedigital.ai/knowledge/guides/product-identity-api-endpoint) is covered on the API endpoint guide.

## What a complete service flow could look like

Imagine a repair assistant dealing with a specific washing machine.

The product identity resolves the exact model and configuration. A compatibility graph says which drain pump variants are valid. A service catalogue says which compatible parts are available in the user's region. The current product state says whether a known recall or service campaign changes the normal repair path. An entitlement service says whether warranty, paid service or self-repair applies. The booking or ordering interface has to be exposed in a form software can call. Only then can an authorised user or agent complete the next step.

If a compatibility result is uncertain, the system can stop before action and request another identifier, attribute, inspection or human check.

The wider question of [what an AI agent needs before it can act on a specific product](https://activatedigital.ai/knowledge/guides/ai-agent-act-on-specific-product) remains canonical for generic authority, evidence and execution. This article owns the narrower bridge from product identity to **the correct part or service**.

## Repair history can improve service resolution without becoming entitlement

An item-level history can sometimes change which service applies.

A product may already have a replaced component, previous repair, software version or service event that affects the next valid part or procedure. Where that history is reliable, it can become another input to the compatibility or service decision.

That does not make history the same as ownership or warranty. [Repair history can persist with a product across ownership change](https://activatedigital.ai/knowledge/guides/repair-history-across-ownership) in some bounded ecosystems, but persistence alone does not transfer legal rights or guarantee that the history is complete.

This is another reason the resolver should expose dependencies rather than return one unexplained “recommended service” result.

## The five maturity questions should stay separate

| Maturity test | Current evidence position |
|---|---|
| **Technology exists** | **Yes.** Persistent product identity, resolver standards, structured compatibility graphs, service APIs and machine tool contracts all exist. |
| **Technically composable** | **Yes.** A controlled ecosystem can join identity, compatibility, catalogue state, entitlement and an API action. |
| **System demonstrated** | **Yes, bounded.** eBay demonstrates machine-operable vehicle/part compatibility. Product-service platforms demonstrate similar vertical service resolution inside their own ecosystems. |
| **System deployed** | **Yes for bounded compatibility and service systems.** The generic cross-brand identity-to-service-to-entitlement-to-agent bridge is not established. |
| **Commercial value measured** | **Yes around individual compatibility and service businesses, not for the general cross-brand bridge.** Existing marketplace value should not be re-labelled as proof that universal product-agent interoperability has a measured return. |

The overall position is **NOW bounded / EMERGING cross-brand agent action**.

## What breaks the system most often?

### The product identity is too coarse

A model family may not be enough if compatibility varies by variant, production date, serial range or installed component.

The solution is not automatically “serialise everything”. The right scope depends on where compatibility changes. [Lot, serial and item identity should follow the operational requirement](https://activatedigital.ai/knowledge/product-data/lot-serial-item-operational-identity).

### The compatibility graph is incomplete or stale

A beautifully resolved product identity cannot rescue bad fitment data.

The system needs governed relationships between product configurations, parts and service rules, including effective dates, supersessions and exceptions.

### Availability is confused with compatibility

A part can fit but be unavailable. A nearby service can exist but not support the model. A repair method can be technically valid but unavailable under current policy.

So external catalogue, inventory and service-network context belongs after the compatibility decision rather than inside the identifier itself.

### Entitlement is assumed from product recognition

Recognising a product does not prove that the person or agent may order a warranty part, view restricted service information or authorise a consequential repair.

### The action surface is callable but not safely governed

An API can be technically invokable while lacking sufficient constraints, confirmation, audit or revocation. Machine-callable does not mean machine-safe.

## What this does not mean

**A product identifier does not contain the whole compatibility graph.** It can be the join key to one.

**Correct compatibility does not grant entitlement.** Fit and permission are separate decisions.

**A resolver link is not an executable service contract.** It can expose a resource without defining the full action semantics.

**An API or MCP tool is not product authority.** The caller still needs appropriate authentication and authorisation.

**Machine-readable does not mean cross-brand interoperable.** Bounded vertical systems can work well while using proprietary data models and service rules.

**Agent action is not required for the architecture to be useful.** Human-facing repair, service and commerce flows can already benefit from exact compatibility resolution.

## What would change this answer

The classification would move materially if the market develops a portable cross-brand object that binds product identity to service semantics and entitlement.

Strong evidence would include:

- normative product-to-service bindings implemented across multiple brands;
- portable compatibility semantics outside a single marketplace or OEM ecosystem;
- a standard way to express product-specific ownership, warranty or service entitlement without conflating it with identity;
- machine-readable action contracts with constraints, revocation, human confirmation and audit;
- production agents that can start from a product identifier, discover the right service, prove authority and complete the action without bespoke pairwise integration;
- measured wrong-part, first-time-fix, booking or service-completion outcomes from those cross-brand systems.
Until then, the practical architecture is clear: **use product identity to resolve the right compatibility and service context now, keep entitlement separate and treat cross-brand autonomous action as an emerging bridge rather than an established standard.**

## Keep exploring

The questions this page usually raises next.

- [CompareNext questionthe programmable product guideThe wider capability picture is in the programmable product guide. If product state itself should change which part or service is recommended, read what changes when a product can report its condition.→](https://activatedigital.ai/knowledge/guides/programmable-product-stack)
- [CompareNext questionwhat changes when a product can report its conditionThe wider capability picture is in the programmable product guide. If product state itself should change which part or service is recommended, read what changes when a product can report its condition.→](https://activatedigital.ai/knowledge/guides/product-condition-sensor-history)

## Sources

**Sources as at 4 September 2026.**

- [eBay Developers: Compatible parts API support, accessed 4 September 2026. Used for structured vehicle and part compatibility in supported categories and markets.](https://developer.ebay.com/api-docs/user-guides/static/trading-user-guide/compatible-parts-api-support.html)
- [eBay Developers: Browse API compatibility, accessed 4 September 2026. Used for machine-operable compatibility status against vehicle attributes.](https://www.edp.ebay.com/api-docs/buy/static/api-browse.html)
- [GS1: GS1-Conformant Resolver Standard 1.2.1, August 2026. Used for product identity resolving to multiple typed machine-discoverable resources.](https://ref.gs1.org/standards/resolver/) Standards body
- [GS1: Digital Link URI Syntax 1.7.0, August 2026. Supporting source for persistent GS1 identifiers represented in resolvable web form.](https://ref.gs1.org/standards/digital-link/uri-syntax/1.7.0/) Standards body
- [Model Context Protocol: Tools, 2026-07-28. Used for discoverable structured machine tools and invocation capability.](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/server/tools.mdx)
- [Model Context Protocol: July 2026 release, 28 July 2026. Used for current protocol maturity and authorisation-hardening context.](https://blog.modelcontextprotocol.io/posts/2026-07-28/)