ISO/IEC 5181:2026

• Abstract:

  This document provides guidelines, methodologies and techniques for securely deriving information about data assets from multiple sources, intermediaries or users, which is denoted as provenance metadata.

• Status: Published
• Publication Date: 22-Oct-2026
• ICS: 35.030 - IT Security
• Technical Committee: ISO/IEC JTC 1/SC 27 - Information security, cybersecurity and privacy protection
• Drafting Committee: ISO/IEC JTC 1/SC 27/WG 4 - Security controls and services
• Current Stage: 6060 - International Standard published
• Start Date: 23-Oct-2026
• Completion Date: 23-Oct-2026

ISO/IEC 5181:2026 is an ISO/IEC document on information security, cybersecurity and privacy protection with a focus on data provenance. It gives guidelines, methodologies and techniques for securely deriving provenance metadata about data assets from multiple sources, intermediaries or users. It is written for people who need to assess, document, exchange, or reuse provenance information in shared data and production-linked environments.

What does ISO/IEC 5181:2026 specify?

ISO/IEC 5181:2026 specifies how provenance metadata can be derived and used for data assets in a system of cooperating stakeholders. The document ties that work to data sharing, production processes, and trust in the resulting data or product.

The document is organized into:

• Clause 1, Scope
• Clause 2, Normative references
• Clause 3, Terms and definitions
• Clause 4, Abbreviated terms
• Clause 5, Data provenance methodology
• Clause 6, Data provenance information model
• Annexes A to D, all informative
• Bibliography

Annex	What it covers
Annex A	DP artefacts of narrative of provenance
Annex B	Operational ontology of DP
Annex C	Dataspaces for data provenance
Annex D	Data provenance constraints derived from EU Acts/regulations

What are the key requirements of ISO/IEC 5181:2026?

ISO/IEC 5181:2026 is built around a traceable link between data history and the corresponding production or usage history. In practice, that means provenance is not treated as a standalone record - it is checked against events, state changes, and expected outcomes in the wider system.

Clause 5 - the methodology

Clause 5 defines two parallel value streams: the upper <data, metadata> stream and the lower production stream. Figure 1 frames them as synchronized paths, with stakeholder categories for provider, intermediary, and user. For an engineer or buyer, this means provenance work has to follow the actual life cycle of the data and the related production activity, not just store metadata after the fact.

Clause 5.1 breaks the method into eight activities, from describing data and metadata, through provisioning resources, observing production events, and integrating measurements, to verifying user expectations. This matters because the standard expects provenance to be built from a sequence of observable steps, not from a single declaration.

Clause 5.2 makes verification and validation central. The two value streams are intended to be checked against each other, and trust is tied to whether the <data, metadata> model and the produced asset are semantically comparable. In practice, provenance evidence should support a claim that the data story matches the physical or operational result.

Clause 5.3 explains the semantics of the value streams. It treats data and production as corresponding streams, describes stakeholder roles and resources, and uses graph-based trajectories to represent state changes over time. The section also links provenance to metadata categories such as provenance, identities, and rights (PIR), and to quality of data (QoD). This is important when a team needs to show who acted, what changed, and what evidence supports use of the data.

Clause 5.4 introduces a formal language approach. It uses variables, propositions, the semiotic triangle, and morphisms to describe how provenance statements are formed and interpreted. In practice, provenance claims need a defined context, bound variables, and a clear relation between symbols, meanings, and real-world events.

Clause 6 - the information model

Clause 6 defines the data provenance information model (DPIM) and applies it to things of interest (ToI). It shows how provenance metadata is created, managed, published, and subscribed through life cycle stages, and how that supports trust in data or products.

Clause 6.2 describes data flow control in dataspaces. It links provenance to retrieval, distribution, manipulation, life cycle management, and security of heterogeneous data tuples. Clause 6.3 presents a complexity model in which the more a product and its data evolve, the harder it becomes to maintain trust and verify expectations. Clause 6.4 gives a reference architecture model with three layers - application, access provisioning, and common dataspace - and ties them to digital identities and digital rights. Clause 6.5 adds the security and privacy model, using annotations, authorization, warrants, confidentiality, integrity, and personally identifiable information (PII) to represent privacy-related provenance.

What terms does ISO/IEC 5181:2026 define?

