Product Type / Catalog Item

Type-level identity anchor and issuing scheme

A product type must resolve to exactly one authoritative identity within a stated scheme. GS1 issues a GTIN under a licensed company prefix for a trade item; UNTP carries a resolvable id plus idScheme and modelNumber at model granularity; medical device regimes issue a Basic UDI-DI as the model-level identifier above the trade-item Device Identifier. Where no external authority applies, the adopting Dimension assigns a UUID or ULID, never a date or a name.

1. Which identifier scheme is authoritative for this product type, who licenses or issues it, and what is the issuing authority's registered identifier? identity
2. At which granularity does this identifier bind — model/type, sub-type variant, packaging level, or a grouping above trade-item identity? classification
3. If no external authoritative scheme applies, what internally assigned identifier is used and how is its uniqueness guaranteed? identity
4. Is the identity anchor resolvable to a network-retrievable representation, and under whose control is that resolution? interoperability

Identifier change triggers and non-reuse

Rules determining when a modification creates a new product type rather than a revision of the existing one, and the prohibition on reusing a retired identifier. GS1 states that a GTIN is non-reusable and permanently assigned, and applies guiding principles based on whether consumers or trading partners can distinguish the change, whether disclosure is legally required, and whether supply chain handling is materially affected.

1. Which declared attributes, when changed, force allocation of a new type identifier rather than a record revision? constraint
2. From which effective date does a type identifier change apply, and how are in-market goods carrying the previous identifier handled? temporal
3. Under what conditions, if any, may a retired identifier be reassigned, and what is the enforced quarantine period? lifecycle
4. What evidence records the change decision so it can be audited and, if disputed, reversed? evidence

Manufacturer designation, brand and multilingual naming

The type carries a manufacturer product designation and a brand, and often a hierarchy of root, family and type designations as in the industrial digital nameplate. Names are locale-scoped and mutable, and must not be treated as identity. Brand is a change-triggering attribute under GS1 guiding principles when the primary brand changes.

1. What are the product root, family and type designations, and which of them is the customer-facing name? definition
2. Which brand is asserted on this type, who owns that brand, and is it the primary brand for identifier-change purposes? ownership
3. Which locales are names and descriptions maintained in, and which locale is authoritative when translations conflict? interoperability
4. Can a designation change without changing the type identity, and what approval is required? process

Secondary, partner and legacy keys

Non-authoritative identifiers used by specific parties or channels: manufacturer part number, order code, article number, seller SKU, buyer item number, catalogue item number, marketplace identifiers and legacy system keys. UBL models these as distinct buyer, seller, manufacturer, standard and catalogue item identifications, which makes the party scope of each key explicit.

1. For each secondary key, which party and which channel or contract does it apply within? identity
2. How are collisions handled when the same secondary key value is used by different parties for different types? constraint
3. Which legacy keys must be retained after migration, and for how long, to keep historical transactions resolvable? retention

Commercial and technical classification assignment

A type is normally classified in several schemes at once: a GPC brick for retail data sharing, a UNSPSC commodity for procurement, an ECLASS or IEC CDD class for engineering, and internal merchandising categories. UNTP models productCategory as an array of scheme-scoped classification objects, which is the correct shape: multiple concurrent assignments, none privileged by default.

1. Which classification schemes is this type assigned in, and what is the code, scheme version and effective date of each assignment? classification
2. Who made each classification assignment, and was it self-declared, partner-supplied or authority-verified? authority
3. Which single classification is treated as primary for navigation and reporting when schemes disagree? decision
4. Is any assignment provisional or a holding value pending a scheme update, and when must it be revisited? quality

Regulatory nomenclature and risk classification

Classifications that carry legal consequence rather than convenience: HS/CN customs nomenclature, hazard and dangerous-goods classes, and regulatory risk classes such as the device risk class embedded in a Basic UDI-DI grouping. These are edition-dated: the HS is amended on a multi-year cycle with correlation tables between editions, so a type's code must be re-assessed at each edition change.

