kSIST FprEN ISO 29481-2:2025
(Main)Building information models - Information delivery manual - Part 2: Interaction framework (ISO/FDIS 29481-2:2025)
Building information models - Information delivery manual - Part 2: Interaction framework (ISO/FDIS 29481-2:2025)
This document specifies a methodology for describing and managing interactions and a format for digital communication between actors in any use case associated with the management of an asset during all life cycle stages.
It provides:
— a methodology that describes an interaction framework for a use case;
— an appropriate way to map responsibilities and interactions that provides a process context for information flow;
— a format in which the interaction framework is specified and executed.
This document is intended to promote secure, verifiable, traceable and high-quality digital IDM communication between actors during all phases of the life cycle of assets, facilitate interoperability between software applications used, and to provide a basis for data- and process-driven information exchange and traceability of communication.
Bauwerksinformationsmodelle - Handbuch der Informationslieferungen - Teil 2: Interaktionsframework (ISO/FDIS 29481-2:2025)
Dieses Dokument legt eine Methodik für die Beschreibung und das Management von Interaktionen und ein Format für die digitale Kommunikation zwischen Akteuren in jedem Anwendungsfall in Verbindung mit dem Management eines Assets während aller Lebenszyklusphasen fest.
Es legt fest:
eine Methodik zur Beschreibung eines Interaktionsframeworks für einen Anwendungsfall;
eine geeignete Methode, Verantwortlichkeiten und Interaktionen darzustellen, die einen Prozesskontext für den Informationsfluss zur Verfügung stellt;
ein Format, in dem das Interaktionsframework festgelegt und ausgeführt ist.
Dieses Dokument dient dazu, eine sichere, verifizierbare, nachverfolgbare und hochwertige digitale IDM-Kommunikation zwischen Akteuren während aller Lebenszyklusphasen von Assets zu fördern, die Interoperabilität zwischen verwendeten Software-Anwendungen zu ermöglichen und eine Grundlage für den daten- und prozessorientierten Informationsaustausch und die Nachverfolgbarkeit der Kommunikation zu bieten.
Modèles des informations de la construction - Protocole d’échange d’informations - Partie 2: Cadre d'interaction (ISO/FDIS 29481-2:2025)
Le présent document spécifie une méthodologie pour décrire et gérer les interactions ainsi qu’un format pour la communication numérique entre les acteurs dans tout cas d’usage associé à la gestion d’un actif au cours de toutes les phases de son cycle de vie.
Il fournit:
— une méthodologie qui décrit un cadre d’interaction pour un cas d’usage;
— une manière adaptée de mettre en correspondance les responsabilités et les interactions, qui donne un contexte aux flux d’informations d’un processus;
— un format dans lequel le cadre d’interaction est spécifié et mis en œuvre.
Le présent document a pour objectif de promouvoir une communication IDM numérique sécurisée, vérifiable, traçable et de haute qualité entre les acteurs au cours de toutes les phases du cycle de vie des actifs, de faciliter l’interopérabilité entre les applications logicielles utilisées et de fournir une base pour les échanges d’informations axés sur les données et les processus ainsi que pour la traçabilité de la communication.
Informacijski modeli stavb - Priročnik z informacijami - 2. del: Okvirni podatki o medsebojnem vplivanju (ISO/FDIS 29481-2:2025)
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
oSIST prEN ISO 29481-2:2025
01-marec-2025
Informacijski modeli stavb - Priročnik z informacijami - 2. del: Okvirni podatki o
medsebojnem vplivanju (ISO/DIS 29481-2:2024)
Building information models - Information delivery manual - Part 2: Interaction framework
(ISO/DIS 29481-2:2024)
Bauwerksinformationsmodelle - Handbuch der Informationslieferungen - Teil 2:
Interaktionsframework (ISO/DIS 29481-2:2024)
Modèles des informations de la construction - Protocole d’échange d’informations -
Partie 2: Cadre d'interaction (ISO/DIS 29481-2:2024)
Ta slovenski standard je istoveten z: prEN ISO 29481-2
ICS:
35.240.67 Uporabniške rešitve IT v IT applications in building
gradbeništvu and construction industry
91.010.01 Gradbeništvo na splošno Construction industry in
general
oSIST prEN ISO 29481-2:2025 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
oSIST prEN ISO 29481-2:2025
oSIST prEN ISO 29481-2:2025
DRAFT
International
Standard
ISO/DIS 29481-2
ISO/TC 59/SC 13
Building information models —
Secretariat: SN
Information delivery manual —
Voting begins on:
Part 2: 2024-12-16
Interaction framework
Voting terminates on:
2025-03-10
Modèles des informations de la construction — Protocole
d’échange d’informations —
Partie 2: Cadre d'interaction
ICS: 35.240.67
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENTS AND APPROVAL. IT
IS THEREFORE SUBJECT TO CHANGE
AND MAY NOT BE REFERRED TO AS AN
INTERNATIONAL STANDARD UNTIL
PUBLISHED AS SUCH.
This document is circulated as received from the committee secretariat.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
ISO/CEN PARALLEL PROCESSING
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
NATIONAL REGULATIONS.
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
PROVIDE SUPPORTING DOCUMENTATION.
Reference number
ISO/DIS 29481-2:2024(en)
oSIST prEN ISO 29481-2:2025
DRAFT
ISO/DIS 29481-2:2024(en)
International
Standard
ISO/DIS 29481-2
ISO/TC 59/SC 13
Building information models —
Secretariat: SN
Information delivery manual —
Voting begins on:
Part 2:
Interaction framework
Voting terminates on:
Modèles des informations de la construction — Protocole
d’échange d’informations —
Partie 2: Cadre d'interaction
ICS: 35.240.67
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENTS AND APPROVAL. IT
IS THEREFORE SUBJECT TO CHANGE
AND MAY NOT BE REFERRED TO AS AN
INTERNATIONAL STANDARD UNTIL
PUBLISHED AS SUCH.
This document is circulated as received from the committee secretariat.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
© ISO 2024
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
STANDARDS MAY ON OCCASION HAVE TO
ISO/CEN PARALLEL PROCESSING
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
BE CONSIDERED IN THE LIGHT OF THEIR
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
or ISO’s member body in the country of the requester.
NATIONAL REGULATIONS.
ISO copyright office
RECIPIENTS OF THIS DRAFT ARE INVITED
CP 401 • Ch. de Blandonnet 8
TO SUBMIT, WITH THEIR COMMENTS,
CH-1214 Vernier, Geneva
NOTIFICATION OF ANY RELEVANT PATENT
Phone: +41 22 749 01 11
RIGHTS OF WHICH THEY ARE AWARE AND TO
PROVIDE SUPPORTING DOCUMENTATION.
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland Reference number
ISO/DIS 29481-2:2024(en)
ii
oSIST prEN ISO 29481-2:2025
ISO/DIS 29481-2:2024(en)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
3.1 Terms defined in ISO 29481-1 .1
3.2 Other terms and definitions .3
4 Interaction Framework. 3
4.1 General .3
4.2 Information Management and the interaction framework .4
4.3 Purpose of an Interaction Framework .5
4.4 Hierarchical structure of an interaction framework .6
4.4.1 Roles .6
4.4.2 Transactions .7
4.4.3 Messages .8
4.4.4 Complex and Simple Elements.9
4.5 Establishing a Digital IDM communication Project .10
4.5.1 Modelling the interaction framework .10
4.5.2 Creating and using the interaction framework schema .11
4.5.3 Using a project specific message to link people to roles .11
4.5.4 Executing digital IDM communication . 12
4.5.5 Validating digital IDM communication . 13
4.5.6 Signing messages with advanced electronic signatures . 13
4.5.7 Changing the project during execution .14
4.5.8 Archiving digital IDM communication.14
5 Schemas for validating interaction frameworks and messages .15
5.1 Introduction . 15
5.1.1 Basic principles .16
5.1.2 Element types in the interaction framework schema and _2 EXPRESS source file .16
5.1.3 Introduction .16
5.1.4 Primary element types .18
5.1.5 Secondary element types .27
5.1.6 References . 30
5.2 Element types in the interaction message schema and the _5 EXPRESS source file .37
5.2.1 Introduction .37
5.2.2 Primary element types . 38
5.2.3 Secondary element types .43
5.2.4 References .45
Annex A (normative) Interaction framework schema definition .52
Annex B (normative) Templates definition .53
Annex C (informative) Promotor algorithm .54
Annex D (informative) Example interaction framework XML of a simplified design office use
case .55
Annex E (informative) Example project specific message XML of a simplified design office use
case .72
Annex F (informative) Example message XML of a simplified design office use case .79
Bibliography .90
iii
oSIST prEN ISO 29481-2:2025
ISO/DIS 29481-2:2024(en)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
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 ISO documents 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).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes 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 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. ISO 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.
This document was prepared by Technical Committee ISO/TC 59, Buildings and civil engineering works,
Subcommittee SC 13, Organization and digitization of information about buildings and civil engineering works,
including building information modelling (BIM).
ISO 29481 consists of the following parts, under the general title Building information models — Information
delivery manual:
— Part 1: Methodology and format
— Part 2: Interaction framework
— Part 3: Data Schema
This second edition cancels and replaces the first edition (ISO 29481-2:2012) and introduces updates that
better integrate the interaction framework within the concept of digital IDM communication. It also aligns
terminology and practices with the latest in the IDM series and other related standards
iv
oSIST prEN ISO 29481-2:2025
ISO/DIS 29481-2:2024(en)
Introduction
Collaboration between the participants involved during the lifecycle of built assets is pivotal to the efficient
delivery and operation of assets. Organizations collaborate within specific use cases to achieve higher levels
of quality and greater re-use of existing knowledge, information experience and resources. A significant
condition of collaboration is the opportunity to communicate, re-use and share information efficiently, and
to reduce the risk of loss, contradiction or misinterpretation.
The information delivery manual (IDM) series provides significant assistance in making the most of
information management. If the necessary information is available at the right time, the quality of the
information is satisfactory and the right person is involved at the right time, the collaboration and outcome
itself is greatly improved. Management and coordination of the parties involved depend on communication,
therefore it shall be well structured, unambiguous, explicit and prompt. For this to happen, there must be
a common understanding of the purpose, the processes, the actors involved and the required information.
This document focuses on the foundations for and execution of digital communication in accordance with
the processes and information requirements of a use case. With a sharp focus on communication, this
part of ISO 29481 offers a natural complement to standards that focus on information management such
as ISO 19650, information containers such as ISO 21597 and information modeling, such as ISO 16739 and
ISO 10303-239.
This document describes how to use various components of an Information Delivery Manual (IDM) for
verifiable and traceable execution of digital communication. The resulting interaction framework enables
standardization of digital communication in construction processes within any collaboration, both within
and between organizations. It is applicable during the complete lifecycle of built assets and construction
projects of all sizes and all levels of complexity. It provides a standard format that IT solutions may use.
Supporting this standard in various ICT solutions means that various information management systems are
connected. By doing so, it provides a basis for reliable information exchange and sharing for users, so that
they can be confident that the information they send or receive is accurate and sufficient for the coordination
activities they need to perform. This provides a basis for using Common Data Environment (CDE) solutions
and workflows.
v
oSIST prEN ISO 29481-2:2025
oSIST prEN ISO 29481-2:2025
DRAFT International Standard ISO/DIS 29481-2:2024(en)
Building information models — Information delivery
manual —
Part 2:
Interaction framework
1 Scope
Document specifies a methodology for describing and managing interactions and a format for digital
communication between actors in any use case associated with the management of an asset during all life
cycle stages.
It therefore specifies
— a methodology that describes an interaction framework for a use case;
— an appropriate way to map responsibilities and interactions that provides a process context for
information flow;
— a format in which the interaction framework should be specified and executed.
This document is intended to promote secure, verifiable, traceable and high-quality digital IDM
communication between actors during all phases of the lifecycle of built assets, facilitate interoperability
between software applications used, and to provide a basis for data- and process driven information
exchange and traceability of communication.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO 29481-1, Building information modelling — Information delivery manual — Part 1: Methodology and format
ISO 29481-3, Building information models — Information delivery manual — Part 3: Data schema
ISO 10303-11, Industrial automation systems and integration — Product data representation and exchange —
Part 11: Description methods: The EXPRESS language reference manual
ISO 40210, Information technology — W3C SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)
3 Terms and definitions
3.1 Terms defined in ISO 29481-1
For the purposes of this document, the following terms defined in ISO 29481-1 apply.
3.1.1
asset
item, thing or entity that has potential or actual value to an organization
[SOURCE: ISO 55000:2024, 3.1.1, modified - The notes to entry have been removed.]
oSIST prEN ISO 29481-2:2025
ISO/DIS 29481-2:2024(en)
3.1.2
use case
description of a process by defining a sequence of actions performed by one or more roles to realize a purpose
Note 1 to entry: a use case specifies the scope of the business context.
[SOURCE: ISO 24014-1:2021, 3.36, modified - the word "actor" has been replaced with "role". The words" and
by the system itself" has been replaced with "to realize a purpose". The note to entry has been added.]
3.1.3
business context
environment in which actors undertake processes
Note 1 to entry: Such an environment includes all the roles, activities, and interactions, products and services under
the actor's control.
Note 2 to entry: the business context always contains one or more business processes
3.1.4
business process
set of interrelated or interacting activities that use inputs to deliver an intended result
EXAMPLE Examples results include: agreements, systems, services, or products.
Note 1 to entry: a business process always contains one or more transactions.
[SOURCE: ISO 9000:2015, 3.4.1, modified - The notes to entry have been replaced with a note to entry. An
example has been added.]
3.1.5
information delivery manual
IDM
specification of a use case using business context maps and exchange requirements
Note 1 to entry: Use case, business context maps, and exchange requirements may be collectively referred to as IDM
components.
3.1.6
interaction map
business context map of the interactions related to a use case
3.1.7
information exchange
act of satisfying an information requirement or part thereof
[SOURCE: ISO 19650-1:2018, 3.3.7]
3.1.8
interaction
communicative action between two roles
3.1.9
transaction
sequence of interactions involving the exchange of information using messages
EXAMPLE processing of a request by one role on behalf of another
Note 1 to entry: a transaction is a message between the initiator and the executor.
oSIST prEN ISO 29481-2:2025
ISO/DIS 29481-2:2024(en)
3.1.10
role
functions being performed by an actor at a point in time
Note 1 to entry: The role of an actor is determined by action and outcome and not necessarily by the profession or
trade followed by the actor.
3.1.11
message
information prepared for communication purposes
[SOURCE: ISO 5127:2017, 3.1.8.02]
3.2 Other terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.2.1
digital IDM communication
exchange of messages within the confines of a use case enabled by an interaction framework and project
specific message
3.2.2
interaction framework
XML file for the elements of an interaction
Note 1 to entry: Elements of an interaction include roles, transactions, messages, and information units
3.2.3
interaction framework schema
XML schema definition file that the interaction framework shall comply with
3.2.4
project specific message
PSM
message placing the interaction framework in the context of a project and links people to organizations and roles
3.2.5
interaction message schema
XML schema definition file that the messages shall comply with
3.2.6
promotor
algorithm that generates an interaction framework schema from an interaction framework, with the support
of a template definition used as input
3.2.7
templates definition
file containing a number of templates, independent of the specific interaction framework, for generating an
interaction framework schema and an interaction message schema
4 Interaction Framework
4.1 General
This Clause explains the core concepts and principles for the development and use of an Interaction
Framework for digital IDM communication. By following the methodology presented in this document users
of software tools are able to model (in a machine interpretable XML file) the business context and exchange
requirements of a specified use case and subsequently start to digitally communicate with each other based
on that interaction framework.
oSIST prEN ISO 29481-2:2025
ISO/DIS 29481-2:2024(en)
4.2 Information Management and the interaction framework
Information management involves defining, producing, checking, and delivering information. Every team
member in any business activity interacts with information management to some extent. The importance
of documented responsibility and accountability in information management is crucial, because focusing
on good information management leads to better project outcomes. To be effective, there shall be a shared
understanding of the processes and the necessary information in each step for their execution.
An IDM captures the business context associated with a use case and defines a detailed specification of
the information that a user fulfilling a particular role would need to provide at a particular stage within a
business process in order to create a product or deliver a service.
Generally speaking, a use case involves delivering goods or providing services to people or institutions.
These people and institutions are called the use case customers or clients. As soon as a customer or client
requests the delivery of a batch of goods or the provision of a service, a chain of activities is set in motion to
fulfil that request. Such a chain of activities is called a business context.
This leads to the basic framework of an IDM as illustrated in Figure 1. Each use case has an associated
business context and information requirements.
Figure 1 — IDM Basic framework
The business context is usually represented in an IDM by any combination of interaction maps and process
maps, supported by textual representations. The analysis of the business context may be thought of as
oSIST prEN ISO 29481-2:2025
ISO/DIS 29481-2:2024(en)
a discovery process using those two mapping approaches since their purpose is to clearly show how the
information exchange requirements for the use case have been derived.
An exchange requirement provides a description of the information to be exchanged between roles in plain
language terms to support a particular business process in the relevant life cycle stage (within a business
context). An exchange requirement may support either (or both) the communication of information essential
to the design, construction, operation and deconstruction of an asset or it may support the communication
of management information with messages that control project execution in relation to the life cycle
management of the asset.
To deliver a service or produce a product within a use case, people perform various activities. Taken in their
entirety, these form the business context. Often, within the business context there are chains of activities that
provide sub products or services, these are called business processes. At certain points in time, information
is needed by an actor to fulfil their task, or it is part of their responsibility to deliver specific information.
When this information is transferred from one actor to another, an interaction occurs. The receiving actor
determines if the information is complete and correct.
An information exchange therefore is never a single activity, it is a (digital) conversation between two actors
in order to satisfy a specific information requirement.
This document focuses on formally structuring, recording and supporting these interactions and their
requirements to achieve an outcome. This is known as performative communication.
4.3 Purpose of an Interaction Framework
The interaction framework is the core of digital IDM communication. It is a formal technical XML description
that includes all elements necessary for interactions within use cases, such as roles, transactions, messages
in transactions, and data elements in messages. The scope of an interaction framework aligns with the scope
of a use case in an Information Delivery Manual (IDM).
Creating an interaction framework not only allows the identification of detailed information exchange
requirements, but also facilitates (through compatible software) verifiable and traceable digital IDM
communication between participants during all phases of the lifecycle of built assets. When properly set up,
an interaction framework forms the foundation for software tools to enable users to communicate digitally
and purposefully through messages based on the processes, roles, exchange requirements, and information
defined by the IDM. Digital IDM communication through an interaction framework enables better process
control, improved data management, increased transparency, enhanced verifiability of agreements, and a
higher quality of the final product. A software tool utilizing an interaction framework structures, monitors,
and stores communication by providing a shared digital communication archive. It clarifies responsibilities
and decisions promptly, keeps project archives up-to-date and complete, facilitates faster and more flexible
partnerships, and prevents miscommunication.
Since the process and content resides in the machine-readable interaction framework rather than being
embedded in a software tool, a software solution implementing this method can support and improve
collaboration of any use case without specialised software.
It also ensures interoperability between software tools that support this document, facilitating seamless
messaging between applications. Every organization may freely choose their software tools that implements
the interaction framework, ensuring secure messaging between them. This guarantees each party complete
access to mutual communication through their own chosen software while shielding internal communication
from the collaborating partners.
The basic principles, terms and concepts of the modelling of interactions that this document uses are based
1)
on DEMO (Design and Engineering Methodology for Organizations). DEMO is a method for analysing
1) DEMO originated from science (Maastricht University, Delft University of Technology) and builds on various theories
including systems theory (Simon, 1962), philosophy of language (Austin, 1962 and Searle, 1968), communicative action
(Habermas, 1986), data modeling (Nijsen and Halpin, 1989) and ontologies (Guizzardi, 2005). In collaboration with
universities in Antwerp (Belgium), Duisburg (Germany), Bolzano (Italy), Luxembourg, Vienna (Austria), Lisbon and
Madeira (Portugal), Prague (Czech Republic), St. Gallen (Switzerland), San Jose (USA) and Tokyo (Japan), DEMO-4 was
released in 2020. DEMO is managed by the Enterprise Engineering Institute.
oSIST prEN ISO 29481-2:2025
ISO/DIS 29481-2:2024(en)
and (re)designing organizations, in which human action is central. DEMO describes the structure of an
organization, abstracted from the implementation. It describes what happens or should happen rather than
how it happens. The focus is on the essence of an organization: WHAT the organization does, not HOW it
does it. A DEMO model describes a partnership, either within an organization and across organizations. A
DEMO model forms a consistent set of products, responsibilities, processes, information and business rules
and gives an overview of, and insight into, organizations. It
4.4 Hierarchical structure of an interaction framework
An interaction framework incorporates all necessary digital interactions and roles to realize the purpose of
a use case. Figure 2 illustrates the hierarchy of definitions within this document. Each transaction defines
a sequence of messages exchanged between two roles. A message is a digital form, including possible
attachments, comprising data elements, which are categorized as complex and simple elements. The
behaviour of simple elements is determined by its’ user defined type and element conditions.
Figure 2 — Interaction framework with the hierarchy of its components
4.4.1 Roles
When defining a use case, roles are assigned to responsibilities and tasks, not specific functions or positions
within an organisation. This is because the same roles consistently appear in business contexts, but
individuals in different functions or positions may fulfil multiple roles or switch between them. For example,
actors may fulfil roles such as 'initiator', 'client', 'builder', or 'designer'. The name of the role is derived from
its primary activity, emphasizing the role's contribution within transactions.
A key principle is that people with roles act and negotiate with authority and responsibility. Only people
can make agreements, take decisions, pass judgments, and enter into contracts. Roles therefor have to fulfil
certain qualifications.
There is not always a one-to-one relationship between actors and roles. In some business processes, one
actor may assume multiple roles, while in others, several actors may share the same role. For instance, a
municipality could be both the initiator and the client, or a contractor for earthworks and an installation
company might both take on the role of builder. An actor may also fulfil different roles across different
business processes.
oSIST prEN ISO 29481-2:2025
ISO/DIS 29481-2:2024(en)
Every interaction framework includes defined roles to streamline responsibilities and tasks. This approach
ensures clear and effective collaboration, providing a structured method to manage various functions
efficiently within the business activity. Roles may also be reassigned if project members leave, and
authorizations may be granted so others may take over their work. The audit trail always remains intact,
allowing visibility about who did what and when.
4.4.2 Transactions
Each interaction framework consists of one or more transactions, this is defined by the use case and the
associated business context. In an interaction framework a transaction is a sequence of messages between
two roles. As shown in Figure 3, each transaction has an initiator (the role that starts the transaction) and
an executor (the role that carries out the transaction).
Figure 3 — A transaction always involves only two roles
Using transactions within information management brings information transfer into a process context. This
ensures that information is exchanged systematically and purposefully within a structured digital process.
Organizations using an interaction framework transition from document-driven to data-driven workflows
by digitally managed information and processes.
4.4.2.1 Business process scenarios and sub transactions
Depending on the business context and use case, an interaction framework may contain one or several
transactions. Within the business context sometimes multiple transactions between roles are required in
sequence to achieve a goal. For example, when a role in transaction A prepares information that another role
in transaction B shall review. In such cases, transactions need to be linked, forming a workflow known as a
business process scenario.
In a business process scenario, there is always a main transaction where the initial request is made linked to
one or more sub transactions. Sub transactions are designed to cascade from the main transaction. This is
detailed in Clause 5.2.2.10.
4.4.2.2 Interaction map
2)
All necessary roles, transactions and sub transactions of a use case are described by the interaction map in
an Information Delivery Manual (IDM). This is an abstract representation that defines the boundary of a use
case and highlights the essential communication chain required to fulfil its purpose. The name is derived
from the fact that it records the interaction between the actors, i.e. their direct mutual influence. It leaves out
all the activities and various process steps. The use of abstract roles makes the interaction map applicable
to various situations. Figure 4 shows a simplified example of an interaction map for a design office use case.
2) In DEMO terms the Interaction Map is called an Organization Construction Diagram (OCD), but for clarity purposes
within the architecture, engineering and construction industry a different term is introduced by this document.
oSIST prEN ISO 29481-2:2025
ISO/DIS 29481-2:2024(en)
Figure 4 — Example of an interaction map of a design office use case
All roles and transactions in the interaction map have a unique identity and name, with numbering being
arbitrary. Roles are named based on their primary activities, emphasizing their contributions to the use
case. A composite role consists of multiple roles, but its composition is not relevant to the use case's scope.
4.4.2.3 Transaction product table
Each transaction has an intended result, also referred to as the product of that transaction. Together with
the transactions and roles described by the interaction map, this can be summarized in a transaction
product table. This table records the transaction kind (the name and unique number of each transaction),
the product kind (the product of each transaction) and its initiating and executing roles. See table 1 for an
example.
Table 1 — Transaction product table of a simplified design office use case
Product kind Transaction kind Initiator role Executor role
Design is delivered T , Deliver design CR Client R Project leading
1 1 1
System specification is deliv- T , Deliver system specifica- R Project leading R System engineering
2 1 2
ered tion
3D model is delivered T , Deliver 3D model R Project leading R 3D engineering
3 1 3
Cost calculation is delivered T , Deliver cost calculation R Project leading R Cost engineering
4 1 4
4.4.3 Messages
To realize the product of a transaction, interactions take place between two roles. In the digital world, these
interactions are performed by means of digital messages. A transaction contains a set of messages that are
exchanged for a specific purpose. The transaction also specifies the participating roles, the point in the
lifecycle, and the sequence in which messages should be delivered (if applicable).
In terms of the IDM methodology, messages may carry information units and attachments that satisfy
exchange requirements. Attachments may be of any type, including structured information containers such
as IFC files or Information Containers (ICDD) and unstructured information containers such as documents,
spreadsheets, pictures, video files and drawings. The interaction Framework message also supports the
inclusion of metadata, such as version number, document date, and status. For certain message types, it may
oSIST prEN ISO 29481-2:2025
ISO/DIS 29481-2:2024(en)
be mandated that at least one attachment shall be added, and specific attachment types may be enforced by
the interaction framework.
4.4.3.1 Sequence of messages
Sets of messages in a transaction form a chain with a beginning and an end. Most process diagrams provide
a "happy flow”, the best case scenario of communicative actions where both actors fulfil their role without
dispute. However, in practice, processes rarely follow this ideal flow because humans can make mistakes so
all possible outcomes should be considered, such as the need for adjustments or scenarios where a model is
not approved.
For example, a transaction involving a request for a 3D model (see Figure 5) illustrates a message sequence
in a transaction as a sequence diagram in UML notation. The transaction is initiated by R1 Project Leader
with the message 'Request for 3D model.' The 3D engineer (role R3) responds with 'Work done and request
for approval.' After a message 'Work approved' or 'Work not approved,' the transaction is completed.
The start message has no preceding message, being the only way to distinguish it from the other messages.
Similarly, the final message has no following message. Each message has a direction indicated by the labelled
arrow. A message may have several previous messages, e.g. a message approval may follow a delivery, but
also a renewed delivery. Similarly, the final message has both a reject and an approval as the previous
messages. Therefore, the chain of messages is not linear, but rather a mathematical graph.
Figure 5 — Example of messages in a transaction
4.4.4 Complex and Simple Elements
A message is essentially a 'form' with data fields and attachments where required. Each message has
a header with details of the involved roles and the date and time the message was sent. The body of the
message includes the information to be transferred, such as: text fields, dates, amounts, Yes/No, list boxes,
and tables. During digital IDM communication the data in the fields is stored in the database of the software
that executes it.
Each data field in a message is called a “Simple Element”, which is always part of a group called a “Complex
Element”. Each Complex Element may contain one or more Simple Elements. Simple Elements may be made
mandatory or optional for users to fill in within a message. Each message shall contain at least one Complex
oSIST prEN ISO 29481-2:2025
ISO/DIS 29481-2:2024(en)
Element with at least one Simple Element, although a Simple Element may be empty. To create a table a
Complex Element needs to be nested within another Complex Element.
The behaviour, restrictions (for example minimum length) and validation of Simple Elements are determined
by their UserDefinedType. During digital IDM communication inheritance takes place. In principle, data
entered in a Simple Element in a previous message will be sent in a subsequent message, unless a so-called
Element Condition has been included in the interaction framework.
See Figure 6 for an example of Complex and Simple Elements in the message “Proposal request for change.”
Figure 6 — Example of Complex and Simple Elements within a message
There is no rule about which data fields should be included in a message and which data should be in
attachments created with other software tools. Depending on the level of detail needed for communicative
decision-making, traceability and datamining purposes of the use case an interaction framework designer
can decide to include or exclude data elements.
NOTE Camel case terms in this document denote XML definitions.
4.5 Establishing a Digital IDM communication Project
After the use case and the associated business context and exchange requirements are analysed, a digital
IDM communication project can be set up. The scope of a digital IDM communication project equals the
scope of the associated use case. The term project is explicitly not seen here as a construction term (e.g. the
execution of a construction project), but as a generic term in which users can collaborate on a specific task.
A software tool that works according to this document can support multiple projects, each containing an
active interaction framework. Each project has a version history containing an active, as well as any possible
previous interaction frameworks that were added, for example when a transaction was added, or the content
of a message was changed. To avoid technical and legal problems, a transaction is always processed in the
version of the interaction
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.