• data asset - a collection of data items that provides value to roles such as provider, intermediary, and user.
• data provenance - the ownership and usage history of data in a system, described through metadata about origins, sources, and parties involved.
• provenance metadata - metadata about the provenance of data, used to record history, state, and changes over the life cycle.
• dataspace - a governance framework and supporting services for trustworthiness and data sharing through agreed policies, semantic models, protocols, and processes.
• narrative of provenance (NoP) - an ordered account of data manipulations and events, expressed as provenance metadata.
• data provenance information model (DPIM) - the model that keeps information about things of interest and their life cycle metadata.
• life cycle value stream (LC VS) - the sequence of stages through which data or production is observed, processed, and verified.
• trustworthiness (TW) - the ability to meet stakeholders’ expectations in a verifiable way.

Who uses ISO/IEC 5181:2026?

ISO/IEC 5181:2026 is used by data providers, intermediaries, and data users who need to share data with traceable history. It also suits teams that manage digital identities, rights, security, and privacy in a dataspace.

The document is relevant in smart manufacturing, smart factory, industrial IoT, health care, energy distribution, smart city, and digital twin work. Typical tasks include capturing provenance metadata, checking histories of data manipulation, validating data against production results, and deciding whether data can be reused as a common good.

Which standards are used with ISO/IEC 5181:2026?

ISO/IEC 5181:2026 cites several standards and related documents that give context to its models and terminology:

• ISO/IEC 20151-1 - dataspace concepts and characteristics used for the dataspace model
• ISO/IEC 30141 - IoT reference architecture used as a context for connected systems
• ISO/IEC 27001 - information security management systems requirements, relevant to security controls around provenance
• ISO/IEC 29100 - privacy framework, relevant to the privacy model
• ISO/IEC 25012 - data quality model, relevant to quality of data
• ISO/IEC 11179-1 and ISO/IEC 11179-33 - metadata registry framework and metamodel for data set registration
• ISO/IEC TS 5723 - trustworthiness vocabulary used for trust terms
• ISO/IEC 62890 - life cycle management for systems and components, relevant to the life cycle view
• ISO/IEC 30194 - best practices for IoT and digital twin use cases
• ISO/IEC/TS 30149 - trustworthiness principles for IoT
• IEC 62443 series - security requirements and processes for industrial automation and control systems

What does the ISO/IEC 5181:2026 document contain?

ISO/IEC 5181:2026 contains four informative annexes, four main figures, and one detailed table in Annex A. Figure 1 presents the dual data and production value streams, Figure 2 the complexity model, Figure 3 the reference architecture model, and Figure 4 a security and privacy example built from provenance annotations.

The annexes add practical context. Annex A gathers narrative-of-provenance artefacts for smart manufacturing and smart factory use, Annex B develops an operational ontology with process graphs and isomorphy, Annex C explains how dataspaces support provenance and verification, and Annex D relates provenance handling to EU regulations.

International
Standard
ISO/IEC 5181
First edition
Information security, cybersecurity
2026-10
and privacy protection — Data
provenance
Sécurité de l’information, cybersécurité et protection de la vie
privée — Provenance des données
Reference number
© ISO/IEC 2026
All rights reserved.
This ISO publication is protected by copyright and is owned by ISO and/or its licensors.
The content of this ISO publication is provided under licence, not sold. Use is subject to the applicable licence terms issued by ISO,
an ISO member body, or an authorized third-party distributor.
Except as required for implementation or expressly permitted by a separate licence, no part of this ISO publication may be
reproduced, distributed, modified, used, or made available in any form or by any means – electronic or mechanical, including
photocopying, scanning, recording, or posting on internal or external digital platforms.
Any use beyond the scope of the granted rights is prohibited and may result in legal action.
ISO copyright office
CP 401 • CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2026 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 5
5 Data provenance methodology . 6
5.1 General assumptions .6
5.2 Verification and validation principles .7
5.3 Value stream semantics . .8
5.3.1 Correspondence between LC value streams .8
5.3.2 Value stream behaviour .8
5.3.3 Representation of VS semantics .9
5.3.4 Continuity aspect of operating products and data .10
5.3.5 Formal language terms . .10
5.3.6 Processing of trust .10
5.3.7 Quality of data provenance .11
5.4 Value stream description language.11
5.4.1 Using variables .11
5.4.2 Data provenance proposition .11
5.4.3 Catalogue of narrative of provenance artefacts . 12
5.4.4 Generating a narrative of provenance by example . 13
6 Data provenance information model . 14
6.1 General .14
6.2 Data flow control model .14
6.3 Data provenance complexity model .14
6.4 Data provenance reference architecture model . 15
6.5 Data provenance security and privacy model .16
Annex A (informative) DP artefacts of narrative of provenance .18
Annex B (informative) Operational ontology of DP .23
Annex C (informative) Dataspaces for data provenance .25
Annex D (informative) Data provenance constraints derived from regulations .27
Bibliography .28