1. What is the customs nomenclature code for this type, under which HS edition and which national extension? classification
2. Which regulatory risk or hazard classes apply to this type, under which legal instrument and jurisdiction? requirement
3. When the nomenclature edition changes, who re-assesses the code and how is the transition recorded? lifecycle
4. Has any classification been challenged or overridden by a customs or regulatory authority, and what is the binding outcome? exception

Property semantics and dictionary binding

Each declared characteristic should reference a property definition in a governed dictionary rather than rely on a free-text label. IEC CDD identifies classes, properties, values and units with IRDIs of the form RAI#DI#VI, giving every property a versioned, resolvable definition; schema.org warns that consuming applications expect specific properties rather than generic property/value pairs, so the mapping between dictionary-bound properties and well-known vocabulary terms must be explicit.

1. Which dictionary definition and version does each declared characteristic bind to? interoperability
2. Which characteristics have no dictionary binding, and what is the plan or justification for leaving them unbound? quality
3. Which characteristics are mandatory for this type's classification or regulatory category, and which are optional? requirement
4. What happens to recorded values when a bound property definition is superseded in a new dictionary release? lifecycle

Declared values, units and measurement basis

The asserted value of each characteristic at type level, with its unit of measure, tolerance, and the test method or measurement condition under which it holds. Type-level values are declared or nominal; measured values from an individual unit belong to the instance or batch. UNTP models this as an extensible characteristics structure for industry-specific parameters.

1. What value and unit of measure is declared for each characteristic, and which unit code system is used? measurement
2. Is each value nominal/declared, a specification limit, or a typical value, and what tolerance applies? measurement
3. Under which test method, standard and ambient conditions does the declared value hold? evidence
4. When was each declared value last verified, and when does it expire or require re-testing? temporal

Variant axes, product groups and sub-type qualifiers

schema.org models a ProductGroup as a prototype that varies by declared axes (variesBy) and is not itself offered for sale, with members linked via hasVariant / isVariantOf. GS1 introduces a further level below the trade item: the consumer product variant qualifier (cpv, AI 22) distinguishes variants that share a GTIN. Together these establish three distinguishable levels — group, type, and shared-identity sub-variant — that a model must not collapse.

1. Which properties are the declared variant axes of the group this type belongs to, and what value does this type take on each? composition
2. Which variations are represented as separate type identities and which are carried as sub-variant qualifiers under a shared identifier? decision
3. Is the product group's membership closed and enumerable, or open and configurable at order time? constraint
4. Is the group itself ever presented as orderable, and if not, how is that constraint enforced downstream? constraint

Packaging-level type hierarchy

Each, inner pack, case and pallet configurations of the same product are distinct trade items with separate identifiers, related by a containment hierarchy with a declared child quantity. A grouping made purely for transport or storage is a logistics unit, not a trade item, and is excluded from this model.

1. Which packaging levels exist for this product, what identifier does each carry, and what is the parent-child containment quantity? composition
2. Is each higher packaging level homogeneous, or a pre-defined assortment of different child types? classification
3. Which packaging level is the consumer or point-of-sale unit, and which levels are orderable or invoiceable? classification
4. What packaging materials and recyclability data are declared for each level? requirement

Net content, dimensions and weights

Declared quantities that describe the type as a physical object of trade: net content, gross and net weight, and the outer dimensions. GS1 guiding principles treat declared net content and material dimensional or gross weight change as grounds for a new identifier, so these values are identity-relevant rather than merely descriptive.

1. What is the declared net content of the type, in which unit, and is it a legally declared quantity? measurement
2. On what basis are the declared dimensions and weights measured — as packaged, as displayed, or as shipped? measurement
3. What tolerance applies to declared quantities, and at what deviation does a change require a new type identifier? constraint
4. Do declared quantities differ by target market due to metrology or labelling rules, and how is that represented? interoperability

Type-level component, material and substance composition

What the type is made of, expressed at type level: component types drawn from the governing bill of material, material breakdown by origin, mass fraction and recycled content, and substances of concern. UNTP models materialProvenance with origin country, mass fraction, recycled content and hazard status; the BOM structure itself is owned by the sibling engineering BOM model.

