> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://tieback.io/docs/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://tieback.io/docs/_mcp/server.

# Lesson 2: Identifiers and Resolvers

> Academy Foundations Module 4 Lesson 2: why the identifier and the resolver are separate things with separate jobs, and what happens when organisations conflate them.

**Module 4, Lesson 2 of 4. About 8 minutes.**

## Orientation

Lesson 1 walked the scan path as a chain of steps. Two of those steps, the identifier and the
resolver, get confused constantly, and the confusion has a cost: teams that treat the identifier as
"the passport" cannot cope when one product needs to be described three different ways to three
different systems, and teams that treat the resolver as "the identifier" cannot cope when they
switch platform vendor. Separating the two properly is what makes both problems avoidable.

## Learning Objectives

## Two Jobs, Not One

A **product identifier** is a value assigned to a product so it can be referred to consistently by
more than one party over time. Its entire job is to point at one thing. It says nothing about what
that thing is made of, what it does, or where its data is stored. It has three properties that
matter here: it must be unique within a stated scope, stable over time, and interpretable by parties
outside the organisation that issued it.

A **resolver** is a completely different kind of thing: a running service that takes an identifier
and decides what the requester should receive. It is the switchboard, not the phone number. Because
resolution is configuration rather than a value printed on a product, the same identifier can be
pointed at a different destination next year without anything about the identifier itself changing.

The reason to hold these apart is durability. An identifier, well allocated, is meant to outlive
every system built to serve it. A resolver is infrastructure, and infrastructure gets replaced:
platforms are migrated, vendors are switched, hosting changes. If the identifier were bound to one
resolver's address, replacing that resolver would mean reissuing every identifier and reprinting
every carrier already in the field. Keeping identity and resolution separate means the organisation
can change how it serves data without touching what a product is called.

**The common misreading** is to treat the string encoded in a carrier as if it were interchangeably
"the identifier" and "the passport address", and to assume that whoever controls the address
therefore controls the identity. In practice the identifier is meant to be portable across
resolvers, in the same way a phone number is meant to be portable across carriers. An organisation
that discovers, mid migration, that its identifiers are hard-wired to one vendor's resolution
service has discovered a costly design mistake rather than a technical inconvenience.

A second confusion worth naming: an identifier without a working resolver is inert. It uniquely
names a product and resolves nothing on its own. The identifier and the resolver only produce value
together, and evaluating one without the other, for example judging a passport programme "identity
complete" while the resolution service is still unbuilt, overstates progress in exactly the way
Module 1 warned against for the technology layer generally.

#### [What is a Product Identifier?](/docs/knowledge-base/standards-and-technology/what-is-a-product-identifier)

Read the definition first, then the hierarchy, which places the identifier and the digital
services that resolve it as separate, dependent layers. The section on why identity matters gives
the cross-organisation case for keeping the two apart.

#### The Aurelia S2's three identifiers, and one resolver problem

The S2 currently has three conflicting internal identifiers across three systems: an ERP part
number, a catalogue code, and a label reference used by the contract manufacturer. None of them
are unique outside their own system, none are stable across a model refresh, and none would be
recognised by a customs authority or a recycler.

Before any passport work can start, the organisation has to decide which identifier, if any of the
three, becomes the one the passport is built on, and whether it needs to adopt a globally recognised
identifier instead. Only once that decision is made does the resolver question become answerable:
which service will take that identifier and route requests correctly, for a product that may
outlive the vendor chosen to build the first version of that service.

#### Separate identity from resolution for one product

Pick a product with more than one internal reference, which for most organisations is any product.
Write down every existing identifier for it and which system holds each. Then write, separately,
where a scan of that product currently ends up, if anywhere. If those two lists are impossible to
keep apart because a system number and an address are the same string, you have found the
conflation this lesson describes.

## Knowledge Check

## Takeaways

* An identifier points at a product; a resolver decides what a requester receives for that identifier.
* Identifiers should be unique within a stated scope, stable over time, and interpretable by outsiders.
* Keeping identity and resolution separate is what allows a platform migration without reissuing every identifier.
* An identifier without a resolver, or a resolver without a stable identifier, delivers nothing on its own.

**If you remember one thing:** an identifier is a name, a resolver is a switchboard, and confusing
the two is what makes a vendor migration painful instead of routine.

## Sources

[What is a Product Identifier?](/docs/knowledge-base/standards-and-technology/what-is-a-product-identifier),
sections Definition, The Product Identity Hierarchy, and Why Every Product Needs an Identity.

## Related Docs

* [Lesson 3: Life After the Sale](/docs/academy/foundations/module-4/lesson-3)
* [Lesson 1: The Scan Path End to End](/docs/academy/foundations/module-4/lesson-1)
* [What is a Product Identifier?](/docs/knowledge-base/standards-and-technology/what-is-a-product-identifier)
* [What is a Data Carrier?](/docs/knowledge-base/standards-and-technology/what-is-a-data-carrier)