© ISO/IEC 2026 – All rights reserved
iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Information security, cybersecurity and privacy protection.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.

© ISO/IEC 2026 – All rights reserved
iv
Introduction
This document provides guidelines and methods on how to derive data provenance information from a
system of co-operating authenticated stakeholders. Data provenance is valid if, the data value stream
represented by sequences of < data, metadata > tuples, in any life cycle phase of compound industrial data
and production value streams, is always comparable to the value stream of production involving operational
technology. Hence, the < data, metadata > tuples value stream is twinning the production value stream such
that both data and production value streams are isomorphic to each other.
The use and processing of data performed by applications, systems, robots, individuals, agents or companies
[23]
usually is subject of permissions from data owners as applied in ISO/IEC 62890.
“Data owner” is a term that is applied to the rights of a data holder. Data holders have the rights to access,
use, or manipulate their data. The data owner role is understood as an individual or a group of stakeholders
who can have control over certain data attributes like data creation, accuracy or the names or identifiers of
sources, etc.
Data provenance information is useful to all who want to use available data in other applications or want
to decide to make data voluntarily available as a common good in a dataspace that can be subscribed by
various application stakeholders. Identifying and deriving information from the history of metadata events
provide details on the narratives of data provenance and data manipulations. The concept of narration is
used because it visually describes sequences of activities or the state changes of a system. Graphically, a
sequence of state changes or events is a graph trajectory.

© ISO/IEC 2026 – All rights reserved
v
International Standard ISO/IEC 5181:2026(en)
Information security, cybersecurity and privacy protection —
Data provenance
1 Scope
This document provides guidelines, methodologies and techniques for securely deriving information about
data assets from multiple sources, intermediaries or users, which is denoted as provenance metadata.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
data
data asset
collection of data items that provide value to organizations playing roles like data provider, data intermediary
and data user
Note 1 to entry: Data are a product, hence data are an asset that can be disseminated, shared, distributed, consumed, or
copied by processes or humans involved in the workflow of an enterprise, factory, information and data infrastructure
or human-machine cooperating communities like smart cities, smart factories etc.
3.2
data altruism
voluntary sharing of data without compensation
Note 1 to entry: Voluntary sharing of data is based on consent of certain data subjects to process their personal data
and to get permission from data holders to use non-personal data.
[11]
Note 2 to entry: Data can be shared via a virtual data sharing platform, such as a dataspace.
Note 3 to entry: A certification framework can provide organizations with voluntary authorization by governments
compared to a framework with compulsory authorization.
[26]
Note 4 to entry: In this context, data altruism is interpreted according to Article 2(16) of the EU DGA.
3.3
artefact
constructive, descriptive or semantic element of views on a thing of interest (ToI) as represented by the
semiotic triangle with three views on the ToI
Note 1 to entry: The construction of things view obeys operational engineering constraints, the description view obeys
requirements represented by an ontological language, and the semantics view is given in a notation that supports
reasoning analysis of the past and predictive simulation-based analysis of future behaviour of a ToI.

© ISO/IEC 2026 – All rights reserved
Note 2 to entry: The ToI can be modelled by an urban digital twin (UDT) which feeds back information from the
performed analysis.
Note 3 to entry: The term artefact is preferred in formal systems because it means an intangible concept in contrast to
a physical object.
3.4
computation
graph computation
sequence of directed edges of a graph (trajectory) that is enabled by annotated rules conditioning the
execution of sequences of edges of the graph
Note 1 to entry: A data graph is an asset that is applied and manipulated along an executable life cycle value stream
(LC VS) trajectory.
Note 2 to entry: A process graph is defined by three things i.e. a set of vertices (i.e. process states), a vertice-disjunct
set of edges (i.e. transitions) and an incidence mapping that maps an edge either into an undirected pair of vertices (i.e.
action), or that maps an edge into a pair of directed vertices (i.e. event). For short, the latter is called directed edge and
the former undirected edge.
Note 3 to entry: Data or process assets both, are modelled by computable graphs, i.e. data graphs or process graphs.
3.5
dataspace
data governance framework and supporting services to build trustworthiness and enable data sharing
through an agreed set of policies, semantic models, protocols and processes
Note 1 to entry: More formally, a dataspace can be considered as a set of data assets annotated with metadata such
as data provenance information, which is organized as a publish-subscribe dataspace that manages many-sorted data
[5]
type items as < n-tuples > , whereby < n-tuples > are defined for n ≥ 2 elements of respective sorts.
Note 2 to entry: sort is a term from applied mathematics that represents a variable i.e. a set of terms of a considered
type.
1)
[SOURCE: ISO/IEC 20151-1:— , 3.1, modified — definition has been modified to align with the context of
this document; notes 1 and 2 to entry have been added.]
3.6
data graph
graphical representation of a data structure using graph artefacts such as vertices, edges and an incidence
mapping
Note 1 to entry: In the data provenance methodology of subclause 5.2, components of a data structure are graphically
represented by tree-like graphs i.e. data graphs.
Note 2 to entry: The graph semantic artefacts allow to represent either data structures or knowledge but also
behaviour of processes or stakeholders that communicate via the dataspace.
Note 3 to entry: A graph is defined by three elements i.e. a set of vertices, a vertices-disjunct set of edges and an
incidence mapping that maps an edge either into an undirected pair of vertices, or that maps an edge into a pair of
directed vertices.
3.7
process graph
graphical representation of a process using graph artefacts such as vertices, edges and an incidence mapping
Note 1 to entry: The elements of a process are graphically represented by a mesh-network-like graph.
Note 2 to entry: The graph semantic artefacts allow to represent behaviour of processes or stakeholders that
communicate via the dataspace, but also data structures or knowledge.
1) Under development. Stage at the time of publication: ISO/IEC FDIS 20151-1:2026.