1. What is the declared material breakdown by mass fraction, origin country and recycled content? composition
2. Which substances of concern are present above declared thresholds, and under which regulatory list? requirement
3. Which bill of material governs the component composition of this type, and at which revision and effectivity? relationship
4. How was the composition determined — supplier declaration, laboratory analysis or calculation — and what is its confidence? provenance

Accessory, spare part, consumable and compatibility links

schema.org provides isAccessoryOrSparePartFor, isConsumableFor, isRelatedTo and isSimilarTo as typed relations between products. These carry operational weight: spare-part availability is a post-market obligation in several regimes, and compatibility assertions drive substitution decisions, so each link needs a direction, an asserting party and a validity period.

1. What is the typed relation to the other product type, and in which direction does it hold? relationship
2. Under what conditions or configurations does a compatibility assertion hold, and where does it fail? constraint
3. Which spare parts must remain available for this type, for how long after discontinuation, and under which obligation? requirement
4. When was each relationship last reviewed, and what invalidates it? quality

Predecessor, successor and substitution

schema.org ProductModel defines predecessorOf and successorOf, giving an explicit succession chain between model generations. Substitution differs from succession: a substitute is an acceptable alternative in a given context, may be bidirectional or one-way, and is often contract- or market-scoped rather than a property of the type itself.

1. Which type supersedes this one, which did it supersede, and from what effective date? lifecycle
2. Is a declared substitution bidirectional or one-way, and in which markets or contracts does it apply? relationship
3. Was the generation change modelled as a new type identity or as a revision of the existing type, and why? decision
4. How and when were affected trading partners notified of the succession or substitution? process

Type-instance classification and sibling product edges

This catalog item classifies zero or more item instances (WM-OBJ-001). It may be a component type in an engineering BOM (WM-OBJ-019). Schema.org provides isAccessoryOrSparePartFor, isConsumableFor, isRelatedTo and isSimilarTo at type level. Offers use itemOffered toward this type and must not be stored as edges of the type itself. Interoperability is alignment, not claimed conformance.

1. Which item-instance records (serialised or otherwise) does this catalog item classify, and is the edge always class-to-instance rather than lot-to-instance? relationship
2. Which engineering BOMs list this catalog item as a component or assembly type, and at what quantity at the type level? composition
3. Which other catalog items are declared accessories, spares, consumables, related or similar, and in which direction? relationship
4. Which external vocabularies is this record aligned to (schema.org ProductModel, GS1 trade item, ISO 22745 item, IEC 61360 class, FDA DI), and what conflicts are recorded rather than hidden? interoperability

Type lifecycle state model

A product type moves through governed states — draft, approved, released/available, restricted, discontinued, obsolete — that are distinct from the state of any physical unit and from commercial availability. Only the type record's own state belongs here; stock availability belongs to inventory and offer models.

1. Which lifecycle states are defined for a product type in this Dimension, and which transitions are permitted? state
2. Which role may authorise each state transition, and what evidence must accompany it? authority
3. How is the record's lifecycle state kept distinct from commercial availability and stock position? constraint
4. Does each state have an effective time distinct from the time it was recorded, and are both retained? temporal

Specification change control and record versioning

Two distinct version axes must be kept apart: the version of the described product type (a generation or specification revision) and the version of the record describing it (a data correction or enrichment). Confusing them causes false change signals downstream. Change effective dating from GS1 practice and dictionary release versioning from IEC CDD both apply.

1. What is the current product specification version and the current record version, and how are they incremented independently? provenance
2. How is a change classified as material (affecting product behaviour or compliance) versus editorial (correcting the record)? classification
3. Which approval path applies to each change class, and which changes may be applied without approval? process
4. Can the record as it stood at any past instant be reconstructed, and to what granularity? temporal

Discontinuation and post-market obligations

Discontinuing a type does not end its data obligations. The identifier remains permanently allocated and non-reusable, passports and compliance data must stay accessible for the product lifecycle, and support, spare-part and recall obligations continue for a defined period after the last unit is placed on the market.

1. What are the last-order, last-shipment and end-of-support dates, and how do they differ across markets? temporal
2. How long must the type record, its passport and its compliance evidence remain accessible after discontinuation, and under which obligation? retention
3. If a safety issue emerges after discontinuation, how are affected instances reached from the type record? process
4. Under what conditions may the record be deleted rather than archived, and what tombstone remains? retention

