# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-24T03:34:49Z", "synthesisSha256": "b04c5e7b2f4516310bc95c62d64b54436d2461ccdda70370ecc874832cd5355d", "providerMode": "dual-provider", "providers": [ "Claude", "Grok" ], "waivedProviders": [] }, "metaModel": { "id": "WM-OBJ-002", "registryId": "vr.wm-obj-002", "name": "Product Type / Catalog Item", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "classifier", "family": "World Models", "category": "Physical world and living systems", "industry": [ "Cross-industry" ], "domain": [ "PHY.OBJ.TYPE" ], "tags": [ "product", "type", "catalog", "item", "phy.obj.type" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-obj-002-product-type-catalog-item/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-obj-002", "model": { "registry_id": "vr.wm-obj-002", "model_id": "WM-OBJ-002", "name": "Product Type / Catalog Item", "entry_kind": "classifier", "purpose": "Provide the governed, format-neutral context an AI agent needs to understand, create, inspect and operate a product type (catalog item): the type-level abstraction that carries stable identity, classification, declared specification, variant structure, packaging form, lifecycle and compliance data, and that classifies the physical item instances produced or sold under it.", "scope_statement": "This model covers the TYPE level of a product: a governed record describing a class of goods (or catalogable service/software offering) whose members share the declared identity, technical characteristics and commercial description. It is the level identified by a GTIN under GS1 trade-item rules, by 'product model' under EU ESPR, by 'model' granularity in UNECE UNTP, by a Device Identifier / Basic UDI-DI in medical device regimes, and by schema.org ProductModel / ProductGroup. It explicitly excludes the individual instance (serial), the production batch/lot, and the commercial offer (price, availability, terms). It is storage- and interface-neutral: JSON, YAML, Markdown, HTML, Git, MCP and MongoDB are projections of this semantics, not part of it.", "in_scope": [ "Type-level identity anchors and identifier schemes (GTIN, MPN, model number, Basic UDI-DI, internal catalog key) and their allocation, change and non-reuse rules", "Designation, brand, multilingual names and marketing/technical descriptions of the type", "Classification against commercial, technical and regulatory taxonomies (GPC, UNSPSC, ECLASS/IEC CDD, HS/CN, risk classes)", "Declared characteristics bound to property dictionaries, with units, tolerances and measurement conditions", "Variant structure: variant axes, product groups, consumer product variants, and the boundary at which a variant becomes a distinct type", "Packaging-level type hierarchy (each/inner pack/case/pallet type), net content, dimensions and weights", "Type-level composition references: component types, materials, substances of concern", "Inter-type relationships: accessory, spare part, consumable, compatibility, predecessor/successor, substitution", "Lifecycle states, specification change control, record versioning, discontinuation and post-market obligations", "Market and temporal applicability: target markets, jurisdictions, effective and validity dating", "Type-level compliance: responsible economic operator, conformity claims, certifications, markings, model-level digital product passport data", "Stewardship, authority, attribute-level provenance, data quality and validation of the type record", "Interoperability: data carriers, web resolution, syndication profiles and crosswalk mappings" ], "out_of_scope": [ "Individual serialised item instances, their serial numbers, condition and custody (WM-OBJ-001)", "Production batches, lots and manufacturing runs, and batch-level passports", "Offers: price, currency, availability, sales channel, delivery terms and contract conditions", "Inventory positions, stock levels, warehouse and shelf locations", "The internal structure and effectivity logic of the engineering bill of material (WM-OBJ-019)", "Governance of the classification schemes themselves (GPC, UNSPSC, ECLASS, HS are external registries)", "Party and organisation master data (brand owner, manufacturer, notified body) beyond referencing roles", "Facility and site master data beyond referencing production locations", "Supply chain traceability events and chain-of-custody records", "Substance and material master data as substances (regulatory substance lists, CAS entries)", "Document lifecycle and content management of referenced media beyond reference and applicability", "Demand forecasting, planning parameters, costing and profitability attributes" ], "boundary_notes": [ { "neighbor": "WM-OBJ-001 Item Instance", "distinction": "The type is a class with an identity that is allocated once and never reused; the instance is an individual with a serial or production identifier. Regulators separate these explicitly: a UDI has a fixed Device Identifier (type/model) and a variable Production Identifier (lot, serial, expiry), and UNTP marks the difference with idGranularity model vs item.", "source_refs": [ "SRC-009", "SRC-015", "SRC-004" ] }, { "neighbor": "Batch / Lot", "distinction": "A batch is a subset of one model produced under shared conditions. It is neither the type nor a single instance and is carried in GS1 Digital Link as the lot (10) key qualifier and in UNTP as idGranularity 'batch'. Batch-specific values (actual measured content, production date) must not be asserted on the type record.", "source_refs": [ "SRC-004", "SRC-009" ] }, { "neighbor": "Offer / Price", "distinction": "schema.org separates Product from Offer, and states that a ProductGroup itself is not directly offered for sale. Price, availability, seller and terms belong to the offer model; only whether an attribute is 'declared' (e.g. price-on-pack, which triggers a new GTIN) touches the type record.", "source_refs": [ "SRC-001", "SRC-002", "SRC-005" ] }, { "neighbor": "WM-OBJ-019 Engineering Bill of Material", "distinction": "The BOM composes component types into an assembly; it owns quantities, positions, effectivity and alternates. The product type owns only the reference to its governing BOM and any summarised composition needed for compliance (materials, substances of concern).", "source_refs": [ "SRC-011", "SRC-009" ] }, { "neighbor": "Classification scheme registry", "distinction": "GPC bricks, UNSPSC commodities, ECLASS/IEC CDD classes and HS subheadings are externally governed registries with their own versioning. This model records the assignment (code, scheme, scheme version, assigning authority, confidence), never the taxonomy content.", "source_refs": [ "SRC-007", "SRC-010", "SRC-013", "SRC-014" ] }, { "neighbor": "Packaging / logistics unit", "distinction": "GS1 treats each, case and pallet as separate trade items with their own GTINs, but a grouping made only for transport or storage is a logistics unit identified by an SSCC, not a trade item. Logistics units are instances and are out of scope.", "source_refs": [ "SRC-006", "SRC-005" ] }, { "neighbor": "Service and software catalog items", "distinction": "GS1 defines a trade item as any item, product or service, that may be priced, ordered or invoiced, so non-physical catalog items are legitimately in scope for identity and classification, but the physical-form findings (packaging, net content, dimensions) are not applicable to them and must be omitted rather than defaulted.", "source_refs": [ "SRC-006", "SRC-014" ] }, { "neighbor": "Party / Organization", "distinction": "Brand owner, manufacturer, information provider and responsible economic operator are roles held by parties; the model carries role-scoped references and the party's registered identifier, not the party master record itself. UNTP models this as relatedParty with a defined role.", "source_refs": [ "SRC-009", "SRC-011", "SRC-008" ] } ] }, "sources": [ { "id": "SRC-001", "title": "Product - Schema.org Type", "organization": "Schema.org Community Group", "url": "https://schema.org/Product", "version_or_date": "V30.0, released 2026-03-19", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:05:00Z", "relevance": "Defines the core product vocabulary used across the web: productID, sku, mpn, gtin variants, model, isVariantOf, additionalProperty, hasCertification, hasMeasurement, and the separation of Product from Offer." }, { "id": "SRC-002", "title": "ProductGroup - Schema.org Type", "organization": "Schema.org Community Group", "url": "https://schema.org/ProductGroup", "version_or_date": "V30.0, released 2026-03-19", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:03:00Z", "relevance": "Normative definition of a group of products varying only in well-described ways, with hasVariant, productGroupID and variesBy; states that the group itself is not directly offered for sale." }, { "id": "SRC-003", "title": "ProductModel - Schema.org Type", "organization": "Schema.org Community Group", "url": "https://schema.org/ProductModel", "version_or_date": "V30.0, released 2026-03-19", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:06:00Z", "relevance": "Defines the prototypical datasheet/vendor-specification view of a product and the isVariantOf, predecessorOf and successorOf relations that structure model succession." }, { "id": "SRC-004", "title": "GS1 Digital Link Standard: URI Syntax", "organization": "GS1 AISBL", "url": "https://ref.gs1.org/standards/digital-link/uri-syntax/", "version_or_date": "Release 1.7.0, ratified August 2026", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:20:00Z", "relevance": "Normative syntax for expressing a GTIN and its key qualifiers (cpv 22 consumer product variant, lot 10, ser 21) in web URIs; establishes the type / variant / batch / instance identifier layering and 14-digit GTIN normalisation." }, { "id": "SRC-005", "title": "What are the GS1 GTIN rules? (GTIN Management Standard)", "organization": "GS1 Global Office Customer Service", "url": "https://support.gs1.org/support/solutions/articles/43000733387-what-are-the-gs1-gtin-rules-", "version_or_date": "GS1 GTIN Management Standard, accessed 2026-08-24", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:16:00Z", "relevance": "First-party confirmation that the GTIN Management Standard is the normative rule set governing when a new GTIN must be assigned, with an online decision-support tool as the authoritative decision procedure." }, { "id": "SRC-006", "title": "Standards - Global Trade Item Numbers (GTIN)", "organization": "GS1 Canada", "url": "https://gs1ca.org/standards/global-trade-item-numbers/", "version_or_date": "Accessed 2026-08-24", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:12:00Z", "relevance": "GS1 Member Organisation statement of the trade item definition, GTIN-8/12/13/14 formats, company prefix structure, the three guiding principles for requiring a GTIN change, and the rule that a GTIN is non-reusable and permanently assigned." }, { "id": "SRC-007", "title": "What is Global Product Classification (GPC)?", "organization": "GS1 UK", "url": "https://www.gs1uk.org/knowledge-hub/product-identification/what-is-global-product-classification-gpc", "version_or_date": "Accessed 2026-08-24", "source_type": "classifier", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:18:00Z", "relevance": "Describes the rules-based four-tier GPC hierarchy (Segment, Family, Class, Brick), the eight-digit brick code, the 99999999 holding code, and the linkage of GPC assignment to GTIN records and GDSN data sharing." }, { "id": "SRC-008", "title": "Digital Product Passport", "organization": "European Commission, DG GROW (Single Market Economy)", "url": "https://single-market-economy.ec.europa.eu/single-market/digital-product-passport_en", "version_or_date": "Accessed 2026-08-24; DPP Registry operational 2026-07-20", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:09:00Z", "relevance": "Authoritative statement of the ESPR (Regulation (EU) 2024/1781) DPP framework: product-group delegated acts, the EU DPP Registry generating a unique URI, the data carrier, role-based access to DPP data, and the sector rollout timeline." }, { "id": "SRC-009", "title": "UN Transparency Protocol - Digital Product Passport specification", "organization": "UNECE / UN/CEFACT", "url": "https://untp.unece.org/docs/specification/DigitalProductPassport", "version_or_date": "v0.7.0 (work in progress), v1.0 expected 2026-09-01", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:30:00Z", "relevance": "Defines idGranularity with values model / batch / item, plus modelNumber, batchNumber, itemNumber, productCategory, characteristics, packaging, productLabel, performanceClaim, relatedParty, materialProvenance, countryOfProduction and producedAtFacility." }, { "id": "SRC-010", "title": "Common Data Dictionary (CDD) - IEC TC 3", "organization": "International Electrotechnical Commission (IEC)", "url": "https://tc3.iec.ch/tc-activity/common-data-dictionary-cdd/", "version_or_date": "Accessed 2026-08-24; data model per IEC 61360-2 / ISO 13584-42 with IEC 62656-1 extensions", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:22:00Z", "relevance": "Authoritative property-dictionary infrastructure: IRDI identification (RAI#DI#VI per ISO/TS 29002-5) for classes, properties, values and units, with versioned dictionary items published as IEC/ISO standards." }, { "id": "SRC-011", "title": "Submodel Templates content hub (incl. IDTA-02006 Digital Nameplate v3.0.1, IDTA-02003 Technical Data v2.0, IDTA-02004 Handover Documentation v2.0, IDTA-02011-1 Hierarchical Structures / BoM v1.0, IDTA-02023 Carbon Footprint v1.0)", "organization": "Industrial Digital Twin Association (IDTA)", "url": "https://industrialdigitaltwin.org/en/content-hub/submodels", "version_or_date": "Accessed 2026-08-24; IDTA-02006 v3.0.1 published", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:24:00Z", "relevance": "Industrial reference structure separating manufacturer product designation, product root/family/type, article and order codes (type level) from serial number and year of construction (instance level), plus technical data, documentation, BoM and footprint submodels." }, { "id": "SRC-012", "title": "Universal Business Language Version 2.4 (OASIS Standard)", "organization": "OASIS Open", "url": "https://docs.oasis-open.org/ubl/os-UBL-2.4/UBL-2.4.html", "version_or_date": "OASIS Standard, 20 June 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:26:00Z", "relevance": "Business-document standard implementing UN/CEFACT CCTS 2.01; its Item business object carries buyer, seller, manufacturer, standard and catalogue item identifications plus commodity classification, establishing the multi-party cross-reference pattern for catalog items." }, { "id": "SRC-013", "title": "HS Nomenclature 2022 Edition", "organization": "World Customs Organization (WCO)", "url": "https://www.wcoomd.org/en/topics/nomenclature/instrument-and-tools/hs-nomenclature-2022-edition.aspx", "version_or_date": "Seventh edition, effective 1 January 2022; HS 2028 edition in preparation", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:28:00Z", "relevance": "Legal basis (HS Convention) for the internationally uniform classification of traded goods, with edition-dated amendments and correlation tables — the canonical example of a versioned regulatory classification that a product type must be re-assessed against." }, { "id": "SRC-014", "title": "UNSPSC - United Nations Standard Products and Services Code", "organization": "United Nations Global Marketplace (UNGM)", "url": "https://www.ungm.org/Public/UNSPSC", "version_or_date": "Accessed 2026-08-24", "source_type": "classifier", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:14:00Z", "relevance": "UN procurement-side confirmation of UNSPSC as a global classification of products and services with Segment / Family / Class / Commodity levels used to categorise supplier offerings." }, { "id": "SRC-015", "title": "MedTech Europe guidance for assigning Basic UDI-DI", "organization": "MedTech Europe", "url": "https://www.medtecheurope.org/wp-content/uploads/2020/06/200602_MTE-Basic-UDI-DI-guidance-v1.1_final.pdf", "version_or_date": "v1.1, June 2020", "source_type": "secondary", "primary_source": false, "authority_tier": 3, "accessed_at": "2026-08-24T09:11:00Z", "relevance": "Industry interpretation of MDR Article 2(15) and Annex VI Part C: the Basic UDI-DI is the primary identifier of a device model grouping devices with the same intended purpose, risk class and essential design and manufacturing characteristics — a counterexample where the 'model' level sits above trade-item identity." }, { "id": "SRC-016", "title": "Global Trade Item Number (GTIN)", "organization": "GS1 AISBL", "url": "https://www.gs1.org/standards/id-keys/gtin", "version_or_date": "accessed 2026-08-24", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T18:00:00Z", "relevance": "Defines GTIN as the GS1 key for any trade item that may be priced, ordered or invoiced, and points to General Specifications and the GTIN Management Standard as governing assignment." }, { "id": "SRC-017", "title": "GTIN Management Standard, Release 1.1, Ratified", "organization": "GS1 AISBL", "url": "https://ref.gs1.org/standards/gtin-management/", "version_or_date": "Release 1.1, September 2023", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T18:00:00Z", "relevance": "Normative rules for when a new GTIN is required (new product, formulation/functionality, net content, dimensions, certification mark, brand, promotional item, pack quantity, assortment, price-on-pack) and that local regulation supersedes the GS1 minimum." }, { "id": "SRC-018", "title": "schema.org Offer", "organization": "Schema.org", "url": "https://schema.org/Offer", "version_or_date": "vocabulary snapshot Google index July 2026", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T18:00:00Z", "relevance": "Defines the offer as transfer of rights with price, availability and businessFunction; itemOffered points at Product. Establishes the type-versus-offer boundary this model must not collapse." }, { "id": "SRC-019", "title": "schema.org IndividualProduct", "organization": "Schema.org", "url": "https://schema.org/IndividualProduct", "version_or_date": "vocabulary snapshot Google index July 2026", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T18:00:00Z", "relevance": "A single identifiable product instance with serialNumber; Digital Link guidance forbids attaching AI 21 serial URIs to class-level Product/ProductModel." }, { "id": "SRC-020", "title": "UDI Basics", "organization": "U.S. Food and Drug Administration", "url": "https://www.fda.gov/medical-devices/unique-device-identification-system-udi-system/udi-basics", "version_or_date": "page current as of 2026-08-23; UDI Rule 78 FR 58826, 2013-09-24", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T18:00:00Z", "relevance": "Splits UDI into Device Identifier (version/model, submitted to GUDID) versus Production Identifier (lot, serial, expiry, manufacture date). DI is the regulated type key; PI is instance/sub-class and out of this model." }, { "id": "SRC-021", "title": "GS1 General Specifications Change Notification WR 24-004 — Global Model Number (GMN) and medical device family", "organization": "GS1 AISBL", "url": "https://ref.gs1.org/standards/genspecs/gscn/2024/GSCN-24-004-MedicalDeviceDefinition.pdf", "version_or_date": "GS1 General Specifications Release 24.0, ratified January 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T18:00:00Z", "relevance": "GMN identifies a product model/family, SHALL NOT identify a trade item, SHALL NOT be reissued, and maps to EU Basic UDI-DI. Brand owner owns both GMN and GTIN. GTIN SHALL associate with at most one GMN." }, { "id": "SRC-022", "title": "ISO 22745-1:2010 Industrial automation systems and integration — Open technical dictionaries and their application to master data — Part 1: Overview and fundamental principles", "organization": "International Organization for Standardization", "url": "https://www.iso.org/standard/53995.html", "version_or_date": "2010-02, confirmed 2020", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T18:00:00Z", "relevance": "Architecture for cataloguing items as class-plus-property-value master data via an open technical dictionary and identification guide, satisfying ISO 8000-110 characteristic-data exchange." }, { "id": "SRC-023", "title": "IEC 61360-2:2012 Standard data element types with associated classification scheme for electric components — Part 2: EXPRESS dictionary schema", "organization": "International Electrotechnical Commission", "url": "https://webstore.iec.ch/en/publication/5381", "version_or_date": "2012 (third edition)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T18:00:00Z", "relevance": "Formal dictionary model separating characterization class from categorization class; classes are abstractions of product sets sharing properties. Basis of IEC CDD and eCl@ss." }, { "id": "SRC-024", "title": "GS1 Global Product Classification (GPC) Browser", "organization": "GS1 AISBL", "url": "https://www.gs1.org/services/gpc-browser", "version_or_date": "GPC as of November 2025 (GDSN) v20251127", "source_type": "classifier", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T18:00:00Z", "relevance": "Authoritative four-level retail classification (Segment/Family/Class/Brick plus brick attributes). One brick per GTIN; many GTINs per brick. Mandated category method for GDSN." }, { "id": "SRC-025", "title": "PROV-O: The PROV Ontology", "organization": "World Wide Web Consortium", "url": "https://www.w3.org/TR/prov-o/", "version_or_date": "W3C Recommendation 30 April 2013", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T18:00:00Z", "relevance": "Provenance of catalog master-data records: entities, activities, agents, generation and derivation, so type records can separate event time from ingestion time and attribute stewardship." }, { "id": "SRC-026", "title": "GS1 Traceability Standard (GTS2) — identification granularity (class, batch/lot, instance)", "organization": "GS1 AISBL", "url": "https://www.gs1.org/sites/default/files/gts2_standard_ratified.pdf", "version_or_date": "ratified PDF, document dated 2019-09-05 on published file", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T18:00:00Z", "relevance": "Explicit class-level GTIN versus GTIN+lot versus GTIN+serial. Class-level data examples: product name, ingredients, nutritional information, net content, packaging dimensions." }, { "id": "SRC-027", "title": "Can a GTIN be re-used?", "organization": "GS1 AISBL", "url": "https://support.gs1.org/support/solutions/articles/43000734325-can-a-gtin-be-re-used-", "version_or_date": "policy effective after December 2018 / 1 January 2019; article cites General Specifications section 4.17.1", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T18:00:00Z", "relevance": "After 2018 a GTIN allocated to a trade item SHALL NOT be reallocated, with narrow never-produced and unmodified-reintroduction exceptions; underpins retention of retired catalog identifiers." }, { "id": "SRC-028", "title": "UNSPSC — How UNSPSC Differs from GPC", "organization": "UNSPSC / GS1 US (archived user guide)", "url": "https://web.archive.org/web/20211122212005if_/https:/www.unspsc.org/Portals/3/Documents/User%20Guides/UNSPSC_QSG_GPC_Comparison.pdf?ver=2021-08-23-085514-233", "version_or_date": "guide version archived 2021-08-23", "source_type": "classifier", "primary_source": false, "authority_tier": 3, "accessed_at": "2026-08-24T18:00:00Z", "relevance": "States there is no official mapping between UNSPSC (procurement spend) and GPC (retail/GDSN). Prevents treating one classification as a substitute for the other." }, { "id": "SRC-029", "title": "WCO Harmonized System Classification Handbook", "organization": "World Customs Organization", "url": "https://www.wcoesarocb.org/wp-content/uploads/2018/07/2.-WCO_HS-CLASSIFICATION-HANDBOOK.pdf", "version_or_date": "handbook describing HS structure; HS 2022 nomenclature in force for international trade", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T18:00:00Z", "relevance": "HS is the customs/statistical goods nomenclature (4-digit headings, 5/6-digit subheadings, national extensions). Type-level tariff classification is distinct from GPC/UNSPSC." }, { "id": "SRC-030", "title": "ISO 8000-110:2021 Data quality — Part 110: Master data: Exchange of characteristic data: Syntax, semantic encoding, and conformance to data specification", "organization": "International Organization for Standardization", "url": "https://www.iso.org/standard/81705.html", "version_or_date": "Second edition 2021-11", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T18:00:00Z", "relevance": "Computer-checkable requirements for exchanging item characteristic master data against a data specification and encoded dictionary; companion to ISO 22745 catalogues." } ], "structure": { "bundles": [ { "id": "identity-and-designation", "name": "Identity and Designation", "description": "How a product type acquires, keeps, changes and loses its identity, and how it is named and cross-referenced by the parties that trade it.", "rationale": "Identity is the load-bearing concern for a type-level model: GS1 makes GTIN allocation and non-reuse normative, ESPR/UNTP make model-level identifiers the anchor for passports, and medical device regimes define a distinct model identifier. Naming and partner keys are separated from identity because they are mutable and non-authoritative.", "source_refs": [ "SRC-004", "SRC-005", "SRC-006", "SRC-009", "SRC-012", "SRC-015" ], "layers": [ { "id": "identifier-assignment-and-scope", "name": "Identifier Assignment and Scope", "description": "The authoritative identity anchor of the type, the schemes that issue it, its scope of application, and the rules that force a new identity or forbid reuse.", "source_refs": [ "SRC-004", "SRC-005", "SRC-006", "SRC-009", "SRC-015" ], "findings": [ { "id": "type-identity-anchor", "name": "Type-level identity anchor and issuing scheme", "description": "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.", "source_refs": [ "SRC-004", "SRC-006", "SRC-009", "SRC-015" ], "questions": [ { "id": "q-identity-anchor-scheme", "text": "Which identifier scheme is authoritative for this product type, who licenses or issues it, and what is the issuing authority's registered identifier?", "kind": "identity", "answer_data": [ "identifier scheme code or IRI", "issued identifier value", "issuing authority identifier (e.g. GS1 company prefix, GLN, registered operator id)", "scheme licence or registration evidence reference" ] }, { "id": "q-identity-granularity", "text": "At which granularity does this identifier bind — model/type, sub-type variant, packaging level, or a grouping above trade-item identity?", "kind": "classification", "answer_data": [ "granularity code (model | sub-variant | packaging-level | model-group)", "rationale text", "reference to the parent or child identifier at adjacent granularity" ] }, { "id": "q-identity-fallback", "text": "If no external authoritative scheme applies, what internally assigned identifier is used and how is its uniqueness guaranteed?", "kind": "identity", "answer_data": [ "internal identifier value (UUID or ULID)", "namespace or IRI base", "uniqueness constraint statement", "assignment timestamp (RFC 3339 with offset or Z)" ] }, { "id": "q-identity-resolvability", "text": "Is the identity anchor resolvable to a network-retrievable representation, and under whose control is that resolution?", "kind": "interoperability", "answer_data": [ "canonical IRI or resolvable URI", "resolver operator identifier", "resolution guarantee statement (resolvable | opaque)" ] } ], "data_elements": [ { "id": "authoritative-type-id", "name": "authoritativeTypeIdentifier", "description": "The single authoritative identifier of the product type within its declared scheme.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-006", "SRC-009" ] }, { "id": "identifier-scheme", "name": "identifierScheme", "description": "Coded reference to the scheme that governs the authoritative identifier (e.g. GTIN, Basic UDI-DI, internal ULID namespace).", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-004" ] }, { "id": "identifier-issuer", "name": "identifierIssuer", "description": "Reference to the party or registry that licensed or issued the identifier.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-009" ] }, { "id": "canonical-iri", "name": "canonicalIri", "description": "Governed resolvable IRI for the type, where one exists (e.g. a GS1 Digital Link URI or a DPP registry URI).", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-008" ] }, { "id": "identifier-assigned-at", "name": "identifierAssignedAt", "description": "Instant the identifier was assigned, recorded separately from the record creation instant.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "product-type-master-record", "name": "Product type master record", "description": "The canonical, format-neutral record instance for one product type, carrying identity, classification, characteristics, lifecycle state and references.", "media_or_form": [ "structured record", "serialisable document", "graph node" ], "serial": false, "identity_strategy": "Keyed by authoritativeTypeIdentifier plus identifierScheme; record revisions are addressed by an immutable record version identifier, never by date alone.", "source_refs": [ "SRC-004", "SRC-006", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "identifier-change-and-non-reuse", "name": "Identifier change triggers and non-reuse", "description": "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.", "source_refs": [ "SRC-005", "SRC-006", "SRC-004" ], "questions": [ { "id": "q-change-trigger-evaluation", "text": "Which declared attributes, when changed, force allocation of a new type identifier rather than a record revision?", "kind": "constraint", "answer_data": [ "list of change-triggering attribute references", "governing rule set identifier and version", "decision outcome (new identifier | revision)", "evaluator identity and evaluation timestamp" ] }, { "id": "q-change-effective-date", "text": "From which effective date does a type identifier change apply, and how are in-market goods carrying the previous identifier handled?", "kind": "temporal", "answer_data": [ "change effective date", "transition window start and end (RFC 3339)", "coexistence policy statement", "reference to superseded identifier" ] }, { "id": "q-identifier-reuse-policy", "text": "Under what conditions, if any, may a retired identifier be reassigned, and what is the enforced quarantine period?", "kind": "lifecycle", "answer_data": [ "reuse permitted flag", "quarantine duration", "governing policy reference", "enforcement mechanism description" ] }, { "id": "q-change-evidence", "text": "What evidence records the change decision so it can be audited and, if disputed, reversed?", "kind": "evidence", "answer_data": [ "change decision record reference", "supporting rule citation", "approver identity", "decision timestamp" ] } ], "data_elements": [ { "id": "supersedes-identifier", "name": "supersedesIdentifier", "description": "Identifier of the product type that this type replaces as a result of a change-triggering modification.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-003" ] }, { "id": "identifier-status", "name": "identifierStatus", "description": "Coded state of the identifier itself: allocated, in-use, retired, quarantined.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-006" ] }, { "id": "change-effective-date", "name": "changeEffectiveDate", "description": "Date from which the identifier change takes commercial and regulatory effect.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "change-rule-reference", "name": "changeRuleReference", "description": "Reference to the specific rule and rule-set version that justified a new identifier or a revision.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-006" ] } ], "artifacts": [ { "id": "identifier-decision-log", "name": "Identifier change decision log", "description": "Append-only log of evaluations of change rules against proposed modifications, with outcome, rule citation, approver and timestamps.", "media_or_form": [ "append-only log", "structured record set" ], "serial": true, "identity_strategy": "Zero-padded monotonic sequence within the product type identity, each entry stamped with an RFC 3339 decision timestamp and the deciding party identifier.", "source_refs": [ "SRC-005", "SRC-006" ] } ], "inline_only_rationale": null } ] }, { "id": "designation-and-secondary-keys", "name": "Designation and Secondary Keys", "description": "Human-facing designation of the type and the non-authoritative keys through which trading partners refer to it.", "source_refs": [ "SRC-001", "SRC-003", "SRC-011", "SRC-012" ], "findings": [ { "id": "designation-brand-and-naming", "name": "Manufacturer designation, brand and multilingual naming", "description": "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.", "source_refs": [ "SRC-011", "SRC-001", "SRC-003", "SRC-006" ], "questions": [ { "id": "q-designation-hierarchy", "text": "What are the product root, family and type designations, and which of them is the customer-facing name?", "kind": "definition", "answer_data": [ "product root designation", "product family designation", "product type designation", "customer-facing name and its locale" ] }, { "id": "q-brand-ownership", "text": "Which brand is asserted on this type, who owns that brand, and is it the primary brand for identifier-change purposes?", "kind": "ownership", "answer_data": [ "brand name", "brand owner party reference", "primary brand flag", "trademark registration reference" ] }, { "id": "q-name-localisation", "text": "Which locales are names and descriptions maintained in, and which locale is authoritative when translations conflict?", "kind": "interoperability", "answer_data": [ "locale tag list (BCP 47)", "authoritative locale tag", "translation status per locale", "last translation review timestamp" ] }, { "id": "q-name-change-control", "text": "Can a designation change without changing the type identity, and what approval is required?", "kind": "process", "answer_data": [ "name-change-permitted flag", "approval role", "effective date of new designation", "previous designation value and retirement timestamp" ] } ], "data_elements": [ { "id": "manufacturer-designation", "name": "manufacturerProductDesignation", "description": "Manufacturer's designation for the product type, locale-scoped.", "value_kind": "text", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-011" ] }, { "id": "brand-name", "name": "brandName", "description": "Brand asserted on the type, with a reference to the brand-owning party.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-012" ] }, { "id": "product-family", "name": "productFamilyDesignation", "description": "Family or product-line grouping designation above the type.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "description-text", "name": "descriptionText", "description": "Locale-scoped marketing or technical description of the type.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-012" ] } ], "artifacts": [], "inline_only_rationale": "Designations and brand strings are inline attributes of the master record; the only durable artifacts they imply (label artwork, brand guidelines) are governed by the media and documentation finding rather than duplicated here." }, { "id": "secondary-and-partner-keys", "name": "Secondary, partner and legacy keys", "description": "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.", "source_refs": [ "SRC-012", "SRC-001", "SRC-011" ], "questions": [ { "id": "q-partner-key-scope", "text": "For each secondary key, which party and which channel or contract does it apply within?", "kind": "identity", "answer_data": [ "key value", "key role code (buyer | seller | manufacturer | catalogue | marketplace | legacy)", "owning party reference", "validity period" ] }, { "id": "q-key-collision", "text": "How are collisions handled when the same secondary key value is used by different parties for different types?", "kind": "constraint", "answer_data": [ "uniqueness scope statement", "collision detection rule", "resolution procedure reference" ] }, { "id": "q-legacy-key-retention", "text": "Which legacy keys must be retained after migration, and for how long, to keep historical transactions resolvable?", "kind": "retention", "answer_data": [ "legacy key value", "source system identifier", "retention end date", "retention justification" ] } ], "data_elements": [ { "id": "secondary-key", "name": "secondaryIdentifier", "description": "A non-authoritative identifier with an explicit role and owning party scope.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-001" ] }, { "id": "secondary-key-role", "name": "secondaryIdentifierRole", "description": "Coded role of a secondary identifier (buyer, seller, manufacturer, catalogue, marketplace, legacy).", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "order-code", "name": "orderCodeOfManufacturer", "description": "Manufacturer order or configuration code used to procure the type.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [ { "id": "key-crosswalk-table", "name": "Identifier crosswalk table", "description": "Mapping set relating the authoritative type identifier to each secondary key, with party scope, validity period and provenance of the mapping.", "media_or_form": [ "mapping table", "structured record set" ], "serial": false, "identity_strategy": "Keyed by the tuple (authoritative type identifier, secondary key role, owning party reference); mapping revisions carry their own version identifier.", "source_refs": [ "SRC-012", "SRC-001" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "classification-and-characteristics", "name": "Classification and Declared Characteristics", "description": "How the type is placed within external taxonomies and how its declared technical properties are given machine-interpretable meaning, including variant structure.", "rationale": "Classification and property semantics are the two mechanisms that make a catalog item comparable and machine-actionable. Both are governed by independent external registries (GPC, UNSPSC, HS, IEC CDD) with their own versioning, so assignments must be recorded as dated, scheme-scoped assertions rather than intrinsic attributes.", "source_refs": [ "SRC-007", "SRC-010", "SRC-013", "SRC-014", "SRC-009", "SRC-002" ], "layers": [ { "id": "classification-alignment", "name": "Classification Alignment", "description": "Assignments of the type to commercial, technical and regulatory classification schemes, each with its own version and authority.", "source_refs": [ "SRC-007", "SRC-010", "SRC-013", "SRC-014", "SRC-009" ], "findings": [ { "id": "commercial-technical-classification", "name": "Commercial and technical classification assignment", "description": "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.", "source_refs": [ "SRC-007", "SRC-014", "SRC-010", "SRC-009" ], "questions": [ { "id": "q-classification-set", "text": "Which classification schemes is this type assigned in, and what is the code, scheme version and effective date of each assignment?", "kind": "classification", "answer_data": [ "scheme identifier or IRI", "scheme version or release", "assigned code", "assignment effective date" ] }, { "id": "q-classification-authority", "text": "Who made each classification assignment, and was it self-declared, partner-supplied or authority-verified?", "kind": "authority", "answer_data": [ "assigning party reference", "assignment basis code (self-declared | partner | authority-verified)", "verification evidence reference" ] }, { "id": "q-classification-primary", "text": "Which single classification is treated as primary for navigation and reporting when schemes disagree?", "kind": "decision", "answer_data": [ "primary scheme identifier", "selection rationale", "conflict notes" ] }, { "id": "q-classification-provisional", "text": "Is any assignment provisional or a holding value pending a scheme update, and when must it be revisited?", "kind": "quality", "answer_data": [ "provisional flag", "holding code value (e.g. GPC 99999999)", "review due date", "responsible steward reference" ] } ], "data_elements": [ { "id": "classification-assignment", "name": "classificationAssignment", "description": "A scheme-scoped classification assertion comprising scheme, scheme version, code, basis and effective dates.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-009", "SRC-014" ] }, { "id": "primary-classification", "name": "primaryClassificationRef", "description": "Reference to the classification assignment designated as primary.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "classification-review-due", "name": "classificationReviewDue", "description": "Date by which a provisional or holding classification must be re-evaluated.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "classification-assignment-set", "name": "Classification assignment set", "description": "The complete, dated set of classification assertions for the type across all schemes, each with scheme version and assigning authority.", "media_or_form": [ "structured record set", "tabular export" ], "serial": false, "identity_strategy": "Keyed by (type identifier, scheme identifier, scheme version); superseded assignments are retained with closed validity periods rather than deleted.", "source_refs": [ "SRC-007", "SRC-009", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "regulatory-nomenclature-and-risk-class", "name": "Regulatory nomenclature and risk classification", "description": "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.", "source_refs": [ "SRC-013", "SRC-015", "SRC-009" ], "questions": [ { "id": "q-customs-classification", "text": "What is the customs nomenclature code for this type, under which HS edition and which national extension?", "kind": "classification", "answer_data": [ "HS subheading (6-digit)", "national extension code and length", "HS edition year", "classification ruling reference if any" ] }, { "id": "q-regulatory-risk-class", "text": "Which regulatory risk or hazard classes apply to this type, under which legal instrument and jurisdiction?", "kind": "requirement", "answer_data": [ "risk or hazard class code", "governing legal instrument reference", "jurisdiction code", "classification date" ] }, { "id": "q-nomenclature-edition-change", "text": "When the nomenclature edition changes, who re-assesses the code and how is the transition recorded?", "kind": "lifecycle", "answer_data": [ "responsible role", "re-assessment due date", "previous and new codes", "correlation table reference" ] }, { "id": "q-classification-dispute", "text": "Has any classification been challenged or overridden by a customs or regulatory authority, and what is the binding outcome?", "kind": "exception", "answer_data": [ "authority reference", "ruling identifier", "binding code", "ruling validity period" ] } ], "data_elements": [ { "id": "hs-code", "name": "customsNomenclatureCode", "description": "HS subheading plus national extension, with the edition year that governs it.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "regulatory-risk-class", "name": "regulatoryRiskClass", "description": "Risk, hazard or device class assigned under a named legal instrument and jurisdiction.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "classification-ruling-ref", "name": "classificationRulingReference", "description": "Reference to a binding authority ruling on the classification of this type.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [], "inline_only_rationale": "Regulatory codes are inline coded values on the master record; the binding evidence (customs rulings, classification opinions) is a document governed by the conformity-evidence finding and is referenced, not duplicated here." } ] }, { "id": "characteristic-semantics", "name": "Characteristic Semantics", "description": "How declared technical properties of the type are given stable meaning, units and measurement basis.", "source_refs": [ "SRC-010", "SRC-011", "SRC-001", "SRC-009" ], "findings": [ { "id": "property-semantics-and-dictionary-binding", "name": "Property semantics and dictionary binding", "description": "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.", "source_refs": [ "SRC-010", "SRC-001", "SRC-011" ], "questions": [ { "id": "q-property-semantic-id", "text": "Which dictionary definition and version does each declared characteristic bind to?", "kind": "interoperability", "answer_data": [ "property semantic identifier (IRDI or IRI)", "dictionary identifier and release", "property preferred name", "binding confidence" ] }, { "id": "q-property-unbound", "text": "Which characteristics have no dictionary binding, and what is the plan or justification for leaving them unbound?", "kind": "quality", "answer_data": [ "unbound property label", "justification text", "candidate dictionary entry reference", "review due date" ] }, { "id": "q-property-mandatory-set", "text": "Which characteristics are mandatory for this type's classification or regulatory category, and which are optional?", "kind": "requirement", "answer_data": [ "property reference", "obligation code (mandatory | conditional | optional)", "source of the obligation (classification brick, delegated act, contract)" ] }, { "id": "q-property-versioning", "text": "What happens to recorded values when a bound property definition is superseded in a new dictionary release?", "kind": "lifecycle", "answer_data": [ "superseding property identifier", "migration rule", "value re-validation status", "migration timestamp" ] } ], "data_elements": [ { "id": "characteristic-property-ref", "name": "characteristicPropertyRef", "description": "Reference to the governed property definition a characteristic binds to, including dictionary release.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010", "SRC-011" ] }, { "id": "characteristic-obligation", "name": "characteristicObligation", "description": "Coded obligation level for a characteristic within a given classification or regulatory context.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010", "SRC-007" ] }, { "id": "characteristic-label", "name": "characteristicLabel", "description": "Locale-scoped human label for the characteristic, distinct from its semantic identifier.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "Property bindings are references into externally governed dictionaries; the dictionary content is an external registry artifact and must not be copied into this model, so this finding is deliberately reference-only." }, { "id": "declared-values-units-and-measurement", "name": "Declared values, units and measurement basis", "description": "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.", "source_refs": [ "SRC-009", "SRC-010", "SRC-001", "SRC-011" ], "questions": [ { "id": "q-value-and-unit", "text": "What value and unit of measure is declared for each characteristic, and which unit code system is used?", "kind": "measurement", "answer_data": [ "numeric or coded value", "unit code", "unit code system identifier", "value data type" ] }, { "id": "q-declared-vs-measured", "text": "Is each value nominal/declared, a specification limit, or a typical value, and what tolerance applies?", "kind": "measurement", "answer_data": [ "value semantics code (nominal | minimum | maximum | typical | declared)", "tolerance expression", "confidence or uncertainty" ] }, { "id": "q-measurement-conditions", "text": "Under which test method, standard and ambient conditions does the declared value hold?", "kind": "evidence", "answer_data": [ "test method or standard reference", "measurement conditions description", "testing party reference", "test report reference" ] }, { "id": "q-value-currency", "text": "When was each declared value last verified, and when does it expire or require re-testing?", "kind": "temporal", "answer_data": [ "value assertion timestamp", "last verification timestamp", "re-verification due date" ] } ], "data_elements": [ { "id": "characteristic-value", "name": "characteristicValue", "description": "The declared value asserted for a characteristic at type level.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-010" ] }, { "id": "value-semantics-code", "name": "valueSemanticsCode", "description": "Whether the value is nominal, minimum, maximum, typical or a declared regulatory figure.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "test-method-ref", "name": "testMethodReference", "description": "Reference to the standard or method under which the declared value was determined.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-011" ] }, { "id": "value-verified-at", "name": "valueVerifiedAt", "description": "Instant at which the declared value was last verified, recorded separately from the assertion instant.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "technical-datasheet", "name": "Technical datasheet / specification sheet", "description": "The published specification document for the type, carrying declared characteristics, units, tolerances and test conditions, in one or more locales.", "media_or_form": [ "PDF document", "HTML page", "structured technical data submodel" ], "serial": false, "identity_strategy": "Keyed by (type identifier, datasheet document identifier, document version); each release is immutable and carries an RFC 3339 issue timestamp.", "source_refs": [ "SRC-011", "SRC-003", "SRC-009" ] } ], "inline_only_rationale": null } ] }, { "id": "variant-structure", "name": "Variant Structure", "description": "How closely related types are grouped, how they vary, and where the boundary between a variant and a distinct type is drawn.", "source_refs": [ "SRC-002", "SRC-003", "SRC-004", "SRC-005" ], "findings": [ { "id": "variant-axes-and-product-groups", "name": "Variant axes, product groups and sub-type qualifiers", "description": "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.", "source_refs": [ "SRC-002", "SRC-003", "SRC-004", "SRC-005" ], "questions": [ { "id": "q-variant-axes", "text": "Which properties are the declared variant axes of the group this type belongs to, and what value does this type take on each?", "kind": "composition", "answer_data": [ "variant axis property references", "axis value per type", "group identifier", "axis completeness flag" ] }, { "id": "q-variant-vs-new-type", "text": "Which variations are represented as separate type identities and which are carried as sub-variant qualifiers under a shared identifier?", "kind": "decision", "answer_data": [ "variation description", "resolution code (separate type | shared identity with qualifier)", "governing rule reference", "qualifier value where applicable" ] }, { "id": "q-group-membership", "text": "Is the product group's membership closed and enumerable, or open and configurable at order time?", "kind": "constraint", "answer_data": [ "membership model code (enumerated | configurable)", "member type references", "configuration rule reference", "valid combination constraints" ] }, { "id": "q-group-offerability", "text": "Is the group itself ever presented as orderable, and if not, how is that constraint enforced downstream?", "kind": "constraint", "answer_data": [ "group orderable flag", "enforcement rule statement", "downstream channel references" ] } ], "data_elements": [ { "id": "product-group-ref", "name": "productGroupRef", "description": "Reference to the product group or prototype that this type is a variant of.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "varies-by", "name": "variesBy", "description": "The property references that constitute the variant axes of the group.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "sub-variant-qualifier", "name": "subVariantQualifier", "description": "Qualifier distinguishing variants that share the type identifier (e.g. GS1 consumer product variant).", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "configuration-rule-ref", "name": "configurationRuleReference", "description": "Reference to the rule set constraining valid option combinations for configurable types.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-011" ] } ], "artifacts": [ { "id": "variant-matrix", "name": "Variant matrix", "description": "Tabulation of the group's variant axes against member type identifiers, including sub-variant qualifiers and invalid combinations.", "media_or_form": [ "matrix table", "structured record set" ], "serial": false, "identity_strategy": "Keyed by product group identifier and matrix version; each cell references a member type identifier or a declared gap.", "source_refs": [ "SRC-002", "SRC-004" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "packaging-composition-and-relations", "name": "Packaging, Composition and Inter-Type Relations", "description": "The physical form the type takes in trade, what it is made of at type level, and how it relates to other types.", "rationale": "GS1 treats each packaging level as its own trade item with its own identifier, so packaging is a type-level structural concern rather than a logistics detail. Composition and inter-type relations are needed for compliance, spare-part supply and substitution, and each is separately sourced.", "source_refs": [ "SRC-006", "SRC-009", "SRC-001", "SRC-003", "SRC-011" ], "layers": [ { "id": "packaging-and-physical-form", "name": "Packaging and Physical Form", "description": "The packaging-level type hierarchy, declared content quantities and physical envelope of the type, plus its material and component composition.", "source_refs": [ "SRC-006", "SRC-009", "SRC-011", "SRC-005" ], "findings": [ { "id": "packaging-level-type-hierarchy", "name": "Packaging-level type hierarchy", "description": "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.", "source_refs": [ "SRC-006", "SRC-005", "SRC-009" ], "questions": [ { "id": "q-packaging-levels", "text": "Which packaging levels exist for this product, what identifier does each carry, and what is the parent-child containment quantity?", "kind": "composition", "answer_data": [ "packaging level code (each | inner pack | case | pallet)", "identifier per level", "contained child type reference", "contained quantity" ] }, { "id": "q-packaging-homogeneity", "text": "Is each higher packaging level homogeneous, or a pre-defined assortment of different child types?", "kind": "classification", "answer_data": [ "homogeneity flag", "assortment composition list", "assortment stability statement" ] }, { "id": "q-consumer-unit-flag", "text": "Which packaging level is the consumer or point-of-sale unit, and which levels are orderable or invoiceable?", "kind": "classification", "answer_data": [ "consumer unit flag per level", "orderable flag per level", "invoiceable flag per level", "target channel references" ] }, { "id": "q-packaging-materials", "text": "What packaging materials and recyclability data are declared for each level?", "kind": "requirement", "answer_data": [ "packaging material code", "material mass or fraction", "recyclability or recycled-content declaration", "governing regulation reference" ] } ], "data_elements": [ { "id": "packaging-level-code", "name": "packagingLevelCode", "description": "Coded packaging level of this type within the trade-item hierarchy.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "contains-child-type", "name": "containsChildType", "description": "Reference to the contained child type together with the contained quantity.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-009" ] }, { "id": "packaging-material", "name": "packagingMaterial", "description": "Declared packaging material with mass or fraction and recyclability attributes.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "packaging-hierarchy-specification", "name": "Packaging hierarchy specification", "description": "Declared containment structure across packaging levels with identifiers, quantities, consumer-unit flags and packaging materials.", "media_or_form": [ "structured record set", "hierarchy diagram" ], "serial": false, "identity_strategy": "Keyed by the identifier of the highest declared packaging level plus a hierarchy version; leaf nodes reference the consumer-unit type identifier.", "source_refs": [ "SRC-006", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "net-content-dimensions-and-weight", "name": "Net content, dimensions and weights", "description": "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.", "source_refs": [ "SRC-006", "SRC-005", "SRC-009", "SRC-001" ], "questions": [ { "id": "q-net-content", "text": "What is the declared net content of the type, in which unit, and is it a legally declared quantity?", "kind": "measurement", "answer_data": [ "net content value", "unit code", "legal declaration flag", "governing metrology rule reference" ] }, { "id": "q-dimensions-basis", "text": "On what basis are the declared dimensions and weights measured — as packaged, as displayed, or as shipped?", "kind": "measurement", "answer_data": [ "measurement basis code", "depth, width, height values with unit", "gross and net weight with unit", "measurement date" ] }, { "id": "q-quantity-tolerance", "text": "What tolerance applies to declared quantities, and at what deviation does a change require a new type identifier?", "kind": "constraint", "answer_data": [ "tolerance expression", "identifier-change threshold statement", "governing rule reference" ] }, { "id": "q-quantity-locale-variance", "text": "Do declared quantities differ by target market due to metrology or labelling rules, and how is that represented?", "kind": "interoperability", "answer_data": [ "target market code", "market-specific declared value and unit", "rule reference" ] } ], "data_elements": [ { "id": "net-content", "name": "netContent", "description": "Declared net content quantity with unit of measure.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-001" ] }, { "id": "gross-weight", "name": "grossWeight", "description": "Declared gross weight of the type at its packaging level.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "outer-dimensions", "name": "outerDimensions", "description": "Declared depth, width and height with unit and measurement basis.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-009" ] }, { "id": "measurement-basis", "name": "measurementBasisCode", "description": "Basis under which dimensions and weights were determined.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "Declared quantities are inline attributes of the master record; their supporting evidence is a measurement or test report already governed by the conformity-evidence finding." }, { "id": "component-material-and-substance-composition", "name": "Type-level component, material and substance composition", "description": "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.", "source_refs": [ "SRC-009", "SRC-011", "SRC-008" ], "questions": [ { "id": "q-material-breakdown", "text": "What is the declared material breakdown by mass fraction, origin country and recycled content?", "kind": "composition", "answer_data": [ "material name or code", "mass fraction", "origin country code (ISO 3166)", "recycled content fraction" ] }, { "id": "q-substances-of-concern", "text": "Which substances of concern are present above declared thresholds, and under which regulatory list?", "kind": "requirement", "answer_data": [ "substance identifier", "concentration or threshold", "regulatory list reference", "declaration date" ] }, { "id": "q-bom-linkage", "text": "Which bill of material governs the component composition of this type, and at which revision and effectivity?", "kind": "relationship", "answer_data": [ "BOM identifier", "BOM revision", "effectivity range", "component type references" ] }, { "id": "q-composition-confidence", "text": "How was the composition determined — supplier declaration, laboratory analysis or calculation — and what is its confidence?", "kind": "provenance", "answer_data": [ "determination method code", "evidence reference", "determining party reference", "confidence statement" ] } ], "data_elements": [ { "id": "material-provenance", "name": "materialProvenance", "description": "Material breakdown entry with mass fraction, origin country, recycled content and hazard status.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "substance-of-concern", "name": "substanceOfConcern", "description": "Declared substance with concentration and the regulatory list that makes it reportable.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-008" ] }, { "id": "governing-bom-ref", "name": "governingBomReference", "description": "Reference to the bill of material revision that composes this type from component types.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [ { "id": "material-declaration", "name": "Material and substance declaration", "description": "Type-level declaration of material composition and substances of concern with supporting method and evidence references.", "media_or_form": [ "structured declaration", "PDF document", "verifiable credential" ], "serial": false, "identity_strategy": "Keyed by (type identifier, declaration identifier, declaration version) with an RFC 3339 issue timestamp and issuing party reference.", "source_refs": [ "SRC-009", "SRC-008" ] } ], "inline_only_rationale": null } ] }, { "id": "inter-type-relationships", "name": "Inter-Type Relationships", "description": "Typed links between product types that express compatibility, dependency and succession.", "source_refs": [ "SRC-001", "SRC-003", "SRC-011" ], "findings": [ { "id": "accessory-spare-part-and-compatibility", "name": "Accessory, spare part, consumable and compatibility links", "description": "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.", "source_refs": [ "SRC-001", "SRC-003", "SRC-011" ], "questions": [ { "id": "q-relation-type-and-direction", "text": "What is the typed relation to the other product type, and in which direction does it hold?", "kind": "relationship", "answer_data": [ "relation type code", "related type identifier", "direction indicator", "asserting party reference" ] }, { "id": "q-compatibility-scope", "text": "Under what conditions or configurations does a compatibility assertion hold, and where does it fail?", "kind": "constraint", "answer_data": [ "applicability conditions", "excluded configurations", "evidence reference", "confidence level" ] }, { "id": "q-spare-part-obligation", "text": "Which spare parts must remain available for this type, for how long after discontinuation, and under which obligation?", "kind": "requirement", "answer_data": [ "spare part type references", "availability period", "governing obligation reference", "jurisdiction code" ] }, { "id": "q-relation-currency", "text": "When was each relationship last reviewed, and what invalidates it?", "kind": "quality", "answer_data": [ "last review timestamp", "invalidation triggers", "review owner reference" ] } ], "data_elements": [ { "id": "typed-relation", "name": "typedRelation", "description": "A directed typed link to another product type with relation code, asserting party and validity period.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "compatibility-condition", "name": "compatibilityCondition", "description": "Conditions under which a compatibility assertion holds or is excluded.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "spare-part-availability-period", "name": "sparePartAvailabilityPeriod", "description": "Committed period during which spare parts remain available after discontinuation.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "Typed relations are graph edges between master records; they carry no independent document and are best held as inline referenced links so that a single relation is not duplicated on both endpoints." }, { "id": "predecessor-successor-and-substitution", "name": "Predecessor, successor and substitution", "description": "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.", "source_refs": [ "SRC-003", "SRC-001", "SRC-005" ], "questions": [ { "id": "q-succession-chain", "text": "Which type supersedes this one, which did it supersede, and from what effective date?", "kind": "lifecycle", "answer_data": [ "predecessor type identifier", "successor type identifier", "succession effective date", "succession reason code" ] }, { "id": "q-substitution-direction", "text": "Is a declared substitution bidirectional or one-way, and in which markets or contracts does it apply?", "kind": "relationship", "answer_data": [ "substitute type identifier", "directionality code", "applicable market or contract references", "approval evidence" ] }, { "id": "q-succession-vs-revision", "text": "Was the generation change modelled as a new type identity or as a revision of the existing type, and why?", "kind": "decision", "answer_data": [ "resolution code", "governing rule reference", "decision rationale", "decision timestamp" ] }, { "id": "q-succession-communication", "text": "How and when were affected trading partners notified of the succession or substitution?", "kind": "process", "answer_data": [ "notification artifact reference", "notification timestamp", "recipient scope", "acknowledgement status" ] } ], "data_elements": [ { "id": "successor-type", "name": "successorTypeRef", "description": "Reference to the type that supersedes this one.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "predecessor-type", "name": "predecessorTypeRef", "description": "Reference to the type this one supersedes.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "substitute-type", "name": "substituteTypeRef", "description": "Reference to an approved substitute with directionality and scope.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "succession-effective-date", "name": "successionEffectiveDate", "description": "Date from which succession takes effect for ordering and support.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-003" ] } ], "artifacts": [ { "id": "product-change-notification", "name": "Product change / discontinuation notification", "description": "Issued notice to trading partners announcing a succession, substitution, specification change or discontinuation, with effective dates and affected identifiers.", "media_or_form": [ "notice document", "structured message" ], "serial": true, "identity_strategy": "Zero-padded monotonic notice number within the issuing party's namespace, combined with an RFC 3339 issue timestamp and the affected type identifiers.", "source_refs": [ "SRC-003", "SRC-005" ] } ], "inline_only_rationale": null }, { "id": "type-instance-classification-and-composition-edges", "name": "Type-instance classification and sibling product edges", "description": "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.", "source_refs": [ "SRC-001", "SRC-003", "SRC-018", "SRC-019" ], "questions": [ { "id": "type-instance-classification-and-composition-edges-q01", "text": "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?", "kind": "relationship", "answer_data": [ "instance-id-list", "edge-type", "granularity-check" ] }, { "id": "type-instance-classification-and-composition-edges-q02", "text": "Which engineering BOMs list this catalog item as a component or assembly type, and at what quantity at the type level?", "kind": "composition", "answer_data": [ "bom-id", "component-quantity", "effectivity-out-of-scope-flag" ] }, { "id": "type-instance-classification-and-composition-edges-q03", "text": "Which other catalog items are declared accessories, spares, consumables, related or similar, and in which direction?", "kind": "relationship", "answer_data": [ "accessory-for", "spare-for", "consumable-for", "similar-to", "related-to" ] }, { "id": "type-instance-classification-and-composition-edges-q04", "text": "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?", "kind": "interoperability", "answer_data": [ "aligned-vocabulary-list", "conflict-list", "conformance-claimed-flag" ] } ], "data_elements": [ { "id": "type-instance-classification-and-composition-edges-data01", "name": "Classifies instances", "description": "Typed edges from this product type to WM-OBJ-001 item instances.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-019", "SRC-026" ] }, { "id": "type-instance-classification-and-composition-edges-data02", "name": "Related product edges", "description": "Accessory, spare, consumable, similar and related type-to-type references.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "type-instance-classification-and-composition-edges-data03", "name": "External alignment set", "description": "Declared alignments to GS1, schema.org, ISO/IEC and regulatory type identifiers with conflict notes.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-022" ] } ], "artifacts": [], "inline_only_rationale": "Typed edges and alignment declarations are reference data on the catalog item; neighbour models hold their own artefacts (instance records, BOM files, offer documents)." } ] } ] }, { "id": "lifecycle-change-and-applicability", "name": "Lifecycle, Change Control and Applicability", "description": "The states a product type passes through, how its specification is changed under control, and where and when it is applicable.", "rationale": "A catalog item is a long-lived governed record whose meaning depends on when and where it is asserted. GS1 change effective dating, ESPR post-market passport availability and market-scoped regulatory obligations all require explicit lifecycle, versioning and applicability semantics rather than a single mutable record.", "source_refs": [ "SRC-005", "SRC-006", "SRC-008", "SRC-009", "SRC-003" ], "layers": [ { "id": "lifecycle-and-change-control", "name": "Lifecycle and Change Control", "description": "State model of the type, controlled revision of its specification, and the obligations that survive discontinuation.", "source_refs": [ "SRC-005", "SRC-006", "SRC-008", "SRC-003" ], "findings": [ { "id": "type-lifecycle-state-model", "name": "Type lifecycle state model", "description": "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.", "source_refs": [ "SRC-005", "SRC-006", "SRC-003" ], "questions": [ { "id": "q-lifecycle-states", "text": "Which lifecycle states are defined for a product type in this Dimension, and which transitions are permitted?", "kind": "state", "answer_data": [ "state code list", "permitted transition pairs", "transition guard conditions", "state definition text" ] }, { "id": "q-state-authority", "text": "Which role may authorise each state transition, and what evidence must accompany it?", "kind": "authority", "answer_data": [ "authorising role", "required evidence references", "approval timestamp", "approval identity" ] }, { "id": "q-state-vs-availability", "text": "How is the record's lifecycle state kept distinct from commercial availability and stock position?", "kind": "constraint", "answer_data": [ "state semantics statement", "separation rule", "downstream consumer guidance" ] }, { "id": "q-state-effective-time", "text": "Does each state have an effective time distinct from the time it was recorded, and are both retained?", "kind": "temporal", "answer_data": [ "state effective timestamp (RFC 3339)", "state recorded timestamp (RFC 3339)", "recording party reference" ] } ], "data_elements": [ { "id": "lifecycle-state", "name": "lifecycleState", "description": "Current governed state of the product type record.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-003" ] }, { "id": "state-effective-at", "name": "stateEffectiveAt", "description": "Instant from which the current state takes effect.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "state-recorded-at", "name": "stateRecordedAt", "description": "Instant the state was recorded in the system, retained separately from the effective instant.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "state-authorised-by", "name": "stateAuthorisedBy", "description": "Reference to the party or role that authorised the transition.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [], "inline_only_rationale": "Lifecycle state is an inline attribute plus an event history; the durable evidence of transitions is the change decision log and change notification artifacts already defined, so no new artifact is warranted." }, { "id": "specification-change-control-and-versioning", "name": "Specification change control and record versioning", "description": "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.", "source_refs": [ "SRC-005", "SRC-010", "SRC-011", "SRC-009" ], "questions": [ { "id": "q-version-axes", "text": "What is the current product specification version and the current record version, and how are they incremented independently?", "kind": "provenance", "answer_data": [ "specification version identifier", "record version identifier", "increment rules", "last change timestamp" ] }, { "id": "q-change-significance", "text": "How is a change classified as material (affecting product behaviour or compliance) versus editorial (correcting the record)?", "kind": "classification", "answer_data": [ "change classification code", "affected attribute references", "impact assessment reference", "classifier identity" ] }, { "id": "q-change-approval-path", "text": "Which approval path applies to each change class, and which changes may be applied without approval?", "kind": "process", "answer_data": [ "change class", "required approver roles", "auto-apply conditions", "approval evidence reference" ] }, { "id": "q-prior-state-reconstruction", "text": "Can the record as it stood at any past instant be reconstructed, and to what granularity?", "kind": "temporal", "answer_data": [ "history retention model", "reconstruction granularity", "earliest reconstructable timestamp", "patch or snapshot references" ] } ], "data_elements": [ { "id": "specification-version", "name": "specificationVersion", "description": "Version identifier of the described product specification, distinct from the record version.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-005" ] }, { "id": "record-version", "name": "recordVersion", "description": "Immutable version identifier of the record revision.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-010" ] }, { "id": "change-classification", "name": "changeClassification", "description": "Coded materiality of a change (material, regulatory, editorial).", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "changed-at", "name": "changedAt", "description": "Instant of the change, with observation/ingestion time recorded separately where the change originated externally.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "change-set-record", "name": "Change set record", "description": "Immutable description of one applied change: affected attributes, prior and new values, classification, approver, effective and recorded timestamps.", "media_or_form": [ "patch record", "append-only log entry" ], "serial": true, "identity_strategy": "Zero-padded monotonic sequence within the type identity; each entry references the resulting record version identifier and carries RFC 3339 effective and recorded timestamps.", "source_refs": [ "SRC-005", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "discontinuation-and-post-market-obligations", "name": "Discontinuation and post-market obligations", "description": "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.", "source_refs": [ "SRC-006", "SRC-008", "SRC-005" ], "questions": [ { "id": "q-discontinuation-dates", "text": "What are the last-order, last-shipment and end-of-support dates, and how do they differ across markets?", "kind": "temporal", "answer_data": [ "last order date", "last shipment date", "end of support date", "market scope per date" ] }, { "id": "q-post-market-data-retention", "text": "How long must the type record, its passport and its compliance evidence remain accessible after discontinuation, and under which obligation?", "kind": "retention", "answer_data": [ "retention period or end date", "governing obligation reference", "responsible custodian reference", "accessibility guarantee" ] }, { "id": "q-recall-reachability", "text": "If a safety issue emerges after discontinuation, how are affected instances reached from the type record?", "kind": "process", "answer_data": [ "instance linkage mechanism", "batch linkage mechanism", "notification channel references", "responsible role" ] }, { "id": "q-record-deletion", "text": "Under what conditions may the record be deleted rather than archived, and what tombstone remains?", "kind": "retention", "answer_data": [ "deletion permitted flag", "legal basis", "tombstone content specification", "deletion approval evidence" ] } ], "data_elements": [ { "id": "discontinuation-date", "name": "discontinuationDate", "description": "Date from which the type is no longer placed on the market, scoped by target market.", "value_kind": "date", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-008" ] }, { "id": "data-retention-until", "name": "dataRetentionUntil", "description": "Date until which the record and its evidence must remain accessible.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "support-obligation", "name": "supportObligation", "description": "Declared post-market obligation with type, duration and jurisdiction.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "Discontinuation produces dates and obligation statements on the master record plus a change notification already defined elsewhere; introducing a separate discontinuation artifact would duplicate that notice." } ] }, { "id": "market-and-temporal-applicability", "name": "Market and Temporal Applicability", "description": "Where and when the type's assertions hold, including jurisdictional scoping and validity dating.", "source_refs": [ "SRC-008", "SRC-009", "SRC-013", "SRC-007" ], "findings": [ { "id": "target-market-and-jurisdiction", "name": "Target market and jurisdictional applicability", "description": "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.", "source_refs": [ "SRC-008", "SRC-009", "SRC-013" ], "questions": [ { "id": "q-target-markets", "text": "For which target markets is this type declared, using which country or region code system?", "kind": "spatial", "answer_data": [ "target market codes (ISO 3166 or region code)", "code system identifier", "declaration date", "declaring party" ] }, { "id": "q-market-scoped-attributes", "text": "Which attributes take different values per target market, and how is the market-scoped value represented?", "kind": "constraint", "answer_data": [ "attribute references", "market code per value", "default value indicator", "conflict resolution rule" ] }, { "id": "q-production-vs-market", "text": "Where is the type produced, and is that independent of the markets in which it is placed?", "kind": "provenance", "answer_data": [ "country of production code", "production facility reference", "market independence statement" ] }, { "id": "q-market-entry-authorisation", "text": "What authorisation, registration or notification is required before the type may be placed on each market?", "kind": "authority", "answer_data": [ "required authorisation type", "issuing authority reference", "authorisation identifier", "validity period" ] } ], "data_elements": [ { "id": "target-market", "name": "targetMarket", "description": "Coded market in which the type is declared to be placed, with code system.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-009" ] }, { "id": "country-of-production", "name": "countryOfProduction", "description": "ISO 3166 country in which the type is manufactured.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "produced-at-facility", "name": "producedAtFacility", "description": "Reference to the facility record where the type is produced.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "market-authorisation", "name": "marketAuthorisation", "description": "Authorisation or registration required for market placement, with issuer and validity.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "Market scoping is a qualifier applied to other assertions rather than a document; the underlying authorisations are conformity evidence artifacts governed by the compliance bundle." }, { "id": "temporal-validity-and-effective-dating", "name": "Temporal validity and effective dating", "description": "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.", "source_refs": [ "SRC-013", "SRC-005", "SRC-008", "SRC-009" ], "questions": [ { "id": "q-validity-period", "text": "What is the validity period of each time-scoped assertion, expressed with explicit offsets?", "kind": "temporal", "answer_data": [ "valid from timestamp (RFC 3339)", "valid to timestamp (RFC 3339)", "open-ended indicator", "time zone or offset rationale" ] }, { "id": "q-event-vs-observation-time", "text": "Are event time and observation or ingestion time recorded separately for externally sourced assertions?", "kind": "provenance", "answer_data": [ "event timestamp", "observation/ingestion timestamp", "source system identifier", "clock authority statement" ] }, { "id": "q-future-dated-changes", "text": "How are future-dated changes staged so that consumers see the correct value at the correct time?", "kind": "process", "answer_data": [ "pending change references", "activation timestamp", "publication policy", "rollback procedure" ] }, { "id": "q-temporal-conflict", "text": "What resolves overlapping or contradictory validity periods for the same attribute?", "kind": "exception", "answer_data": [ "conflict detection rule", "precedence rule", "escalation role", "resolution log reference" ] } ], "data_elements": [ { "id": "valid-from", "name": "validFrom", "description": "Instant from which an assertion is valid, RFC 3339 with explicit offset or Z.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-005" ] }, { "id": "valid-to", "name": "validTo", "description": "Instant after which an assertion ceases to be valid.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "observed-at", "name": "observedAt", "description": "Instant at which an externally sourced assertion was observed or ingested.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "pending-change-ref", "name": "pendingChangeReference", "description": "Reference to a staged future-dated change awaiting activation.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "Temporal scoping is metadata attached to other assertions and to the change set records already defined; a separate artifact would fragment the audit trail." } ] } ] }, { "id": "compliance-conformity-and-evidence", "name": "Compliance, Conformity and Evidence", "description": "Type-level regulatory obligations, the parties responsible for them, and the evidence that substantiates declared claims.", "rationale": "Under ESPR the economic operator placing a product on the market must register its passport and keep it accessible, and UNTP structures supplier assertions as performanceClaims backed by conformity evidence. These are properties of the type, not of individual units, and require explicit party roles and evidence linkage.", "source_refs": [ "SRC-008", "SRC-009", "SRC-011", "SRC-015" ], "layers": [ { "id": "regulatory-obligations", "name": "Type-Level Regulatory Obligations", "description": "Who is responsible for the type in each market and what registered, machine-readable data must accompany it.", "source_refs": [ "SRC-008", "SRC-009", "SRC-015" ], "findings": [ { "id": "responsible-operator-and-market-placement", "name": "Responsible economic operator and market placement", "description": "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.", "source_refs": [ "SRC-008", "SRC-009", "SRC-011" ], "questions": [ { "id": "q-operator-roles", "text": "Which parties hold which regulatory roles for this type, in which markets, and with what registered identifiers?", "kind": "ownership", "answer_data": [ "party reference", "role code", "market scope", "registered operator identifier" ] }, { "id": "q-registration-status", "text": "Is the type registered in each required authority registry, and what registry identifier was returned?", "kind": "authority", "answer_data": [ "registry identifier", "registration identifier or URI", "registration timestamp", "registration status code" ] }, { "id": "q-role-transfer", "text": "How is a change of responsible operator recorded, and what happens to prior registrations and identifiers?", "kind": "lifecycle", "answer_data": [ "transfer effective date", "previous and new party references", "registration migration outcome", "identifier continuity statement" ] }, { "id": "q-obligation-inventory", "text": "Which regulatory obligations apply to this type per market, and what is the compliance status of each?", "kind": "requirement", "answer_data": [ "obligation reference", "jurisdiction", "compliance status code", "evidence reference" ] } ], "data_elements": [ { "id": "related-party", "name": "relatedParty", "description": "Party reference with a coded regulatory or commercial role and market scope.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-008" ] }, { "id": "registry-registration", "name": "registryRegistration", "description": "Registration of the type in an authority registry, with returned identifier and status.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "obligation-status", "name": "obligationStatus", "description": "Compliance status of a named obligation for a given market.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "Operator roles and registration identifiers are inline references and coded values; the underlying registrations are held by external authority registries and must be referenced rather than copied." }, { "id": "digital-product-passport-model-level", "name": "Model-level digital product passport data", "description": "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.", "source_refs": [ "SRC-008", "SRC-009" ], "questions": [ { "id": "q-dpp-applicability", "text": "Does a passport obligation apply to this type, under which instrument and delegated act, and from what date?", "kind": "requirement", "answer_data": [ "instrument reference", "delegated act or product group reference", "applicability date", "applicability determination evidence" ] }, { "id": "q-dpp-granularity", "text": "At which granularity is the passport issued for this type — model, batch or item — and why?", "kind": "decision", "answer_data": [ "granularity code (model | batch | item)", "rationale", "linkage to lower-granularity passports" ] }, { "id": "q-dpp-registry-uri", "text": "What unique URI identifies the passport, who issued it, and where does it resolve?", "kind": "identity", "answer_data": [ "passport URI", "issuing registry identifier", "resolution endpoint", "registration timestamp" ] }, { "id": "q-dpp-access-roles", "text": "Which data elements of the passport are public and which are restricted to specific user roles?", "kind": "access", "answer_data": [ "data element references", "access role per element", "legal basis for restriction", "enforcement mechanism" ] } ], "data_elements": [ { "id": "passport-uri", "name": "passportUri", "description": "Unique resolvable URI of the model-level passport.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008", "SRC-009" ] }, { "id": "id-granularity", "name": "idGranularity", "description": "Granularity at which the passport is issued: model, batch or item.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "passport-data-element", "name": "passportDataElement", "description": "An individual passport data element with its value, access role and legal basis.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "delegated-act-ref", "name": "delegatedActReference", "description": "Reference to the product-group instrument that defines the required passport content.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "model-level-passport", "name": "Model-level digital product passport", "description": "The machine-readable passport instance issued at model granularity, resolvable from its registered URI and linked from the product data carrier.", "media_or_form": [ "verifiable credential", "structured JSON-LD document", "registry entry" ], "serial": false, "identity_strategy": "Identified by the registry-issued unique URI; each reissue carries an immutable version identifier and an RFC 3339 issuance timestamp, with prior versions retained.", "source_refs": [ "SRC-008", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "regulated-type-identifiers-and-marks", "name": "UDI-DI, Basic UDI-DI and type-level certifications", "description": "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.", "source_refs": [ "SRC-017", "SRC-001", "SRC-020", "SRC-021" ], "questions": [ { "id": "regulated-type-identifiers-and-marks-q01", "text": "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?", "kind": "identity", "answer_data": [ "udi-di", "issuing-agency", "basic-udi-di", "gmn", "gudid-published", "production-identifiers-excluded" ] }, { "id": "regulated-type-identifiers-and-marks-q02", "text": "Which certifications, marks or energy classes apply at type level, who issued them, and did add/remove of a mark require a new GTIN?", "kind": "evidence", "answer_data": [ "certification-list", "issuer", "certification-id", "gtin-change-for-mark" ] }, { "id": "regulated-type-identifiers-and-marks-q03", "text": "What GUDID or equivalent registry fields (brand name, version/model, GMDN, package count, premarket number) are bound to this type?", "kind": "requirement", "answer_data": [ "gmdn-code", "version-or-model-number", "premarket-number", "package-count", "proprietary-name" ] }, { "id": "regulated-type-identifiers-and-marks-q04", "text": "Does an FDA UDI exception, alternative or other regional exemption apply so that this type has no UDI-DI?", "kind": "exception", "answer_data": [ "exception-citation", "alternative-granted", "region", "effective-time" ] } ], "data_elements": [ { "id": "regulated-type-identifiers-and-marks-data01", "name": "UDI Device Identifier", "description": "Fixed portion of UDI identifying labeler and version/model; GUDID key. Not a production identifier.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020" ] }, { "id": "regulated-type-identifiers-and-marks-data02", "name": "Basic UDI-DI", "description": "Medical-device family identifier, represented in GS1 as GMN; independent of packaging.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-021" ] }, { "id": "regulated-type-identifiers-and-marks-data03", "name": "Type-level certifications", "description": "Certification objects (issuer, name, identification or rating) that apply to all instances of the type.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "regulated-type-identifiers-and-marks-artifact01", "name": "GUDID / UDI database device record", "description": "Published device-identifier master data for a version/model; excludes production identifiers.", "media_or_form": [ "GUDID-record", "AccessGUDID-export", "EUDAMED-registration" ], "serial": false, "identity_strategy": "UDI-DI as master-system identifier; Basic UDI-DI/GMN as family IRI.", "source_refs": [ "SRC-020", "SRC-021" ] } ], "inline_only_rationale": null } ] }, { "id": "conformity-and-documentation", "name": "Conformity Evidence and Documentation", "description": "Declared claims, third-party attestations, markings and the technical and media documentation that supports them.", "source_refs": [ "SRC-009", "SRC-011", "SRC-003", "SRC-001" ], "findings": [ { "id": "conformity-evidence-and-technical-documentation", "name": "Conformity claims, markings and technical documentation", "description": "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.", "source_refs": [ "SRC-009", "SRC-011", "SRC-003", "SRC-001" ], "questions": [ { "id": "q-claim-vs-attestation", "text": "For each claim, is it a supplier self-declaration or an independently attested conformity result, and who is the assessment body?", "kind": "evidence", "answer_data": [ "claim identifier", "claim basis code (self-declared | attested)", "assessment body reference and accreditation", "evidence document reference" ] }, { "id": "q-claim-standard-and-metric", "text": "Against which standard, metric and threshold is each claim made, and at which version of that standard?", "kind": "measurement", "answer_data": [ "standard reference and version", "metric identifier", "threshold or result value with unit", "assessment date" ] }, { "id": "q-marking-applied", "text": "Which conformity or regulatory markings are applied to the product or its packaging, and on what basis?", "kind": "validation", "answer_data": [ "marking code or image reference", "legal basis reference", "application location (product | packaging | documentation)", "responsible party" ] }, { "id": "q-documentation-set", "text": "Which documents and media constitute the required documentation set for this type, in which locales, and which version of each is current?", "kind": "composition", "answer_data": [ "document type code", "document identifier and version", "locale coverage", "current version indicator" ] }, { "id": "q-evidence-expiry", "text": "When does each attestation expire or require surveillance, and what happens to the claim in the interim?", "kind": "temporal", "answer_data": [ "attestation validity period", "surveillance interval", "lapse handling rule", "responsible role" ] } ], "data_elements": [ { "id": "performance-claim", "name": "performanceClaim", "description": "Supplier assertion referencing a conformity topic, standard, metric, threshold and supporting evidence.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "conformity-attestation-ref", "name": "conformityAttestationReference", "description": "Reference to an independently issued conformity credential or certificate, with issuer and validity.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "product-label-marking", "name": "productLabelMarking", "description": "Applied certification or regulatory marking with legal basis and application location.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "documentation-reference", "name": "documentationReference", "description": "Reference to a document or media asset with type, version and locale coverage.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-001" ] } ], "artifacts": [ { "id": "declaration-of-conformity", "name": "Declaration of conformity / conformity credential", "description": "Issued declaration or third-party credential attesting that the type conforms to named requirements, with issuer, scope, standards and validity period.", "media_or_form": [ "PDF document", "verifiable credential", "structured attestation" ], "serial": true, "identity_strategy": "Issuer-scoped document number with a zero-padded sequence, combined with the type identifier and an RFC 3339 issue timestamp; superseded declarations are retained with closed validity.", "source_refs": [ "SRC-009", "SRC-011" ] }, { "id": "product-media-set", "name": "Product media and label artwork set", "description": "Images, label artwork, marking images and instructional media associated with the type, with locale, market scope and usage rights.", "media_or_form": [ "raster image", "vector artwork", "video", "structured media manifest" ], "serial": false, "identity_strategy": "Keyed by (type identifier, media role, locale, market scope) with a content digest for integrity and an RFC 3339 capture or release timestamp.", "source_refs": [ "SRC-009", "SRC-001", "SRC-011" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "stewardship-provenance-and-quality", "name": "Stewardship, Provenance and Data Quality", "description": "Who is authoritative for the record, how each assertion's origin is tracked, how the record is validated, and who may see what.", "rationale": "A catalog item record is assembled from many contributors with unequal authority. GS1 data-sharing practice distinguishes the information provider from the brand owner, and passport regimes grant differentiated access by user role, so authority, provenance, quality and access must be first-class rather than implicit.", "source_refs": [ "SRC-006", "SRC-007", "SRC-008", "SRC-009", "SRC-012" ], "layers": [ { "id": "authority-and-access", "name": "Authority and Access", "description": "Authoritative sourcing of the record and controlled disclosure of its contents.", "source_refs": [ "SRC-006", "SRC-007", "SRC-008", "SRC-012" ], "findings": [ { "id": "authoritative-source-and-stewardship", "name": "Authoritative source and stewardship", "description": "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.", "source_refs": [ "SRC-006", "SRC-007", "SRC-012" ], "questions": [ { "id": "q-authoritative-party", "text": "Which party is authoritative for each attribute group of this record, and on what basis is that authority established?", "kind": "authority", "answer_data": [ "attribute group reference", "authoritative party reference", "basis of authority (prefix licence, brand ownership, regulatory role)", "effective period" ] }, { "id": "q-information-provider", "text": "Which party publishes the record on the authoritative party's behalf, and under what mandate?", "kind": "ownership", "answer_data": [ "information provider identifier", "mandate reference", "publication scope", "mandate validity period" ] }, { "id": "q-enrichment-precedence", "text": "When a non-authoritative contributor supplies a conflicting value, which wins and how is the loser preserved?", "kind": "decision", "answer_data": [ "precedence rule", "winning value reference", "preserved alternative value", "resolution timestamp" ] }, { "id": "q-steward-accountability", "text": "Which named steward is accountable for the record's completeness and currency, and on what review cycle?", "kind": "ownership", "answer_data": [ "steward role and party reference", "review cycle", "last review timestamp", "escalation path" ] } ], "data_elements": [ { "id": "authoritative-party", "name": "authoritativePartyRef", "description": "Party authoritative for a named attribute group, with the basis of that authority.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-012" ] }, { "id": "information-provider", "name": "informationProviderRef", "description": "Party publishing the record on behalf of the authoritative party.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "data-steward", "name": "dataStewardRef", "description": "Accountable steward for record quality and currency.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [], "inline_only_rationale": "Authority assignments are inline references and precedence rules held with the record; the mandates themselves are contracts owned by a party or agreement model and are referenced only." }, { "id": "access-confidentiality-and-release-control", "name": "Access, confidentiality and release control", "description": "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.", "source_refs": [ "SRC-008", "SRC-009", "SRC-007" ], "questions": [ { "id": "q-access-classes", "text": "Which access classes apply to which attribute groups, and who may read each class?", "kind": "access", "answer_data": [ "access class code", "attribute group reference", "permitted role list", "legal or contractual basis" ] }, { "id": "q-embargo", "text": "Is the type under pre-release embargo, until when, and which attributes are embargoed?", "kind": "security", "answer_data": [ "embargo flag", "embargo lift timestamp (RFC 3339)", "embargoed attribute references", "approver reference" ] }, { "id": "q-third-party-redistribution", "text": "May a recipient redistribute the record or its media, to whom, and under what licence?", "kind": "privacy", "answer_data": [ "redistribution permission code", "licence reference", "recipient scope", "attribution requirement" ] }, { "id": "q-access-audit", "text": "What access events must be logged, retained for how long, and made available to whom?", "kind": "validation", "answer_data": [ "logged event types", "retention period", "log accessibility scope", "log integrity mechanism" ] } ], "data_elements": [ { "id": "access-class", "name": "accessClass", "description": "Coded disclosure class assigned to an attribute group.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "embargo-until", "name": "embargoUntil", "description": "Instant until which embargoed attributes must not be disclosed.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "usage-licence-ref", "name": "usageLicenceReference", "description": "Licence governing reuse and redistribution of record content and media.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "Access classes and embargo dates are inline governance metadata; the audit trail they imply is a service-layer log rather than a product-type artifact." } ] }, { "id": "provenance-and-validation", "name": "Provenance and Validation", "description": "Per-assertion origin tracking and the rules that determine whether the record is fit for use.", "source_refs": [ "SRC-009", "SRC-010", "SRC-007", "SRC-012" ], "findings": [ { "id": "attribute-provenance-and-time", "name": "Attribute-level provenance and dual timestamps", "description": "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.", "source_refs": [ "SRC-009", "SRC-012", "SRC-010" ], "questions": [ { "id": "q-assertion-origin", "text": "For each asserted value, which party and source system supplied it and by what acquisition method?", "kind": "provenance", "answer_data": [ "asserting party reference", "source system identifier", "acquisition method code (declared | measured | derived | inferred | extracted)", "source document reference" ] }, { "id": "q-dual-timestamps", "text": "Are event time and ingestion time both retained for each assertion, with explicit offsets?", "kind": "temporal", "answer_data": [ "event timestamp (RFC 3339)", "ingestion timestamp (RFC 3339)", "offset handling policy" ] }, { "id": "q-derived-values", "text": "Which values are derived or inferred rather than asserted, and what is the derivation rule and its inputs?", "kind": "provenance", "answer_data": [ "derived attribute reference", "derivation rule identifier and version", "input attribute references", "recomputation trigger" ] }, { "id": "q-source-trust", "text": "What trust level is assigned to each source, and how does it affect precedence and publication?", "kind": "quality", "answer_data": [ "source trust level", "assignment rationale", "effect on precedence", "review date" ] } ], "data_elements": [ { "id": "assertion-provenance", "name": "assertionProvenance", "description": "Per-assertion provenance record with party, source system, method and dual timestamps.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-012" ] }, { "id": "acquisition-method", "name": "acquisitionMethod", "description": "Coded method by which a value was obtained.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "derivation-rule-ref", "name": "derivationRuleReference", "description": "Reference to the rule and version used to derive a computed value.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "Provenance is metadata bound to individual assertions inside the master record; extracting it into a standalone artifact would break the one-to-one binding that gives it meaning." }, { "id": "validation-quality-and-conflict-resolution", "name": "Validation, quality measurement and conflict resolution", "description": "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.", "source_refs": [ "SRC-007", "SRC-010", "SRC-009", "SRC-012" ], "questions": [ { "id": "q-validation-rule-set", "text": "Which validation rule sets apply to this record, at which version, and which are blocking versus advisory?", "kind": "validation", "answer_data": [ "rule set identifier and version", "rule severity code", "blocking flag", "last execution timestamp" ] }, { "id": "q-completeness-measure", "text": "How is completeness measured against the mandatory attribute set implied by classification and market, and what is the current score?", "kind": "quality", "answer_data": [ "mandatory attribute set reference", "completeness score", "missing attribute references", "measurement timestamp" ] }, { "id": "q-conflict-procedure", "text": "When two sources assert different values for the same attribute, what procedure resolves it and who decides?", "kind": "exception", "answer_data": [ "conflict record reference", "resolution procedure identifier", "deciding role", "resolution outcome and timestamp" ] }, { "id": "q-publication-gate", "text": "Which validation outcomes block publication to each downstream channel?", "kind": "process", "answer_data": [ "channel reference", "blocking rule references", "override permission and approver", "override evidence" ] } ], "data_elements": [ { "id": "validation-result", "name": "validationResult", "description": "Outcome of executing a named rule set against the record, with severity and timestamp.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-010" ] }, { "id": "completeness-score", "name": "completenessScore", "description": "Measured completeness against the applicable mandatory attribute set.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "conflict-record", "name": "conflictRecord", "description": "Recorded disagreement between sources with competing values and the resolution decision.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-009" ] } ], "artifacts": [ { "id": "validation-report", "name": "Validation and quality report", "description": "Dated report of rule executions, failures, severity, completeness scores and unresolved conflicts for one type record.", "media_or_form": [ "structured report", "tabular export" ], "serial": true, "identity_strategy": "Zero-padded monotonic run number within the type identity and rule-set version, stamped with an RFC 3339 execution timestamp and the executing service identifier.", "source_refs": [ "SRC-007", "SRC-010", "SRC-012" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "interoperability-and-projection", "name": "Interoperability and Projection", "description": "How the type record is carried, resolved and exchanged across systems and standards without changing its semantics.", "rationale": "GS1 Digital Link defines a normative way to express type identity in web URIs; GDSN, AAS submodels, schema.org and passport formats are alternative projections of the same type-level facts. Keeping projection separate from semantics is required by the format-neutrality rule.", "source_refs": [ "SRC-004", "SRC-009", "SRC-011", "SRC-001", "SRC-008" ], "layers": [ { "id": "carriers-resolution-and-exchange", "name": "Carriers, Resolution and Exchange", "description": "Physical and digital carriers of type identity, their resolution behaviour, and the profiles used to exchange the record.", "source_refs": [ "SRC-004", "SRC-008", "SRC-009", "SRC-011", "SRC-001" ], "findings": [ { "id": "data-carrier-and-web-resolution", "name": "Data carrier encoding and web resolution", "description": "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.", "source_refs": [ "SRC-004", "SRC-008" ], "questions": [ { "id": "q-carrier-types", "text": "Which data carriers encode this type's identity, on which packaging levels, and with which encoded content?", "kind": "interoperability", "answer_data": [ "carrier type code", "packaging level", "encoded content string", "encoding standard and version" ] }, { "id": "q-uri-construction", "text": "How is the web URI for this type constructed, including qualifier ordering and identifier normalisation?", "kind": "interoperability", "answer_data": [ "URI template", "normalisation rule", "qualifier order", "domain and path ownership" ] }, { "id": "q-resolution-behaviour", "text": "What does the URI resolve to for each requesting role and link type, and who operates the resolver?", "kind": "access", "answer_data": [ "link type identifiers", "target resource per link type and role", "resolver operator reference", "availability commitment" ] }, { "id": "q-carrier-change", "text": "When the carrier or its encoded content changes, how are in-market goods with the previous carrier handled?", "kind": "lifecycle", "answer_data": [ "carrier change effective date", "coexistence period", "backward compatibility statement", "affected packaging levels" ] } ], "data_elements": [ { "id": "data-carrier", "name": "dataCarrier", "description": "Carrier of the type identity with carrier type, packaging level and encoded content.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-008" ] }, { "id": "digital-link-uri", "name": "digitalLinkUri", "description": "Web URI expressing the type identity with normalised identifier and qualifiers.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "link-type", "name": "linkType", "description": "Declared link type mapping a resolution request to a target resource.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "carrier-specification", "name": "Data carrier specification", "description": "Specification of the carriers applied to each packaging level, with symbology, encoded content, placement and quality requirements.", "media_or_form": [ "specification document", "structured record" ], "serial": false, "identity_strategy": "Keyed by (type identifier, packaging level, carrier type) with a specification version identifier and an RFC 3339 approval timestamp.", "source_refs": [ "SRC-004", "SRC-008" ] } ], "inline_only_rationale": null }, { "id": "exchange-profiles-and-crosswalks", "name": "Exchange profiles and crosswalk mappings", "description": "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.", "source_refs": [ "SRC-009", "SRC-011", "SRC-001", "SRC-012", "SRC-007" ], "questions": [ { "id": "q-projection-targets", "text": "Which external profiles is this record projected into, at which profile version, and for which consumers?", "kind": "interoperability", "answer_data": [ "profile identifier and version", "consumer scope", "projection direction (export | import | bidirectional)", "last projection timestamp" ] }, { "id": "q-mapping-gaps", "text": "Which elements cannot be mapped in each direction, and how is the loss recorded rather than silently dropped?", "kind": "quality", "answer_data": [ "unmappable element references", "loss direction", "mitigation or annotation mechanism", "reviewer reference" ] }, { "id": "q-conformance-evidence", "text": "What evidence supports any claim of conformance to an external profile, and who validated it?", "kind": "evidence", "answer_data": [ "conformance test suite reference", "test result reference", "validating party", "validation timestamp" ] }, { "id": "q-round-trip-integrity", "text": "Does a round trip through a projection preserve identity, semantics and provenance, and what is verified?", "kind": "validation", "answer_data": [ "round-trip test definition", "preserved element set", "divergence findings", "verification timestamp" ] } ], "data_elements": [ { "id": "projection-profile", "name": "projectionProfile", "description": "External profile the record is projected into, with version and direction.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-011", "SRC-001" ] }, { "id": "mapping-entry", "name": "mappingEntry", "description": "Element-level mapping between an internal data element and an external profile term, with fidelity notes.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-010" ] }, { "id": "conformance-claim", "name": "conformanceClaim", "description": "Recorded claim of conformance to an external profile together with supporting test evidence.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "crosswalk-mapping-set", "name": "Crosswalk mapping set", "description": "Versioned element-level mappings between this model's data elements and each external profile, annotated with unmappable elements and known conflicts.", "media_or_form": [ "mapping table", "structured mapping document" ], "serial": false, "identity_strategy": "Keyed by (source model identifier and version, target profile identifier and version); each mapping set carries an immutable version identifier and an RFC 3339 publication timestamp.", "source_refs": [ "SRC-009", "SRC-011", "SRC-001", "SRC-012" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "register-product-type", "name": "Register product type", "description": "Create a governed product type record with exactly one authoritative identity anchor, a declared granularity and an initial lifecycle state.", "inputs": [ "proposed identifier scheme and value or a request to assign an internal identifier", "authoritative party reference", "initial classification assignment", "target market scope" ], "outputs": [ "persisted product type master record", "assigned authoritative identifier", "record version identifier", "creation and identifier-assignment timestamps" ], "preconditions": [ "the requesting party holds or can evidence authority to allocate under the chosen scheme", "no existing record already claims the same authoritative identifier", "the type does not duplicate an existing record under a different key" ], "effects": [ "a new type identity becomes permanently allocated and enters the non-reuse regime", "downstream consumers can resolve the identifier to a record", "an entry is written to the identifier change decision log" ], "source_refs": [ "SRC-004", "SRC-006", "SRC-009" ] }, { "id": "evaluate-identity-change-rule", "name": "Evaluate identity change rule", "description": "Decide whether a proposed modification requires allocation of a new type identifier or may be applied as a revision of the existing record.", "inputs": [ "proposed attribute changes", "current record version", "applicable rule set identifier and version", "target markets affected" ], "outputs": [ "decision outcome (new identifier | revision)", "cited rule references", "recommended change effective date", "decision log entry" ], "preconditions": [ "the applicable rule set and its version are resolvable", "the affected attributes are classified as declared or descriptive" ], "effects": [ "either a successor type registration is triggered or a change set is opened", "trading partners can be notified with an authoritative rationale" ], "source_refs": [ "SRC-005", "SRC-006" ] }, { "id": "classify-product-type", "name": "Classify product type", "description": "Assign or update classification codes in one or more external schemes, recording scheme version, basis and effective dates.", "inputs": [ "scheme identifier and version", "candidate code", "assignment basis", "assigning party" ], "outputs": [ "classification assignment record", "primary classification designation", "review due date for provisional assignments" ], "preconditions": [ "the scheme release is resolvable and not withdrawn", "the code exists in the stated scheme release" ], "effects": [ "mandatory attribute sets implied by the classification become applicable", "validation and completeness scoring are recalculated" ], "source_refs": [ "SRC-007", "SRC-013", "SRC-014", "SRC-009" ] }, { "id": "bind-characteristic-value", "name": "Bind characteristic value", "description": "Attach a declared value to a characteristic bound to a governed property definition, with unit, tolerance, measurement basis and provenance.", "inputs": [ "property semantic identifier and dictionary release", "declared value and unit code", "value semantics and tolerance", "test method reference and provenance" ], "outputs": [ "characteristic assertion with provenance and dual timestamps", "validation result for the value domain" ], "preconditions": [ "the property definition resolves in the stated dictionary release", "the unit code belongs to a declared unit code system" ], "effects": [ "the characteristic becomes machine-comparable across types sharing the binding", "re-validation is triggered when the dictionary release is superseded" ], "source_refs": [ "SRC-010", "SRC-009", "SRC-011" ] }, { "id": "define-variant-set", "name": "Define variant set", "description": "Declare the product group, its variant axes and its members, and record which variations are represented as shared-identity qualifiers.", "inputs": [ "product group identifier", "variant axis property references", "member type identifiers and axis values", "qualifier scheme where identity is shared" ], "outputs": [ "variant matrix", "group membership assertions", "invalid combination declarations" ], "preconditions": [ "each member type already has an authoritative identifier or a declared qualifier", "the group is marked as not directly orderable where the source vocabulary requires it" ], "effects": [ "consumers can navigate from a group to its purchasable members", "identity-change evaluation gains an explicit variant boundary" ], "source_refs": [ "SRC-002", "SRC-003", "SRC-004" ] }, { "id": "assemble-packaging-hierarchy", "name": "Assemble packaging hierarchy", "description": "Declare the containment structure across packaging-level types with quantities, consumer-unit flags and packaging materials.", "inputs": [ "child type identifier and contained quantity", "packaging level code", "homogeneity or assortment declaration", "packaging material declarations" ], "outputs": [ "packaging hierarchy specification", "per-level orderable and consumer-unit flags" ], "preconditions": [ "each packaging level that is priced, ordered or invoiced has its own identifier", "groupings created only for transport are excluded as logistics units" ], "effects": [ "logistics and retail systems can derive per-level quantities from the type record", "packaging regulation reporting becomes computable at type level" ], "source_refs": [ "SRC-006", "SRC-005", "SRC-009" ] }, { "id": "transition-lifecycle-state", "name": "Transition lifecycle state", "description": "Move the type record to a new governed state with separate effective and recorded timestamps and an authorising identity.", "inputs": [ "target state code", "effective timestamp", "authorising party and evidence references", "affected market scope" ], "outputs": [ "updated lifecycle state", "state transition history entry", "triggered notifications" ], "preconditions": [ "the transition is permitted by the declared state model", "required evidence for the target state is present", "post-market obligations are declared before entering discontinued" ], "effects": [ "downstream availability and ordering behaviour changes at the effective time", "retention and support obligation clocks start where applicable" ], "source_refs": [ "SRC-005", "SRC-006", "SRC-008" ] }, { "id": "issue-model-level-passport", "name": "Issue model-level passport", "description": "Assemble and register the passport data set at model granularity and obtain a resolvable unique URI linked from the product data carrier.", "inputs": [ "applicable instrument and delegated act reference", "required passport data elements with access roles", "responsible economic operator reference", "carrier specification" ], "outputs": [ "registered passport URI", "passport instance at model granularity", "registration timestamp and status" ], "preconditions": [ "the passport obligation has been determined applicable for the product group and market", "the responsible economic operator is identified and registered", "required data elements pass blocking validation" ], "effects": [ "the passport becomes resolvable to authorised roles for the product lifecycle", "the carrier must be updated to reference the passport URI" ], "source_refs": [ "SRC-008", "SRC-009", "SRC-004" ] }, { "id": "validate-product-type-record", "name": "Validate product type record", "description": "Execute applicable rule sets against the record and produce a dated validation and quality report with blocking and advisory outcomes.", "inputs": [ "record version under test", "applicable rule set identifiers and versions", "classification-derived mandatory attribute set", "target channel profile" ], "outputs": [ "validation report", "completeness score", "blocking failure list", "unresolved conflict list" ], "preconditions": [ "classification and market scope are assigned so that mandatory sets are derivable", "rule set versions are resolvable" ], "effects": [ "publication to a channel is gated on blocking outcomes", "quality trends become measurable across record versions" ], "source_refs": [ "SRC-007", "SRC-010", "SRC-012" ] }, { "id": "resolve-identifier-to-record", "name": "Resolve identifier to record", "description": "Given an identifier, qualifier set or web URI, return the correct product type record and the resources permitted for the requesting role.", "inputs": [ "identifier or URI with optional qualifiers", "requesting role or credential", "requested link type" ], "outputs": [ "resolved record reference or targeted resource", "granularity of the match (group | type | sub-variant)", "access decision and audit entry" ], "preconditions": [ "identifier normalisation rules are applied before lookup", "the caller's role is established for access-class filtering" ], "effects": [ "an access event is logged", "callers must not assume the URI implies a resolver unless one is declared" ], "source_refs": [ "SRC-004", "SRC-008" ] }, { "id": "project-to-exchange-profile", "name": "Project to exchange profile", "description": "Render the record into an external profile using a versioned crosswalk, recording unmappable elements rather than dropping them silently.", "inputs": [ "target profile identifier and version", "crosswalk mapping set version", "record version and access-class filter" ], "outputs": [ "profile-conformant payload", "loss report of unmappable elements", "projection timestamp and provenance" ], "preconditions": [ "a published crosswalk exists for the target profile version", "access-class filtering has been applied for the destination audience" ], "effects": [ "external consumers receive a shape they can process", "conformance is claimed only where test evidence exists" ], "source_refs": [ "SRC-009", "SRC-011", "SRC-001", "SRC-012" ] }, { "id": "supersede-product-type", "name": "Supersede product type", "description": "Link a successor type, close out the predecessor and issue notification while preserving the retired identifier against reuse.", "inputs": [ "predecessor and successor type identifiers", "succession effective date", "reason code", "affected market scope" ], "outputs": [ "succession links on both records", "product change notification", "updated identifier status" ], "preconditions": [ "the successor is registered and validated", "post-market obligations of the predecessor are declared" ], "effects": [ "the predecessor identifier moves to retired and remains permanently unavailable for reuse", "ordering is redirected from the effective date" ], "source_refs": [ "SRC-003", "SRC-005", "SRC-006" ] }, { "id": "link-type-to-instance-and-bom", "name": "Link type to instances or BOM composition", "description": "Create typed edges CLASSIFIES to item instances or accept COMPOSE from an engineering BOM without copying instance or BOM payloads into this model.", "inputs": [ "catalog-item-id", "target-model-id", "relation-type", "target-identifiers" ], "outputs": [ "typed-edge-set" ], "preconditions": [ "Target exists in the neighbour model.", "Relation is CLASSIFIES, accessory/spare/similar, or BOM composition — not Offer." ], "effects": [ "Updates relationship collection only." ], "source_refs": [ "SRC-001", "SRC-019", "SRC-026" ] }, { "id": "publish-product-type-record", "name": "Publish catalog item master data", "description": "Emit GDSN/GUDID/ProductModel publication of type master data without embedding Offer price or availability.", "inputs": [ "catalog-item-id", "channel", "redaction-policy" ], "outputs": [ "publication-message", "publication-timestamp", "channel-identifier" ], "preconditions": [ "Required identity and description fields present.", "GTIN check digit and prefix validity pass if GTIN present.", "Offer/price fields are absent or stripped." ], "effects": [ "Makes type data available to trading partners or public consumers.", "Records PROV generation of the published entity." ], "source_refs": [ "SRC-001", "SRC-018", "SRC-024", "SRC-025" ] } ], "composition": [ { "target": "WM-OBJ-001 Item Instance", "relation": "REFERENCE", "purpose": "The product type classifies item instances: each instance references exactly one type identity, while serial, condition and custody stay on the instance. Regulators formalise this split as a fixed device identifier plus a variable production identifier, and UNTP as idGranularity model versus item.", "required": true, "source_refs": [ "SRC-004", "SRC-009", "SRC-015" ] }, { "target": "WM-OBJ-019 Engineering Bill of Material", "relation": "REFERENCE", "purpose": "The engineering BOM composes component types into an assembly type; this model holds only the reference to the governing BOM revision and effectivity, not the structure, quantities or alternates.", "required": false, "source_refs": [ "SRC-011", "SRC-009" ] }, { "target": "Batch / Lot model", "relation": "REFERENCE", "purpose": "Batches are subsets of one model produced under shared conditions, addressed by the lot key qualifier and by batch granularity passports; batch-specific measured values must reference the type without being asserted on it.", "required": false, "source_refs": [ "SRC-004", "SRC-009" ] }, { "target": "Offer / Price model", "relation": "REFERENCE", "purpose": "Commercial terms attach to offers, not to the type. schema.org keeps Product and Offer separate and states that a product group is not itself offered for sale, so price, availability and channel conditions are referenced only.", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "target": "Party / Organization model", "relation": "REFERENCE", "purpose": "Brand owner, manufacturer, information provider, responsible economic operator and assessment body are role-scoped party references with registered identifiers, supplied by the party model.", "required": true, "source_refs": [ "SRC-009", "SRC-012", "SRC-008" ] }, { "target": "Facility / Site model", "relation": "REFERENCE", "purpose": "Production facility references support countryOfProduction and producedAtFacility assertions without importing facility master data into the type record.", "required": false, "source_refs": [ "SRC-009" ] }, { "target": "Classification scheme registry (GPC, UNSPSC, ECLASS, HS)", "relation": "ALIGN", "purpose": "Classification codes are assignments into externally governed, independently versioned registries; this model records the assignment and its scheme release, never the taxonomy content.", "required": true, "source_refs": [ "SRC-007", "SRC-013", "SRC-014", "SRC-010" ] }, { "target": "Property dictionary (IEC CDD / IEC 61360 / ISO 13584-42)", "relation": "ALIGN", "purpose": "Characteristics bind to IRDI-identified property definitions so that values carry versioned, resolvable semantics rather than free-text labels.", "required": false, "source_refs": [ "SRC-010", "SRC-011" ] }, { "target": "GS1 trade item identification and Digital Link", "relation": "ALIGN", "purpose": "Alignment to GTIN allocation, non-reuse and URI expression for retail and supply chain interoperability; alignment is asserted at the identifier and carrier level only, and conformance is not claimed without GS1 licence evidence.", "required": false, "source_refs": [ "SRC-004", "SRC-005", "SRC-006" ] }, { "target": "schema.org Product / ProductModel / ProductGroup", "relation": "ALIGN", "purpose": "Projection target for web publication and search; supplies the prototype, variant-group and succession relations but with weaker identity guarantees than governed identifier schemes.", "required": false, "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ] }, { "target": "ESPR Digital Product Passport / UNECE UNTP DPP", "relation": "ALIGN", "purpose": "Alignment for model-granularity passport content, registry URI, role-based access and sustainability claims; applicability depends on product-group delegated acts and must be determined per market.", "required": false, "source_refs": [ "SRC-008", "SRC-009" ] }, { "target": "IDTA Asset Administration Shell submodels (Digital Nameplate, Technical Data, Handover Documentation)", "relation": "ALIGN", "purpose": "Industrial projection separating type-level designations, article and order codes from instance-level serial and construction year, and supplying technical data and documentation structures.", "required": false, "source_refs": [ "SRC-011" ] }, { "target": "OASIS UBL Item / catalogue business objects", "relation": "ALIGN", "purpose": "Transactional projection supplying the multi-party identifier pattern (buyer, seller, manufacturer, standard, catalogue item identification) used by the secondary-key finding.", "required": false, "source_refs": [ "SRC-012" ] }, { "target": "Material and substance model", "relation": "REFERENCE", "purpose": "Material provenance and substances of concern reference externally governed material and substance records; only the type-level breakdown, fractions and hazard status are held here.", "required": false, "source_refs": [ "SRC-009" ] }, { "target": "Document and media asset model", "relation": "REFERENCE", "purpose": "Datasheets, declarations, label artwork and instructional media have their own lifecycle; this model records the reference, role, locale, market scope and current version only.", "required": false, "source_refs": [ "SRC-011", "SRC-001" ] }, { "target": "Conformity assessment / credential model", "relation": "REFERENCE", "purpose": "Independently issued conformity credentials are separate verifiable objects; performance claims on the type reference them rather than embedding assessment content.", "required": false, "source_refs": [ "SRC-009" ] }, { "target": "Unit of measure and quantity model", "relation": "MIX-IN", "purpose": "Quantity-valued characteristics, net content, dimensions and weights reuse a shared quantity pattern with unit code system, tolerance and measurement basis instead of redefining units locally.", "required": false, "source_refs": [ "SRC-010", "SRC-009" ] }, { "target": "Change management and versioning pattern", "relation": "MIX-IN", "purpose": "Record versioning, change classification, dual timestamps and append-only change sets are a cross-cutting pattern reused rather than specialised for product types.", "required": false, "source_refs": [ "SRC-005", "SRC-009" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "The adopting Dimension MUST name a single accountable owner for WM-OBJ-002 who holds authority to approve identifier-scheme selection, change-rule sets and publication gates.", "The Dimension MUST declare which identifier scheme is authoritative per product family and per market, and MUST record evidence of any licence required to allocate under that scheme (for example a GS1 company prefix licence) before any identifier is issued.", "The Dimension MUST publish its lifecycle state model, change-classification rules and precedence rules for conflicting contributors, versioned and dated, before the first record is created.", "The Dimension MUST declare the sibling models it composes with (item instance, batch, offer, party, facility, BOM) and MUST NOT re-implement their concepts locally.", "The Dimension MUST declare retention and deletion policy per access class, including what tombstone survives deletion of a retired identifier." ], "namespace_guidance": "Use one stable namespace IRI per Dimension, with a sub-path per record plane and model, for example {dimension-base}/world-model/wm-obj-002/{scheme}/{identifier}. External identifiers are never minted into the local namespace: they are recorded as scheme-qualified values with their issuer. Internally assigned identifiers use UUID or ULID under the Dimension namespace and are opaque and non-significant. Names, dates, classification codes and file paths MUST NOT appear in identifier positions.", "registry_links": [ "vr.wm-obj-002 is the registry entry of record for this model; changes to scope or entry kind require a registry update.", "WM-OBJ-001 (item instance) is the mandatory downstream target of the CLASSIFIES relation and must be resolvable from any Dimension adopting this model.", "WM-OBJ-019 (engineering bill of material) composes component types and must be resolvable where type-level composition is asserted.", "External registries referenced by assignment (GS1 GTIN/Digital Link, GPC, UNSPSC, IEC CDD, WCO HS, EU DPP Registry) must be recorded with scheme identifier, release version and access endpoint." ] }, "canon_and_patch": { "canonicalization_rules": [ "The canonical form is the format-neutral master record; JSON, YAML, Markdown, HTML, Git, MCP and MongoDB projections are derived and never authoritative.", "Identifiers are canonicalised before comparison: GTINs are normalised to 14 digits with leading-zero filler, IRDIs retain their RAI#DI#VI form including version, and IRIs are compared after standard URI normalisation.", "All timestamps are canonicalised to RFC 3339 with seconds and an explicit offset or Z; local-time values without offsets are rejected at ingest.", "Collections of assertions (classifications, characteristics, relations) are canonically ordered by their semantic identifier and then by valid-from timestamp so that digests are stable.", "Locale-scoped text is canonicalised with BCP 47 tags; an authoritative locale is declared and untagged text is rejected." ], "patch_rules": [ "Every change is expressed as an immutable change set referencing the prior record version and producing a new record version identifier; in-place mutation without a change set is prohibited.", "A change set MUST carry the change classification (material, regulatory, editorial), the affected attribute references, prior and new values, the approving identity and both effective and recorded timestamps.", "A change that the identity change-rule evaluation classifies as requiring a new identifier MUST NOT be applied as a patch; it MUST create a successor record and a succession link.", "Future-dated change sets are staged and activated at their effective instant; consumers reading as-of a past instant MUST see the value that was effective then.", "Deletion of an assertion is expressed as closing its validity period, not as removal, except where a declared retention or legal-erasure rule applies." ], "compatibility_rules": [ "Adding an optional data element or an additional classification assignment is backward compatible; removing an element, narrowing cardinality or changing a value domain is breaking and requires a model version increment.", "Changing the authoritative identifier scheme for existing records is breaking and requires an explicit migration with retained crosswalks.", "External profile projections are versioned independently of the model; a profile version bump must not force a model version bump unless a mapping becomes impossible.", "Conformance to an external standard is asserted only with named test evidence; absent evidence, the relationship is recorded as alignment.", "Consumers MUST tolerate unknown additional elements and MUST NOT infer meaning from element ordering." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier issued by the governing authority for the domain (for example a GTIN under a licensed company prefix, a Basic UDI-DI, or an authority registry identifier).", "Governed global identifier or IRI (for example a GS1 Digital Link URI, a DPP registry URI, or an IRDI from a published dictionary).", "UUID or ULID assigned by the adopting Dimension within its declared namespace, used only when no external authority applies.", "A name, model designation, classification code, file path or date is never an identifier and must not be promoted into an identifier position." ], "timestamp_rule": "All time values use RFC 3339 with seconds and an explicit UTC offset or Z. Event time (when the fact became true) and observation or ingestion time (when the system learned it) are recorded separately whenever an assertion originates outside the owning system; a single 'last updated' value is insufficient.", "serial_naming_rule": "Serial artifacts (identifier decision log, change set records, validation reports, conformity declarations, change notifications) use a zero-padded monotonic sequence scoped to the owning key (type identity, or issuer namespace for externally issued documents), paired with an RFC 3339 issue timestamp and the issuing party identifier. Sequence numbers are never reused, never reordered, and never carry semantics beyond ordering.", "integrity_rule": "Every artifact carries a content digest over its canonical form, the identifier and version of the producing process, and the identity of the issuing or approving party. Binary media additionally record byte length and media type. Digests are verified on ingest and on projection; a digest mismatch blocks publication and raises a validation failure rather than being silently corrected." }, "policies": [ "Identifier non-reuse is absolute within this model: an identifier that has been allocated to a product type is never reassigned to a different type, and retired identifiers remain resolvable to a tombstone record.", "Type-level records must not carry instance-specific or batch-specific facts (serial numbers, actual measured content of one unit, individual expiry dates); such values are rejected at validation and redirected to the sibling instance or batch model.", "Commercial terms (price, availability, seller, delivery) are excluded from the type record; only whether a term is a declared, identity-relevant attribute may be recorded.", "No claim of conformance to an external standard is published without named, retrievable test or certification evidence; otherwise the relationship is recorded as alignment with known gaps.", "Every published assertion carries attribute-level provenance including asserting party, source system, acquisition method and dual timestamps; assertions without provenance may be stored but must not be projected to external consumers.", "Access classes are evaluated before any projection; embargoed and partner-restricted attributes are filtered at projection time, not at presentation time.", "Class versus instance versus offer: a WM-OBJ-002 record MUST NOT store serial numbers, lot/expiry production identifiers, SSCC, or seller price/availability as if they were type master data.", "GTIN and GMN non-reuse: allocated class keys SHALL NOT be recycled except the documented never-produced exception; discontinued types remain queryable tombstones.", "Regulatory floor: local legal GTIN-change, labelling and UDI rules supersede GS1 and schema.org minima.", "Master-data quality: characteristic data exchanged across organisations SHOULD be dictionary-encoded and computer-checkable per ISO 8000-110/ISO 22745 when an identification guide exists." ], "crud": { "read": [ "Read by authoritative identifier, by governed IRI, or by scheme-qualified secondary key with the party scope supplied.", "Read as-of a given instant, returning the record version that was effective then, with both effective and recorded timestamps.", "Read filtered by access class according to the caller's established role, with the filtering applied before serialisation.", "Read a projection into a named external profile version, accompanied by the loss report for unmappable elements.", "Resolve a data carrier or web URI to the record, returning the matched granularity (group, type, sub-variant) explicitly." ], "create": [ "Create only with an authoritative identity anchor or an explicitly justified internally assigned identifier, plus initial classification, market scope and lifecycle state.", "Reject creation when the proposed identifier is already allocated, quarantined or retired.", "Record creation timestamp, identifier assignment timestamp and creating party separately.", "Run blocking validation before the record leaves draft state." ], "update": [ "Update only through an immutable change set that produces a new record version and cites the change classification and approver.", "Run the identity change-rule evaluation before applying any change to a declared attribute; a new-identifier outcome blocks the patch and opens a successor registration.", "Preserve superseded values with closed validity periods rather than overwriting them.", "Recompute validation, completeness and affected projections after each applied change set." ], "delete": [ "Logical deletion only for records that have ever been published: close validity periods, set lifecycle state to obsolete and retain a tombstone that preserves the identifier and its non-reuse status.", "Physical deletion is permitted only where a declared legal basis requires erasure, and requires named approval, a recorded legal basis and a retained deletion record.", "Deletion must not break inbound references from item instances, batches, BOMs or issued passports; blocked references are reported rather than cascaded.", "Retention clocks derived from post-market and passport obligations override routine housekeeping deletion." ] }, "roles": [ { "name": "Model owner", "responsibilities": [ "Approve scope, boundaries and model version increments for WM-OBJ-002.", "Adjudicate boundary disputes with sibling models and record the outcome in the registry.", "Approve breaking changes and the associated migration plan." ] }, { "name": "Identity authority", "responsibilities": [ "Select and evidence the authoritative identifier scheme per product family and market.", "Allocate identifiers and enforce the non-reuse and quarantine policy.", "Own the identifier change-rule set and its versioning, and approve new-identifier outcomes." ] }, { "name": "Data steward", "responsibilities": [ "Maintain completeness, currency and accuracy of assigned type records.", "Resolve conflicts between contributors according to the declared precedence rules and record the decision.", "Run the review cycle for provisional classifications and expiring evidence." ] }, { "name": "Compliance officer", "responsibilities": [ "Determine which regulatory obligations, passport regimes and markings apply per market and record the determination.", "Approve conformity claims, verify supporting evidence and monitor attestation expiry.", "Approve discontinuation only after post-market and retention obligations are declared." ] }, { "name": "Interoperability engineer", "responsibilities": [ "Maintain versioned crosswalks to external profiles and publish loss reports.", "Operate identifier normalisation, carrier specification and resolution behaviour.", "Validate round-trip integrity and gate projections on blocking validation outcomes." ] }, { "name": "Access controller", "responsibilities": [ "Assign access classes to attribute groups and approve embargo periods and lifts.", "Enforce role-based filtering at projection time and maintain the audit trail.", "Approve exceptions and record their legal or contractual basis." ] } ], "access": { "default_rule": "Deny by default. A caller receives only the attribute groups whose access class its established role permits, evaluated before serialisation; unclassified attributes are treated as restricted until an access class is assigned.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Passport and other legally mandated public data elements are readable without authentication where the governing instrument requires public access, and this exception must cite the instrument.", "Embargoed pre-release attributes are readable only by the issuing party and named approvers until the embargo lift timestamp, regardless of the caller's normal role.", "Regulatory authorities and market surveillance bodies may be granted read access to restricted attributes on the basis of a recorded legal request, with the request retained.", "Emergency safety access (recall, defect investigation) may bypass partner restrictions for named responders, subject to mandatory post-hoc review.", "Bulk export of media assets is denied unless a usage licence covering redistribution is attached.", "Investigational/draft GTINs shared only with named development partners (reuse exception depends on that restriction).", "UDI and certification artefacts may be public via GUDID/AccessGUDID while internal decision records stay steward-only.", "Break-glass read of discontinued tombstones for recall/traceability with mandatory audit." ], "audit_requirements": [ "Log every read of a restricted or embargoed attribute with caller identity, role, requested scope, decision and an RFC 3339 timestamp.", "Log every change set application, identity change-rule evaluation, lifecycle transition and access-class assignment with the approving identity.", "Log every projection to an external profile with the profile version, crosswalk version, access filter applied and loss report reference.", "Retain audit records at least as long as the record's declared post-market retention obligation, and make them tamper-evident by digest chaining.", "Make audit records available to the model owner, the compliance officer and, on recorded legal request, to the relevant authority.", "Log create, identity-key assignment, GTIN-change decisions, status transitions, publication and every exception read with agent, activity, event time and ingestion time." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Model ID and registry ID", "Authoritative identifier scheme and issuing authority", "Access classes and default rule", "Sibling model links and required composition targets" ], "read_order": [ "Read AGENTS.md first and resolve Name, Type, Model ID and registry ID before touching any data.", "Read the Specification URL to load the format-neutral semantics, scope and boundaries; do not infer semantics from the storage projection.", "Read the Storage type URL to learn how the canonical record is projected into the deployed store (including MongoDB collections or MCP resources) and which fields are derived.", "Read the Interface URL to learn the available read, create, update and delete operations, their preconditions and the access-class filtering behaviour.", "Read the Processes URL to learn the governed procedures: identifier allocation and change-rule evaluation, lifecycle transitions, validation gates, projection and audit.", "Only then resolve the required composition targets (item instance, party) and confirm they are reachable before performing any write." ] } }, "coverage": { "claim": "Covers the type-level (model / catalog-item) context surface for physical goods and catalogable services: identity anchoring and non-reuse, multi-scheme classification, dictionary-bound declared characteristics, variant and packaging structure, inter-type relations including the class-to-instance classification edge, lifecycle and change control, market and temporal applicability, type-level regulatory obligations including regulated type identifiers and model-level passport data, stewardship and provenance, and carrier/exchange projection. Instance, batch/lot, offer, price, availability and inventory semantics are excluded by boundary. This is not a claim of universal completeness: normative GS1, ISO and ESPR texts were partly unretrievable, sector-specific attribute sets are unenumerated, and the security dimension remains an evidence gap.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Authoritative anchor, issuing scheme, granularity, fallback UUID/ULID and canonical IRI are covered by GS1 Digital Link, GS1 trade-item rules and UNTP idGranularity/modelNumber. Identity priority is enforced in the artifact rules." }, { "dimension": "lifecycle", "status": "covered", "notes": "State model, change control, dual version axes, succession and discontinuation obligations are covered. State code lists themselves are Dimension-declared rather than standard-derived, which is stated as a gap in known_omissions." }, { "dimension": "relationships", "status": "covered", "notes": "Variant/group membership, packaging containment, accessory/spare-part/consumable/compatibility, predecessor/successor and substitution are supported by schema.org relations and GS1 packaging-level rules." }, { "dimension": "temporal", "status": "covered", "notes": "Validity periods, change effective dating, dual event/observation timestamps and as-of reads are required throughout; RFC 3339 with explicit offset is mandated in artifact_rules and canonicalization." }, { "dimension": "provenance", "status": "covered", "notes": "Attribute-level provenance with asserting party, source system, acquisition method and dual timestamps, plus derivation rules for computed values." }, { "dimension": "ownership", "status": "covered", "notes": "Brand owner, information provider, data steward and responsible economic operator are separated, with authority recorded per attribute group rather than per record." }, { "dimension": "validation", "status": "covered", "notes": "Rule sets with severity, classification-derived mandatory attribute sets, completeness scoring, conflict records and publication gating are specified, with GPC/IEC CDD supplying the mandatory-set and value-domain basis." }, { "dimension": "access", "status": "covered", "notes": "Deny-by-default with attribute-group access classes, embargo handling, five named exceptions and audit requirements; grounded in the DPP role-based access model." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Identifier non-reuse, post-market data retention, tombstoning and constrained physical deletion are specified. Concrete retention durations are jurisdiction-specific and were not obtainable from primary text; listed in known_omissions." }, { "dimension": "interoperability", "status": "covered", "notes": "Carriers, URI construction and resolution, versioned crosswalks with loss reports, and an explicit rule against claiming conformance without test evidence." }, { "dimension": "classification", "status": "covered", "notes": "Multi-scheme concurrent assignment with scheme version and basis, plus separate treatment of legally consequential nomenclature (HS) and risk classes." }, { "dimension": "measurement", "status": "covered", "notes": "Units, tolerances, value semantics, test methods and measurement basis are separated from the property definitions they bind to; unit code systems are referenced not redefined." }, { "dimension": "variant granularity", "status": "covered", "notes": "Three levels are kept distinct — product group, type identity, and shared-identity sub-variant qualifier — which several vocabularies collapse." }, { "dimension": "regulatory compliance", "status": "covered", "notes": "Responsible operator, registration, obligation inventory, passport data and markings are modelled at type level, scoped by market." }, { "dimension": "sustainability and circularity", "status": "covered", "notes": "Material provenance, recycled content, substances of concern and packaging materials are covered via UNTP and ESPR; specific delegated-act data sets are out of reach until adopted per product group." }, { "dimension": "spatial", "status": "not-applicable", "notes": "A product type has no location. Country of production, target market and facility are attributes or references, not a geometry of the type itself; geometry belongs to instances and facilities." }, { "dimension": "security", "status": "gap", "notes": "No primary source was found governing integrity, authenticity and anti-tampering of product master data itself. Digest-based integrity and credential-based claims are proposed by analogy from verifiable-credential practice and should be treated as unverified." }, { "dimension": "localisation", "status": "covered", "notes": "Locale-tagged names and descriptions, market-scoped attribute values and per-market declared quantities are represented, with an authoritative locale required." } ], "known_omissions": [ "Concrete record retention durations per jurisdiction: the obligation to keep passports accessible is sourced, but no primary text yielded numeric retention periods for the type record itself.", "Full article text of Regulation (EU) 2024/1781 could not be retrieved (EUR-Lex responses returned only the Official Journal index), so ESPR definitions of product model, batch, item and unique identifiers are grounded in the European Commission's own DPP page and UNECE UNTP rather than the article text.", "GS1 normative documents on gs1.org returned HTTP 403; the GTIN Management Standard rule list is therefore grounded in GS1 Member Organisation and GS1 Global Office support material rather than the standard PDF itself, and individual rule numbering is not asserted.", "ECLASS technical specification pages timed out; ECLASS is referenced only as an example of a property-dictionary scheme, with IEC CDD carrying the sourced property-semantics structure.", "ISO 8000 / ISO 22745 master-data quality requirements were not verifiable (iso.org returned 403), so no data-quality conformance is claimed.", "Software, digital goods and subscription catalog items are only boundary-noted; SWID tags, package URLs and CPE identity schemes were not researched.", "Product-group delegated acts under ESPR define the actual passport data sets and were not enumerated; only the framework and the model/batch/item granularity choice are modelled.", "Sector-specific dictionaries and mandatory attribute sets (GPC brick attribute lists, GDSN validation rule catalogues, healthcare and foodservice GTIN allocation variants) are referenced structurally but not enumerated.", "Pricing, promotion and assortment planning semantics are deliberately excluded and no assessment of their boundary details was made.", "EU Digital Product Passport (ESPR) type-versus-instance payloads are emerging and were not fetched as a primary source in this pass.", "Consumer Product Variant (AI 22) and variable-measure GTIN indicator 9 are noted in GS1 Digital Link/GTS but not modelled as first-class findings.", "ISBN-10 to ISBN-13/GTIN mapping, CAS chemical identifiers and proprietary taxonomies (Google product category, Amazon browse nodes, ETIM) are not specified beyond ASIN.", "Made-to-order versus made-to-stock class rules appear in GS1 ID Standard granularity text but were not fully expanded.", "National HS extensions, dual-use export controls and dangerous-goods UN numbers as type attributes are likely neighbours, not specified here.", "Full ISO 22745/8000 and IEC 61360 texts are paywalled; architecture is taken from official abstracts and freely available companion material.", "GS1 Web Vocabulary semantics chapter is still evolving as a separate Digital Link document." ], "conflicts": [ "Identity granularity conflict: in retail, a GTIN approximates one product type, but under EU medical device rules the Basic UDI-DI is a model-level identifier that groups several trade-item Device Identifiers. The 'model' level therefore sits above trade-item identity in one regime and coincides with it in another; the model handles this with an explicit granularity attribute rather than assuming one identifier per type.", "Sub-type conflict: GS1 Digital Link defines a consumer product variant qualifier that distinguishes variants sharing one GTIN, whereas schema.org expects each variant to be a distinct Product under a ProductGroup. A faithful projection to schema.org may therefore have to mint identifiers that GS1 does not require.", "Identity rigour conflict: schema.org productGroupID and model are free text with no allocation rules, while GS1 imposes licensed prefixes, change rules and permanent non-reuse. Round-tripping through schema.org can silently lose identity guarantees.", "Definitional conflict: a GS1 trade item is defined commercially (anything priced, ordered or invoiced), whereas an ESPR product model is defined technically (units sharing the technical characteristics relevant to ecodesign requirements). The two do not partition the same population, so one commercial type may span several regulatory models or vice versa.", "Classification non-alignment: GPC bricks, UNSPSC commodities, ECLASS/IEC CDD classes and HS subheadings are independently governed with different granularity and revision cycles, and no authoritative bidirectional crosswalk exists; concurrent assignment with a declared primary is the only defensible treatment.", "Packaging conflict: GS1 requires each priced or orderable packaging level to carry its own identifier, while several exchange formats and marketplaces model packaging as an attribute of a single product. Projections must not flatten the hierarchy silently.", "Versioning conflict: HS editions, GPC releases and IEC CDD dictionary versions change on independent schedules, so a single record can simultaneously hold assignments valid under different scheme releases; validity periods per assignment are mandatory rather than optional.", "schema.org Product permits nested Offer, GTIN-on-Offer and itemCondition, mixing type, offer and sometimes instance semantics; this model treats that as a projection conflict and strips offer/instance fields.", "GPC (retail physical goods, one brick per GTIN) versus UNSPSC (procurement goods and services) versus HS (customs) versus IEC 61360 (characterization class) have different purposes and no official mapping.", "FDA UDI-DI is packaging-level device version/model in GUDID; EU Basic UDI-DI/GMN is packaging-independent family identity — both are type-level but not equivalent.", "GTIN reuse: pre-2019 48-month (30-month apparel) reuse versus post-2018 never-reuse; healthcare and directly marked parts already never-reused. Historical reused GTINs remain in the wild.", "schema.org Product includes services (haircut, streamed episode); GPC guidance excludes services and digital products — a type may be valid as GTIN trade-item service and still have no GPC brick.", "ISO 22745 'item' can mean a physical object or a concept class; this model uses only the concept/class reading.", "ProductGroup is not offered for sale; a catalog item with a GTIN is orderable — do not store a group template as if it were a trade item." ], "regional_assumptions": [ "Passport, registry and responsible-economic-operator obligations as modelled are EU-derived (ESPR framework and the EU DPP Registry operational from 2026-07-20) and do not transfer unchanged to other jurisdictions.", "GS1 identification is global in reach but retail- and supply-chain-biased; sectors using HIBC, ISBN/ISSN, NSN, NDC or purely internal schemes are accommodated only through the generic scheme attribute.", "Customs classification assumes the WCO HS 6-digit international level with national extensions of differing length (for example EU CN at 8 digits, US HTSUS at 10); the model records the extension length rather than assuming one.", "Country and market codes are assumed to be ISO 3166-based, following UNTP's countryOfProduction; regional or economic-area scopes require an explicit code system declaration.", "Medical device evidence is drawn from EU MDR interpretation; the US device identifier model differs in structure and the two must not be conflated.", "No assessment was made of Chinese, Indian, Japanese or Brazilian product identification and registration regimes; assumptions for those markets are unsupported.", "GTIN-12/UPC is the common North American encoding; GTIN-13/EAN/JAN elsewhere; both canonicalise to GTIN-14.", "FDA UDI/GUDID is United States law; EU MDR Basic UDI-DI via GMN is a separate regime that may apply to the same type.", "Local labelling, language, net-content and certification regulations can force GTIN changes beyond the GS1 minimum.", "HS 2022 is the international core; national tariff schedules add digits and legal force.", "UNSPSC governance moved from GS1 US back toward UNDP; codeset version must be recorded because stewardship changed." ], "adversarial_checks": [ "Tested 'one product type equals one GTIN'. Rejected: the EU Basic UDI-DI groups multiple device identifiers under one model identifier, and GS1's own consumer product variant qualifier permits distinct variants under one GTIN. The model therefore carries an explicit granularity attribute instead of a fixed one-to-one assumption.", "Tested 'a catalog item is always physical'. Rejected: GS1 defines a trade item as any product or service that may be priced, ordered or invoiced. Physical-form findings (packaging, net content, dimensions) are marked as not applicable for non-physical types rather than defaulted, and a boundary note records the distinction.", "Tested 'the specification is fixed at registration'. Rejected: configure-to-order and made-to-order items have an open, rule-constrained option space with no enumerable member set. The variant finding carries an explicit enumerated-versus-configurable membership model.", "Tested 'schema.org is a sufficient basis for the identity layer'. Rejected: productGroupID and model are free text with no allocation, change or reuse rules, so schema.org is recorded as a projection target and alignment, never as the identity authority.", "Tested whether an inventory and availability layer belongs here. Rejected: schema.org separates Product from Offer and states a ProductGroup is not itself offered for sale; stock and price are instance- and offer-scoped and were removed to sibling models.", "Tested whether the engineering BOM structure should be absorbed. Rejected: WM-OBJ-019 already composes component types with quantities and effectivity; only a reference to the governing BOM revision is retained here to avoid duplicating a sibling model.", "Tested whether batch-level data could be folded into the type record for convenience. Rejected: UNTP's idGranularity and the GS1 lot key qualifier both make batch a distinct level, and folding it in would make measured batch values indistinguishable from declared type values.", "Tested whether conformance to GS1, ISO 8000 or ESPR could be claimed. Rejected: the normative texts were either paywalled or blocked during research, so all such relationships are recorded as alignments with explicit evidence gaps, per the no-conformance-without-evidence policy.", "Would a serialised laptop (IndividualProduct + AI 21) be incorrectly stored as WM-OBJ-002? Rejected: serial Digital Links and serialNumber are out of scope.", "Would an Amazon listing price and InStock flag be stored on the type? Rejected: schema.org Offer is a neighbour; publish-catalog-item strips those fields.", "Would a case-pack quantity change keep the case GTIN? Fail: GTIN Management pack/case quantity rule requires a new higher-level GTIN.", "Would a discontinued GTIN be reassigned to a new flavour after four years? Fail under current non-reuse (post-2018); only never-produced draft exception applies.", "Would GPC brick 10000384 be treated as unique product identity equivalent to GTIN? Fail: many GTINs share a brick; classification is not identification.", "Would GMN be used at POS instead of GTIN? Fail: GMN SHALL NOT identify a trade item.", "Would a used/refurbished unit be given a new catalog type under GTIN Management? Fail: standard SHALL NOT identify non-new trade items; that is instance condition.", "Would unofficial GPC-to-UNSPSC maps be marked as conforming? Fail: GS1/UNSPSC comparison states there are no official mapping tables." ] }, "researchAdjudication": { "providerMode": "dual-provider", "activeProviders": [ "claude", "grok" ], "waivedProviders": [], "providerPolicy": {}, "boundaryDecision": { "entry_kind": "classifier", "status": "accepted", "rationale": "Both providers independently converge on entry_kind 'classifier' and on the same four exclusions (serialised instance, batch/lot, commercial offer, engineering BOM structure), so the boundary is settled before any node is accepted. Claude's boundary set is adopted as canonical because it resolves eight neighbours rather than five, including the classification-scheme registry, logistics unit versus trade item, party/organisation roles, and non-physical catalog items — the last of which is what makes the classifier entry kind defensible for services and software rather than physical goods only. The type/instance split is asserted by both providers against the same primary evidence (GS1 class-versus-instance granularity, UDI Device Identifier versus Production Identifier, schema.org Product versus IndividualProduct), so no split, merge or reclassification is warranted." }, "decisions": [ { "concept": "Base provider selection", "disposition": "Claude adopted as base; Grok used as additive source only", "rationale": "Claude carries eight resolved neighbour boundaries against Grok's five, a fuller out-of-scope list, and layers Grok has no counterpart for (market and temporal applicability, attribute-level provenance, carriers and resolution, conformity evidence). Size was not decisive: Grok's stronger GS1/ISO/FDA source pinning was weighed and handled as targeted additions plus publication holds rather than a base swap." }, { "concept": "Entry kind: classifier", "disposition": "Accepted without change", "rationale": "Both providers independently declare classifier and both justify it by the type-classifies-instance relation rather than by naming convention, so no reclassification, split or merge is required before accepting structure." }, { "concept": "Consumer product variant (GS1 AI 22) as a sub-type level", "disposition": "Accepted in base form: in scope as a granularity qualifier, not as a distinct identity level", "rationale": "Claude keeps CPV in scope as a shared-identity sub-variant qualifier; Grok explicitly excludes it as sub-class. Resolved in the base's favour because a type model must state the boundary at which a variation becomes a new identity, and Grok itself lists CPV as an unmodelled known omission rather than as contradicting evidence. Excluding it would leave the group/type/sub-variant boundary undefined." }, { "concept": "Regulated type identifiers (FDA UDI-DI, GUDID, EU Basic UDI-DI as GMN)", "disposition": "Added from Grok into the regulatory-obligations layer", "rationale": "Materially missing from the base, backed by two tier-1 primary sources the base did not hold, and it upgrades the base's identity-granularity conflict from secondary guidance to primary evidence without duplicating the passport or conformity findings." }, { "concept": "Class-to-instance classification edge and BOM composition reference", "disposition": "Added from Grok into the inter-type-relationships layer, narrowed", "rationale": "The base declares the classifier entry kind but never governs the edge that realises it. Narrowed on merge so that sibling accessory/similar edges and vocabulary alignment stay with the existing findings that already own them." }, { "concept": "GTIN Management change rules as a standalone finding", "disposition": "Rejected as duplicative; base finding retained with a re-grounding hold", "rationale": "Grok's gtin-management-rules and the base's identifier-change-and-non-reuse cover the same decision surface. Adding both would put two change-rule findings in one layer. The real gain is source quality — Grok holds the ratified GTIN Management Standard Release 1.1 where the base was blocked by HTTP 403 — so this is recorded as a publication hold to re-ground the base finding, not as new structure." }, { "concept": "GTIN framed as the sole class identity anchor", "disposition": "Rejected; scheme-neutral anchor with explicit granularity retained from base", "rationale": "Grok's identity layer is GTIN-first. The base's scheme-neutral anchor with a declared granularity attribute survives the adversarial case both providers found independently: Basic UDI-DI groups several trade-item Device Identifiers, so model level sits above trade-item identity in one regime and coincides with it in another. A GTIN-first framing cannot represent that without contradiction." }, { "concept": "Auxiliary type identifiers (MPN, SKU, ASIN, NSN, ISBN, GMN)", "disposition": "Rejected as duplicative", "rationale": "The base's secondary-and-partner-keys finding already scopes non-authoritative keys by asserting party and namespace using UBL's buyer/seller/manufacturer/catalogue identification split, which is a stricter treatment than an enumerated list of key types." }, { "concept": "Names, brand and intended audience", "disposition": "Rejected as duplicative", "rationale": "Fully covered by the base's designation-brand-and-naming finding, including the locale hierarchy and brand-as-change-trigger. Grok's language-only-packaging rule is an attribute-level detail of the change-trigger question, not a separate node." }, { "concept": "Variant grouping and model lineage", "disposition": "Rejected as duplicative", "rationale": "Split across the base's variant-axes-and-product-groups and predecessor-successor-and-substitution findings, both of which are more precise: the base separates succession from substitution and keeps enumerable versus configurable membership explicit, which Grok's single finding collapses." }, { "concept": "ISO 8000-110 / ISO 22745 identification-guide conformance", "disposition": "Deferred, not added", "rationale": "Grok concedes the ISO texts are paywalled and its architecture derives from abstracts and companion material, while the base explicitly refused any data-quality conformance claim after iso.org returned 403. Weakly supported structure is preferred deferred over accepted, and the base validation finding already carries versioned rule sets with blocking severity." }, { "concept": "Retire-catalog-item and resolve-class-digital-link functions", "disposition": "Rejected as duplicative", "rationale": "Retirement with tombstone and reuse block is already split across the base's supersede-product-type and transition-lifecycle-state; Digital Link resolution is covered by resolve-identifier-to-record, which additionally scopes returned resources by requesting role." }, { "concept": "Model-level Digital Product Passport", "disposition": "Retained from base despite Grok's omission", "rationale": "Grok lists ESPR/DPP as not fetched in this pass, so its silence is an evidence gap rather than a contradiction. The base grounds the finding on the European Commission DPP page and UNTP model granularity, both tier-1, and it is held for re-verification against the regulation text and UNTP v1.0." }, { "concept": "Service and software catalog items in scope", "disposition": "Accepted from base with physical-form findings marked not-applicable", "rationale": "Both providers agree a trade item may be a service that is priced, ordered or invoiced. The base's rule that packaging, net content and dimension findings are omitted rather than defaulted for non-physical types is the safer treatment and is consistent with Grok's own observation that GPC has no brick for pure services." }, { "concept": "Packaging levels as distinct trade items", "disposition": "Accepted from base; strongest cross-provider agreement", "rationale": "Both providers derive per-level identifiers and the logistics-unit exclusion from GS1 independently, and both warn that exchange formats flatten the hierarchy. The base finding is kept as-is; Grok's pack-quantity change rule is an attribute detail folded into the existing change-trigger question." } ], "publicationHolds": [ "Source verification: re-fetch and pin every accepted source URL and version before publication — GS1 Digital Link 1.7.0, GTIN Management Standard 1.1, schema.org release version (base pins V30.0 while the added-source provider used an unpinned July 2026 index snapshot), GPC v20251127, HS 2022, FDA UDI page currency, and GS1 GSCN 24-004.", "Re-ground the base identifier-change-and-non-reuse and net-content-dimensions-and-weight findings on the ratified GTIN Management Standard, which the base could not retrieve (HTTP 403) and sourced from GS1 support and Member Organisation material instead; do not assert individual rule numbering until the normative text is read.", "UNTP Digital Product Passport is cited at v0.7.0 work-in-progress with v1.0 expected 2026-09-01; every finding depending on UNTP idGranularity, productCategory, characteristics, materialProvenance or performanceClaim must be re-verified against v1.0 before publication.", "ESPR article text (Regulation (EU) 2024/1781) was not retrieved; the model-level passport, responsible-operator and market-placement findings rest on the European Commission DPP page and UNTP. Verify the definitions of product model, batch, item and unique identifier against the regulation before publishing them as legal statements.", "Multi-profile validation is incomplete: the merged model must be exercised against at least retail/FMCG (GS1/GDSN), medical device (FDA UDI and EU MDR Basic UDI-DI), industrial MRO (dictionary-bound properties), and a non-physical catalog item (service or software) before any completeness claim is published.", "The security dimension is an open evidence gap — neither provider found a primary source governing integrity, authenticity or anti-tampering of product master data itself. Publish it as a stated gap and do not present digest-based integrity or credential-based claims as sourced." ], "deferredResearch": [ "ISO 8000-110 and ISO 22745 identification-guide conformance for characteristic-data exchange: both providers were blocked by paywalls, so the conformance-checkable message model is deferred rather than modelled from abstracts.", "ESPR product-group delegated acts and the concrete passport data sets they mandate; only the framework and the model/batch/item granularity choice are currently modelled.", "Non-physical catalog item identity schemes for software and digital goods — SWID tags, package URLs, CPE, and ISBN/ISSN-to-GTIN mapping — which both providers boundary-noted but neither researched.", "Consumer product variant (GS1 AI 22) and variable-measure GTIN indicator 9: decide whether the sub-variant qualifier stays an attribute of the identity anchor or earns a first-class node, using the GS1 General Specifications text.", "ECLASS technical specification (timed out for the base provider) and sector-specific mandatory attribute sets: GPC brick attribute lists, GDSN validation rule catalogues, and healthcare/foodservice GTIN allocation variants.", "Product identification and registration regimes outside the EU and US — notably China, India, Japan and Brazil — for which both providers explicitly recorded unsupported assumptions.", "Concrete per-jurisdiction retention durations for the type record, its passport and its compliance evidence after discontinuation; the obligation is sourced but no numeric period was obtainable from primary text." ] }, "statistics": { "sources": 30, "bundles": 7, "layers": 14, "findings": 30, "questions": 120, "artifacts": 17, "functions": 14 } }