© ISO/IEC 2026 – All rights reserved
Note 3 to entry: A graph is defined by three elements i.e. a set of vertices, a vertices-disjunct set of edges and an
incidence mapping that maps an edge either into an undirected pair of vertices, or that maps an edge into a pair of
directed vertices.
3.8
data governance
process focused on managing the quality, consistency, usability, security, and availability of data
Note 1 to entry: This process is closely linked to the notions of data ownership and stewardship.
[27]
[SOURCE: ISO/TR 14872:2025, 3.3, modified — “information” has been replaced by “data”.]
3.9
data leakage
drain of data that makes the operation phenomenon, including the phenomenon’s data, untrustworthy
Note 1 to entry: The longer the life cycle value stream (LC VS) of operation, the higher the complexity of production.
Higher complexity creates a higher risk of data leakage or other non-authorized manipulations.
3.10
metadata
data that defines and describes other data
Note 1 to entry: In the ISO/IEC 11179 series and ISO/IEC 19763 series of standards, the objects being described are
instances of the subclasses of item, e.g. concepts, data elements, services.
[19]
[SOURCE: ISO/IEC 11179-3:2023, 3.2.30, modified — note 1 to entry has been added from
[20]
ISO/IEC 11179-3:2023/Amd 1:2026 ]
3.11
provenance metadata
metadata about the provenance of data
Note 1 to entry: Metadata comprises in practice various categories of information about the state of data that is
observable during the life cycle value stream (LC VS).
Note 2 to entry: Metadata derived during the LC VS of processing assets has the purpose to provide trust in the
incorporation of data subscribed from a dataspace.
Note 3 to entry: Metadata annotated to data that are generated and derived during the operation of a physical
machinery (e.g. energy distribution, automated production, self-driving cars) is called the narrative of provenance
(NoP) of the associated data of interest.
Note 4 to entry: By inspecting the NoP, the data of interest can be applied by stakeholders, processes, or individuals
in contexts different from the source contexts. Based on the NoP, interested parties can decide which of their data
subscribed from the dataspace, they want to use as a common good and which not.
3.12
data provenance
ownership and usage history of data of a system, consisting of information that is given by sets of metadata
describing origins, sources of data, parties involved in generating, manipulating, and managing any data
[10]
Note 1 to entry: A similar definition of data provenance is given in VDE SPEC 90009 v1.0 that defines data provenance
(DP) as the origin of the metadata values comprising person, organization, software agent, file or unknown. VDE
[10] [13] [10]
SPEC 90009 v1.0 is based on IEC 61360-1 that defines the attributes for the specification of meta-metadata.
[10]
Note 2 to entry: In this document and in contrast to the VDE SPEC 90009 v1.0 , metadata (values) of data provenance
information are interpreted semantically which means metadata (values) are derived during the life cycle value
streams in the same activity or phase of production from the data and from the production.
[21]
Note 3 to entry: A similar definition of data provenance is given in ISO/IEC 11179-33 that defines provenance as
information on place and time of origin, derivation or generation of a data set, proof of authenticity of the data set, or a
data set of past and present ownership of that data set.