Target market and jurisdictional applicability

Most type-level assertions are market-scoped: regulatory obligations, declared quantities, labelling and classification codes differ per jurisdiction. UNTP records countryOfProduction as an ISO 3166 code; the DPP obligation depends on the product being placed on the EU market irrespective of manufacturing location, so market scope and production location are independent facts.

1. For which target markets is this type declared, using which country or region code system? spatial
2. Which attributes take different values per target market, and how is the market-scoped value represented? constraint
3. Where is the type produced, and is that independent of the markets in which it is placed? provenance
4. What authorisation, registration or notification is required before the type may be placed on each market? authority

Temporal validity and effective dating

Every material assertion about a type needs an effective period distinct from the instant it was recorded or observed. Classification scheme editions change on fixed dates, identifier changes have effective dates, and passports must remain valid across the product lifecycle, so bitemporal handling is a requirement rather than an optimisation.

1. What is the validity period of each time-scoped assertion, expressed with explicit offsets? temporal
2. Are event time and observation or ingestion time recorded separately for externally sourced assertions? provenance
3. How are future-dated changes staged so that consumers see the correct value at the correct time? process
4. What resolves overlapping or contradictory validity periods for the same attribute? exception

Responsible economic operator and market placement

For each market, one identified party bears the obligation for the type: the manufacturer, importer, authorised representative or fulfilment service provider. Under ESPR the economic operator placing the product on the market is responsible for registering the passport in the EU registry. UNTP models this generically as relatedParty with a defined role, which is the format-neutral shape to adopt.

1. Which parties hold which regulatory roles for this type, in which markets, and with what registered identifiers? ownership
2. Is the type registered in each required authority registry, and what registry identifier was returned? authority
3. How is a change of responsible operator recorded, and what happens to prior registrations and identifiers? lifecycle
4. Which regulatory obligations apply to this type per market, and what is the compliance status of each? requirement

Model-level digital product passport data

Where a passport regime applies, the type must carry the passport data set defined by its product-group delegated act, linked from a data carrier and registered so that a unique URI resolves to it. UNTP's idGranularity makes the model level explicit and lets model-level, batch-level and item-level passports coexist without conflating them.

1. Does a passport obligation apply to this type, under which instrument and delegated act, and from what date? requirement
2. At which granularity is the passport issued for this type — model, batch or item — and why? decision
3. What unique URI identifies the passport, who issued it, and where does it resolve? identity
4. Which data elements of the passport are public and which are restricted to specific user roles? access

UDI-DI, Basic UDI-DI and type-level certifications

For medical devices the Device Identifier identifies labeler plus version/model and is the GUDID key; production identifiers stay off this model. EU Basic UDI-DI is implemented as GMN and is assigned independently of packaging; GTIN (UDI-DI) remains the supply-chain trade-item key. Adding or removing a certification mark that trading partners must distinguish requires a new GTIN. Schema.org hasCertification records issuer, name and rating or identification.

1. If this type is a medical device, what is the UDI Device Identifier (and issuing agency) and the Basic UDI-DI/GMN, and are production identifiers excluded from this record? identity
2. Which certifications, marks or energy classes apply at type level, who issued them, and did add/remove of a mark require a new GTIN? evidence
3. What GUDID or equivalent registry fields (brand name, version/model, GMDN, package count, premarket number) are bound to this type? requirement
4. Does an FDA UDI exception, alternative or other regional exemption apply so that this type has no UDI-DI? exception

Conformity claims, markings and technical documentation

Type-level claims (performance, sustainability, safety) must be distinguishable from third-party attested conformity and from applied markings. UNTP separates performanceClaim (supplier assertion referencing a conformity topic, metric, standard and evidence) from independently issued conformity credentials, and models productLabel as images of certification and regulatory marks. Handover and technical documentation submodels supply the durable documents.

