ISO 29002:2026 consolidates six former Technical Specifications into a single International Standard specifying the identification scheme (IRDI), concept dictionary model and resolution services on which semantically interoperable characteristic data exchange depends. It is the infrastructure standard beneath ISO 8000-110 conformance, IRDI-based identifiers and any serious cross-organisational product data exchange — and KOIOS, registered as ICD 0194, appears in the standard itself as a reference example of that infrastructure in operation.
The original ISO/TS 29002 series was published as six separate Technical Specifications, each addressing a specific layer of the characteristic data exchange infrastructure. Part 4 addressed basic datatypes. Part 5 specified the identification scheme and the International Registration Data Identifier. Part 6 defined the concept dictionary terminology reference model. Part 10 specified the characteristic data exchange format. Part 20 defined the concept dictionary resolution services. Part 31 addressed the query mechanism for characteristic data. Together they formed a coherent architecture — but one that required a practitioner to hold six separate documents, navigate cross-references between them and track which normative reference was relevant to which aspect of an implementation.
ISO 29002:2026 brings all six parts into a single document, with the content of each former Technical Specification incorporated into a numbered clause:
Formerly ISO/TS 29002-4.
Formerly ISO/TS 29002-5.
Formerly ISO/TS 29002-6.
Formerly ISO/TS 29002-10.
Formerly ISO/TS 29002-20.
Formerly ISO/TS 29002-31.
The practical effect is significant. An organisation implementing ISO 29002-conformant infrastructure now works from a single authoritative document, with a unified data model, consistent terminology and a single set of conformance requirements against which any implementation can be validated. The consolidated document also incorporates technical revisions that were not possible within the constraints of the individual Technical Specifications: updated provisions allowing the use of new technologies for data exchange, a clarified operation of the location service, an alternative process for operating in the absence of a location service, and updated notation across all figures for consistency and readability.
At the foundation of ISO 29002 is the International Registration Data Identifier — the IRDI — which clause 6 specifies as the identifier for all administered items in a concept dictionary. Understanding the IRDI is essential to understanding why the ISO 29002 architecture achieves what column headers, part numbers and free-text property labels cannot.
ICD (per ISO/IEC 6523) + organisation identifier — globally unique by construction.
Identifies the specific administered item within that authority's concept dictionary.
Completes the tuple, supporting controlled evolution of concept definitions over time.
The IRDI’s structure encodes not merely a unique label but a resolution path: any receiving system can use the location service in clause 9 to retrieve the terminology and ontology services for that authority. The IRDI does not just point to a meaning — it specifies the path by which any system can retrieve that meaning, programmatically, without human intervention.
The concept dictionary model specified in ISO 29002 addresses a problem that is more fundamental than most data governance frameworks acknowledge. When two organisations exchange product data, the individual data values — dimensions, material codes, performance parameters — are in principle straightforward to transmit. The difficult problem is transmitting the meaning of those values in a form that the receiving system can interpret correctly without depending on the receiving party’s prior familiarity with the sending party’s internal terminology. The concept dictionary model is the mechanism by which that problem is solved.
A concept dictionary, in the sense defined by ISO 29002, is a collection of concept dictionary entries, where each entry contains at minimum a concept identifier — the IRDI — a term and a definition. The dictionary enables lookup by concept identifier. When a characteristic data message references an IRDI rather than a property label, the receiving system is not dependent on recognising the label. It resolves the IRDI against the concept dictionary to retrieve the definition, the applicable terms in all supported languages, any associated symbols or images, and the full terminological context of the property. The meaning travels with the data — not as embedded text, which is static and prone to variation, but as a reference to a defined, versioned, externally maintained and machine-resolvable concept.
ISO 29002 also specifies a concept equivalence relationship — a formally defined assertion that two or more concepts from different concept dictionaries have the same meaning. This is the mechanism by which organisations using different dictionaries — different terminology systems, different natural languages, different domain conventions — can exchange characteristic data and confirm that the concepts referenced are semantically equivalent. For organisations operating across the boundaries of industrial sectors, regulatory jurisdictions or trading blocs, this equivalence mechanism is not an optional feature. It is what makes a genuinely open data exchange infrastructure possible rather than a series of bilateral agreements between organisations who happen to use the same dictionary.
Clause 9 specifies three runtime services that together form the infrastructure of a semantically interoperable characteristic data ecosystem.
Given a registration authority identifier, returns the internet address of that authority's terminology and ontology services. The architectural entry point — no system needs to know URLs in advance.
Returns the detailed content of the concept dictionary by IRDI: terms, definitions, abbreviations, symbols, images and concept equivalence relationships across all supported languages.
Returns the ontological description: the concept's position in a class hierarchy, associated properties, value constraints and relationships between classes.
ISO 29002 addresses semantic interoperability explicitly and formally, and the normative content of the document reflects an understanding of the problem that goes well beyond the simplistic framing — common in data governance discussions — of interoperability as a matter of agreeing on formats. Annex K of the document articulates the technical case directly: “the inability to map terminological items from different sources is a common root cause of failure for organizations attempting an exchange of characteristic data without loss of meaning.” This is not a theoretical observation. It is the documented operational reality of industrial data exchange at scale.
The document draws on an IEC Strategic Management Board Study Group report that states the point with precision: machines need “a common language — the same set of semantically-defined digital representations of information — to understand each other.” The implication, which ISO 29002 operationalises in its concept dictionary model and resolution services, is that semantic interoperability is an engineering requirement, not a governance aspiration. It requires methods for specifying semantics that are formal, machine-processable, accessible under appropriate licensing and resolvable at the point of receipt — precisely the set of properties that the ISO 29002 architecture provides.
The benefits of well-specified semantic domains that the document identifies are measurable in operational terms: reduced cost of translation at any location of usage; greater quality of data exchange by eliminating errors arising from erroneous assumptions of meaning; increased rates of data exchange by reducing the translation effort that poorly specified data requires; and more flexible systems capable of accommodating future evolution without renegotiating the semantic foundations of every bilateral data relationship. These are not abstract qualities. They are the engineering case for investing in ISO 29002-conformant infrastructure before the pressure of supply chain, regulatory and Digital Product Passport requirements makes the absence of that infrastructure visible — and costly.
One of the substantive technical revisions in ISO 29002:2026 is the explicit support for modern API technologies. The original Technical Specifications defined exchange formats and service interfaces primarily in XML and WSDL/SOAP — the dominant technologies for structured data exchange at the time of their publication. While these technologies remain specified and supported, ISO 29002:2026 adds OpenAPI Specification format with JSON as an alternative binding for all three resolution services, reflecting the shift in industry practice towards REST-based APIs and JSON-native data exchange.
Ten in XML and ten in OpenAPI Specification format.
WSDL with SOAP binding and HTTP binding with OAS schema, for the location, terminology and ontology services.
ISO 29002:2026 is not a document in which KOIOS appears as a downstream user of the infrastructure it specifies. It is a document in which KOIOS appears as a reference example of that infrastructure in operation. Annex K, Table K.1 of the standard presents a set of equivalent concept entries from different concept dictionaries, demonstrating how the same real-world concept — a power contactor — is represented across the IEC Common Data Dictionary, ECLASS and the KOIOS Concept Dictionary. The KOIOS entry, identified by ICD 0194, appears alongside the most widely deployed industrial concept dictionaries as an illustration of the concept equivalence mechanism that ISO 29002 specifies.
KOIOS holds ICD 0194 as a registered issuing organisation under ISO/IEC 6523 — the organisation identification scheme that governs the registration authority identifier component of every IRDI. This registration is not incidental. It means that every IRDI issued by KOIOS under ICD 0194 is globally unique in the precise technical sense that ISO 29002 requires: no other registration authority operating under any other ICD can issue the same identifier. The KOIOS concept dictionary is therefore not merely a collection of definitions that can be referenced in product data. It is a registered, globally unique concept dictionary whose entries are resolvable under the resolution service architecture that ISO 29002 specifies — a fully conformant implementation of the infrastructure standard whose architecture this article describes.
For manufacturers onboarding product data into K:spec, this means that every property identifier assigned to their data carries provenance traceable to a concept defined in a registered, internationally recognised concept dictionary — one that is referenced in the standard itself. That provenance is not metadata that an organisation adds later to meet a regulatory requirement. It is embedded in the data architecture from the point of creation, in accordance with the infrastructure standard that the wider ecosystem of industrial data exchange depends upon.
ISO 29002:2026 raises four direct questions about any existing data infrastructure:
Are concept identifiers used in product data globally unique IRDIs — or internal labels meaningful only inside the system that issued them?
Is the concept dictionary registered under an ISO/IEC 6523-based ICD, so the registration authority component of every IRDI is globally unique and resolvable?
Are the terminology and ontology services accessible over the internet using the clause 9 service interfaces (now including JSON / OpenAPI as well as SOAP)?
Are concept equivalence relationships defined, so data exchanged with parties using other dictionaries can be confirmed semantically equivalent automatically?
For most organisations, the existing infrastructure cannot answer yes to any of these with confidence. The gap is real, but not irremediable. ISO 29002:2026 defines the infrastructure precisely. The KOIOS platform — including K:spec and the KOIOS Concept Dictionary registered under ICD 0194 — implements it.