© ISO/IEC 2026 – All rights reserved
3.13
provability
verifiability
degree to which something can be reliably demonstrated or formally proven
Note 1 to entry: Defining the data provenance involves specifying provenance evaluation criteria and requirements
that can demonstrate the data provenance of a system in a provable way.
Note 2 to entry: Provability is an important element of the data provenance methodology.
3.14
quality of data
degree to which the characteristics of data satisfy stated and implied needs when used under specified
conditions
Note 1 to entry: Quality of data (QoD), e.g. of a blueprint of car production, is coupled with the quality of the operation
phenomenon of a technical production of a car.
Note 2 to entry: Data are an informational asset that digitally mirrors the behaviour of an operational asset. The
coupling is understood as the technical phenomena of a system’s machinery, e.g. car production, that is tightly coupled
with the mirroring asset of data capturing through sensors and data analysis provisioning to actuators on a high level
of quality of data.
[SOURCE: ISO/IEC 25012:2008, 4.3, modified — preferred term has been made “quality of data” (QoD); Notes
to entry have been added.]
3.15
security
resistance to intentional unauthorized acts designed to cause harm or damage to a digital data asset or to
personally identifiable information captured by a system
Note 1 to entry: Security is the freedom from misuse of data.
Note 2 to entry: In the context of data provenance, “system” includes data and their associated metadata.
[SOURCE: ISO/IEC 23643:2020, 3.16, modified — in the definition, “system” has been replaced by "digital
data asset or to personally identifiable information captured by a system”; Notes to entry have been added.]
3.16
privacy
right of individuals to control or influence information related to them that may be collected and stored and
by whom and to whom that information may be disclosed
Note 1 to entry: In the context of data provenance, privacy refers to control of the data and the associated metadata.
[28]
[SOURCE: ISO 7498-2:1989, 3.3.43, modified — Note to entry has been replaced.]
3.17
semantics
mapping between elements of a language and the real world
Note 1 to entry: The semantics of data manipulation can be described in computational terms such as processes,
variables and many-sorted data types.
Note 2 to entry: The semantics of production process based on state changes during life cycle value streaming can be
represented by graphs comprising events and states.
[29]
[SOURCE: ISO/IEC TR 24800-1:2012, 2.5, modified — Notes to entry have been added.]
3.18
semiotic triangle
model that relates linguistic symbols to semantic concepts and to the objects they represent
Note 1 to entry: Linguistic symbols can be terms or signs, possibly from an ontology.

© ISO/IEC 2026 – All rights reserved
Note 2 to entry: Semantic concepts can be represented by graph vertices and edges.
3.19
sort
data type
variable
formal notion from algebraic data type theory, which describes sub-data types that can be extended to
many-sorted (i.e. complex) data types comprising multiple sets of data
Note 1 to entry: Sorts are algebraic terms that represent sets of data in a dataspace.
Note 2 to entry: The terms data type and variable are synonymous terms for a sort i.e. a set of data items.
3.20
trust
recognize an asset (something, someone) as being trustworthy in a defined context of use that is of value to
the user
3.21
trustworthiness
ability to meet stakeholders’ expectations in a verifiable way
Note 1 to entry: Depending on the context or sector, and on the specific product or service, data, technology and
process used, different characteristics apply and need verification to ensure stakeholders’ expectations are met.
[7]
[SOURCE: ISO/IEC TS 5723:2022, 3.1.1, modified — Notes 2, 3 and 4 to entry have been deleted.]
3.22
validity
proof of a data provenance proposition in certain circumstances or system states that become valid or
invalid
Note 1 to entry: Semiotic mappings is achieved by defining pairs of semiotic artefacts from the three semiotic domains.
By this view, validity is a kind of “weak correctness proof” based on propositions about relationships between semantic
artefacts (declarative), ontological artefacts (descriptive) and physical artefacts (constructive, phenomenological).
4 Abbreviated terms
AAS asset administration shell
CDDL concise data definition language
DP data provenance
DPIM data provenance information model
DS data secrecy
DTw digital twin
HMI man-machine interface
GDPR general data protection regulation
IoT internet of things
MD metadata
MMI machine-machine interface
ML machine learning
© ISO/IEC 2026 – All rights reserved
NoP narrative of provenance
LC VS life cycle value stream
OT operational technology
PII personally identifiable information
QoD quality of data
PIR provenance, identities, rights
RAM reference architecture model
RM reference model
SF smart factory
SM smart manufacturing
ToI thing(s) of interest
TW trustworthy, trustworthiness
UDT urban digital twin
VS value stream
5 Data provenance methodology
5.1 General assumptions
Figure 1 illustrates a < data, metadata > VS, its production VS, and their dynamic interrelationships. In the
figure, the stakeholder types are represented by rectangles, the corresponding activities manipulating
variables are represented by circles, and the narratives of provenance (NoP) are represented by arrows.
Key
1,2 ., 8 reference numbers of DP activities
A, B, C stakeholder DP categories of provider, intermediary, user
NOTE 1 The letters A, B, and C indicate three stakeholder types.
NOTE 2 Ontological artefacts identified in B of the intermediaries are described in an operational manner.
NOTE 3 The numbers 1 to 8 indicate activities on the upper and lower life cycle value stream (LC VS).
Figure 1 — Life cycle value streams of parallel data and production asset processing