1. For each claim, is it a supplier self-declaration or an independently attested conformity result, and who is the assessment body? evidence
2. Against which standard, metric and threshold is each claim made, and at which version of that standard? measurement
3. Which conformity or regulatory markings are applied to the product or its packaging, and on what basis? validation
4. Which documents and media constitute the required documentation set for this type, in which locales, and which version of each is current? composition
5. When does each attestation expire or require surveillance, and what happens to the claim in the interim? temporal

Authoritative source and stewardship

The party that licensed the identifier (typically the brand owner) is normally authoritative for the type's core identity and declared attributes, while an information provider may publish on its behalf and distributors may enrich the record. Authority must be recorded per attribute group, not per record, because enrichment legitimately comes from non-authoritative parties.

1. Which party is authoritative for each attribute group of this record, and on what basis is that authority established? authority
2. Which party publishes the record on the authoritative party's behalf, and under what mandate? ownership
3. When a non-authoritative contributor supplies a conflicting value, which wins and how is the loser preserved? decision
4. Which named steward is accountable for the record's completeness and currency, and on what review cycle? ownership

Access, confidentiality and release control

Type records commonly mix public catalog data, partner-restricted commercial data, and pre-release embargoed data. Passport regimes make this explicit by granting access to different data according to user role, which means access control is an attribute-level property of the model, not solely a deployment concern.

1. Which access classes apply to which attribute groups, and who may read each class? access
2. Is the type under pre-release embargo, until when, and which attributes are embargoed? security
3. May a recipient redistribute the record or its media, to whom, and under what licence? privacy
4. What access events must be logged, retained for how long, and made available to whom? validation

Attribute-level provenance and dual timestamps

Because a catalog item record aggregates contributions from manufacturers, distributors, laboratories and scraped sources, provenance must be recorded per assertion: who asserted it, from which source system, by what method, and at which event and ingestion times. Recording only a record-level 'last updated' destroys the ability to assess trust.

1. For each asserted value, which party and source system supplied it and by what acquisition method? provenance
2. Are event time and ingestion time both retained for each assertion, with explicit offsets? temporal
3. Which values are derived or inferred rather than asserted, and what is the derivation rule and its inputs? provenance
4. What trust level is assigned to each source, and how does it affect precedence and publication? quality

Validation, quality measurement and conflict resolution

A type record must be validated against structural rules, classification-driven mandatory attribute sets, dictionary-bound value domains and cross-attribute consistency before publication, and quality must be measurable over time. Conflicts between contributors need a declared resolution procedure rather than silent last-write-wins.

1. Which validation rule sets apply to this record, at which version, and which are blocking versus advisory? validation
2. How is completeness measured against the mandatory attribute set implied by classification and market, and what is the current score? quality
3. When two sources assert different values for the same attribute, what procedure resolves it and who decides? exception
4. Which validation outcomes block publication to each downstream channel? process

Data carrier encoding and web resolution

Type identity is carried on product and packaging by barcodes, QR codes or RFID and, increasingly, by a web URI. GS1 Digital Link normalises GTINs to 14 digits in the URI path and appends key qualifiers for variant, lot and serial, while explicitly warning that applications must not assume such a URI points to a resolver. Passport regimes require the carrier to lead to the passport.

1. Which data carriers encode this type's identity, on which packaging levels, and with which encoded content? interoperability
2. How is the web URI for this type constructed, including qualifier ordering and identifier normalisation? interoperability
3. What does the URI resolve to for each requesting role and link type, and who operates the resolver? access
4. When the carrier or its encoded content changes, how are in-market goods with the previous carrier handled? lifecycle

Exchange profiles and crosswalk mappings

The same type record is projected into several external shapes: trade-item data pools, industrial asset submodels, web vocabulary markup and passport credentials. Each projection is lossy in a different direction, so mappings must be recorded explicitly with their gaps and the conflicts they cannot reconcile, and conformance must not be claimed without evidence.

1. Which external profiles is this record projected into, at which profile version, and for which consumers? interoperability
2. Which elements cannot be mapped in each direction, and how is the loss recorded rather than silently dropped? quality
3. What evidence supports any claim of conformance to an external profile, and who validated it? evidence
4. Does a round trip through a projection preserve identity, semantics and provenance, and what is verified? validation