Lesson 2: Identifiers and Resolvers
Lesson 2: Identifiers and Resolvers
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
By the end of this lesson you should be able to:
- M4-O2Explain the distinct roles of the unique identifier and the resolver.
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.
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.
Read: What is a Product Identifier? (15 min read)
Sections that carry this lesson:
- Definition
- The Product Identity Hierarchy
- Why Every Product Needs an Identity
The article is the source of record. Where this lesson and the article differ, the article is correct.
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.
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
4 questions. Feedback is immediate, nothing is graded, and this does not gate your progress.
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?, sections Definition, The Product Identity Hierarchy, and Why Every Product Needs an Identity.
Module 4 · Lesson 2 of 4
Checking this device for saved progress.
Previous: The Scan Path End to End
Progress is saved on this device.