© ISO/IEC 2026 – All rights reserved
The concept of data provenance relies on the following two principles: (a) semantics that is expressed in
[7, 32]
terms of graph artefacts and (b) the physical phenomena that coincide with the derived narratives of
provenance (NoP).
The two principles (a) and (b) are operationalized into 8 activities:
a) Activity 1 and 2: descriptions of the data (key reference 1 of Figure 1) and metadata (key reference 2 of
Figure 1) elements and rules to fit into < data, metadata > pairs;
b) Activity 3: provisioning of required resources (artefacts) for the anticipated asset production processes;
c) Activity 4: cyclic information provisioning from the space of production to the digital data space of
information modelling;
d) Activity 5: observation of LC production VS events and patterns that are of interest to questions of trust;
e) Activity 6: inheritance of data models usually many-sorted data (i.e. multiple sets) and PIR information
from both < data, metadata > VS and production VS to improve quality of production;
f) Activity 7: based on available data manipulation tools, to perform analysis and simulations and if
necessary, provide adjustments to the production processes to synchronize with the data VS models;
g) Activity 8: verification or validation of the expectations of the data user involved in the considered use
case on the production asset (as applied in Annex B and Annex C).
The anticipated value streams (VS) of the production asset life cycle contain not only single data items (i.e.
constants) but also sorted variables that represent sets of data (i.e. data types).
The LC VS model of Figure 1 comprises three basic types of stakeholders.
h) The provider of many-sorted data, metadata and (production) resources is specified by the related
variables md of sort “metadata” and res of sort “resources” (key reference A in Figure 1)
i) The producer of a product asset is specified by variables comprising certificates cert and evidence ev of
sort “dataspace”, or product prod of sort “production space” (key reference B in Figure 1).
j) The product/data user stakeholder is specified by the variables uc of sort “trusted UC” and pr of sort
“trusted product” (key reference C in Figure 1).
The < data, metadata > model changes in the path above (Figure 1) correspond to the changes of the
production process in the path below (Figure 1). The < data, metadata > model trajectory at the end of a
considered LC VS represents the user’s expectations on the trusted product that are semantically comparable
i.e. verifiable with the measured qualities on the trusted product and therefore the corresponding data and
production value streams can be trustworthy.
5.2 Verification and validation principles
Figure 1 shows the basic validation and verification principles (as outlined in Annex B and Annex C) of
deriving trust when using data voluntarily made available that stem from different sources while respecting
their histories of changes and manipulations by inspecting metadata narratives of provenance (NoP) on the
data’s life cycle value stream (LC VS).
The two value streams of Figure 1 (i.e. the upper < data, metadata > and the lower production VS) are
intended to be validated or verified against each other. Then both assets, the < data, metadata > model
and the related product can be trusted (activity 8 in Figure 1). To demonstrate this, the expectations from
the < data, metadata > VS is shown to be fulfilled by the production processes that operate in parallel.
In Figure 1, the < data, metadata > model changes in the path above correspond with the changes of the
production process in the path below. The < data, metadata > model trajectory at the end of a considered LC
VS represents the user’s expectations on the trusted product that are semantically comparable i.e. verifiable
with the measured qualities on the trusted product and therefore the corresponding data and production
value streams can be trustworthy.

© ISO/IEC 2026 – All rights reserved
In the DP methodology represented in Figure 1, authenticity in industrial systems mean that the < data,
metadata > VS is always in relation to the production VS of a thing of interest (ToI) based on operational
[22] [33]
technology. Since, the < data, metadata > tuples VS is twinning the production VS, the corresponding
value streams are isomorphic to each other.
5.3 Value stream semantics
5.3.1 Correspondence between LC value streams
In industrial systems, basically, there are two corresponding value streams the < data, metadata > VS and
the production VS.
In Figure 1, the < data, metadata > VS is the upper stream, starting from the initial < data, metadata > sources
in activities 1 and 2, working through the intermediaries of performing activities 6 and 7 based on acquired
PIR < data, metadata > tuples of measured production qualities, and finally to the expected use cases verified
with the final product in activity 8.
The production VS is the lower stream, also starts from the initial < data, metadata > sources in activities
1 and 2, but is aligned with the production resources that are provided in activity 3. The production VS
then works through the intermediaries of performing activity 5 manufacturing qualities, properties and
capabilities of the resultant asset of a new product. The < data, metadata > tuples information is acquired by
the production VS in activities 4 and 5 and delivered to the upper VS to perform a production analysis or a
simulation for achieving an anticipated high quality of the product.
The production activities provide a proof that the stakeholders’ expectations documented by < data,
metadata > models are achieved on the resulting product asset. This capability is called provability of DP
assertions.
The cyclic process incorporating activities 1 to 7 is a semantic process of generating trust because it
generates various categories of tuple sets of the < provenance, identities, rights > (P, I, R) metadata that
document all activities necessary for the LC VS of production of a product (i.e. the physical asset).
Metadata capturing occurs in all physical processes during the entire LC VS. It is an ongoing task for the
purpose of creating trust for the use or application of data-of-interest that are subscribed from a dataspace.
For example, in production processes, an asset is basically a product together with its data that result from
stakeholders involved in the same LC VS that is generating, operating, manipulating, decommissioning or
refurbishing the compound LC VS of < data, metadata > tuples and production.
When collecting metadata from observations of the production VS (Figure 1, activities 4, 5) and integrating
these derived metadata into NoPs (Figure 1, activities 6, 7) then these NoPs can be used to prove product
authenticity because of the applied isomorphy property.
5.3.2 Value stream behaviour
The three basic interoperating stakeholders (A, B, C) of Figure 1 reside in different infrastructures that
comprise human, digital and physical resources to set up activities of parallel data processing and production
processes. In the various LC VS stages, processes are required to interact in a trustworthy manner by means
of exchange and forwarding new or manipulated data models via specific dataspaces.
Data models can comprise various data types. A data type is many-sorted which means that there can be
[5]
multiple sorts with variables in one many-sorted (i.e. compound) data type. In the application of the asset
[6]
administration shell (AAS), a sort can be a sub-model or in formal terms, a sort can be represented by a
variable. This is also outlined for each stakeholder in Figure 1.
With respect to data provenance inspections to obtain trustworthiness for some data-of-interest, it is
important to note that generally data is an asset that mirrors model behaviour of production assets during
their production or operation as outlined in Figure 1, activities 1 to 7. The VS are described in terms of
sequences of compound < data, metadata > pairs that describe stories of trusted data manipulations
twinning semantically the sequences of production events.

© ISO/IEC 2026 – All rights reserved
However, when data are considered as assets, they can be made accessible by an own asset administration
[6]
shell (AAS) sheltering the data like a physical product. A data-product has value to its provider, creator,
or user when data are used in models such as a production process in all its phases of functional and quality
maturity. The value of a data product is related to its stakeholders’ credibility and market economics of data
users.
5.3.3 Representation of VS semantics
Figure 1 represents the LC VS of the incorporated assets i.e. the generation of an initial data including
metadata specifications during operation and the operational (technical) production asset yielding a
product of a certain quality.
The two value streams of Figure 1 operate in parallel and are referred to as a compound data-product
asset. The presentation of the whole LC in Figure 1 is represented by the three stakeholder categories (key
references A, B, C). In the lower stream (production LC VS), the stakeholders manage and manipulate the
production infrastructure and the resources required for the production, and, in the upper stream ( metadata > VS), the verification of the data model, the management of the dataspace and the data prepared
for use by authenticated third parties and the product user.
The provisioning of resources to a production LC VS, comprising data and metadata is required for
[8]
authentication. The producer can involve data and resources from multiple sources for the VS processes of
production.
The quality of the product to be produced is documented by generating metadata that can comprise trust
certificates, collections of evidence about the integrity, authenticity and confidentiality of the assets (i.e.
data, product or production), and stakeholder identities. This documentation can be used by the customer or
user as the metadata evidence required for proving trust and product authenticity. Based on the metadata
evidence, the customer can prove that the documented metadata NoP of any product apply the isomorphy
property, such that both value streams obey the rules of provability.
Figure 1 shows the isomorphic principle, which means that the collected < data, metadata > tuples are in
all LC VS stages in synchrony with the LC VS stages of the production. This is a formal way of applying
provability to LC VS processes.
NOTE 1 Tuples denominate a collection of heterogeneous items that are packaged due to certain constraints.
Stakeholder A (activities 1 to 3) starts the production with a trusted collection of initial data and resources
that semantically initialize the quality of production to be maintained during all activities of the LC VS.
Stakeholder B (activities 4 to 7) continue the production process showing that LC VS stages, data, and
metadata tuples can be updated and evaluated with respect to the operational production stages of a
product. Vice versa, the production activities can be validated against the data model based on LC VS < data,
metadata > tuples. Formally, data and metadata structures can be instantiated with type graphs that can be
manipulated based on a formal grammar.
Stakeholder C (activity 8) finishes the production by comparing the expectations modelled as use cases or
NoPs with the result of production. In case of isomorphy, the model and product comply.
NOTE 2 The capabilities of data and metadata handling are captured by the concept of a dataspace. Data and
metadata can be combined into tuples which are identifiable by valid proposition and can allow stakeholders to
publish and subscribe specified data and metadata tuples to and from the dataspace.
[8]
NOTE 3 A comparable metadata-based content provenance authentication methodology is specified in C2PA
[14] [26]
technical specifications which comprise a” Concise Data Definition Language (CDDL)” to express binary object
data structures and provide tools to human users, for automated compliance checking, data analysis and security.
NOTE 4 The C2PA manifest is a data structure comprising a so-called claim of a collection of assertions. The claim
is hashed by signature. The assertions contain certain information about data with some hashes to bind them to the
manifest.
© ISO/IEC 2026 – All rights reserved
5.3.4 Continuity aspect of operating products and data
Semantics with respect to data provenance includes LC VS behaviour of a process or system that is
represented by variables that change continuously or discretely over time. In other words, the process
variables range over sets of typed values, formally referred to as “sorts”.
NOTE A process represented by a continuous variable is modelled in terms of graph-theoretical approach
comprising vertices, edges and mappings among vertices. The mapping defines the creation of graph edges in terms
of ordered or unordered pairs of vertices. An ordered pair of vertices is semantically equivalent to an observed event.
An unordered pair is equivalent to a potential event not yet observed i.e. the declaration of an action. The metadata
annotated to the action describes that action by means of ontological artefacts.
The application of production resources require trust in data and resources to be applied or consumed.
Thus, trustworthiness influences the quality of data and production. In a dataspace, trustworthiness can be
derived from metadata annotated to data. Figure 2 illustrates the complexity dependency of quality of data
from the LC VS. The more a data tuple experiences manipulation during the LC VS, the less trust is placed on
the data tuple of interest.
5.3.5 Formal language terms
For the creation of DP metadata, a formal language approach is applied to determine and analyse the
information on data provenance derived from observed data manipulations in a certain LC value stream.
The information contained by the metadata of a thing of interest (ToI) is used by the LC VS stakeholders, to
make decisions on data or product usage.
The approach of data provenance distinguishes between the concepts of metadata comprising information
on data provenance, security, privacy and trust, and formal language terms used for making assertions
about data provenance propositions.
[8]
NOTE The application of propositions in logic depends upon the context of use. For example, in case of capturing
data provenance metadata, a proposition can describe the observation of an event that depends from the binding of all
free variables of the proposition in a certain context.
5.3.6 Processing of trust
Descriptive artefacts of a domain ontology comprise the range of representations from single
data representations to complex knowledge representations, including learned or derived < data,
metadata > tuples based on trusted methods and tools of data provenance information handling and
manipulations.
An example of data provenance value adding based on metadata is shown in Figure 1 by the activities 4
to 7. This cyclic process is called a process of generating trust because it maintains sets of PIR metadata
that document all activities on data and on production of the involved trusted stakeholders, necessary to
produce a physical product asset.
The production documentation by means of NoPs but also the identification of modelling artefacts can be
of value for similar production processes e.g. for use as a blueprint adopting the variables from an existing
environment to a new machinery and production environment. The modification of graph artefact is
achieved by applying a formal graph grammar. Hence, a trusted artefact can be used in different contexts
and is thus of value to stakeholders connected to a trustworthy dataspace.
Provenance metadata comprises of various categories of information about the state of data that is
observable during the LC VS.
The PIR metadata categories comprise:
— data provenance (P) that is derived from the phenomena of physical operation incorporating data along
trajectories of usage;
— digital identities (I) that control the stakeholders requesting access to the data or thing of interest;
— digital rights (R) that control the access to the data or thing of interest (ToI).

© ISO/IEC 2026 – All rights reserved
[4]
The metadata derived during the LC VS describing proces
...