ISO/DTS 7817-2

• Abstract:

  This document defines how level of information need can be implemented in projects and programmes. It further clarifies how to state the prerequisites, as defined in Part 1 (EN 17412-1, ISO 7817-1) and then elaborates a methodology on how to specify information requirements for geometrical information, alphanumerical information and documentation, in line with the concepts and principles from Part 1. Part 2 includes various examples and diagrams to help the information receiver understand the extent of their requirements specification, mainly using plain-language and a series of decision trees. This is illustrated with examples from building and infrastructure projects and is not limited by classification systems, software tools, exchange formats or data schemas. It also provides a few tabular templates, which help expressing the level of information need using traditional text and spreadsheet formats, in line with current industry practice. However, the ambition is to present the requirements in a structured way, allowing to specify the level of information need consistently across the international market. The structured approach will form the basis to develop a machine-interpretable exchange data schema to capture level of information need specifications, which is the subject of Part 3 of the standard. In addition, Part 2 describes suggestions and approaches for defining a nomenclature and it expands on verification and validation aspects as defined in Part 1. Part 2 supports the verification and validation of information deliverables against the information requirements expressed in the level of information need. Validation against design requirements, building code, regulations or building programme are not the scope of Part 2. Also, information model exchange and related data exchange formats are not within scope. Finally, Part 2 relates the level of information need to the elaboration of Exchange Information Requirements (EIR), BIM Execution Plan (BEP) according to ISO 19650 and explains how it relates to ISO 29481 Information Delivery Manual (IDM) and ISO 16739-1 Industry Foundation Classes (IFC).

• Status: Not Published
• ICS: 35.240.67 - IT applications in building and construction industry
• ICS: 91.010.01 - Construction industry in general
• Technical Committee: ISO/TC 59/SC 13 - Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM)
• Drafting Committee: ISO/TC 59/SC 13 - Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM)
• Current Stage: 5020 - FDIS ballot initiated: 2 months. Proof sent to secretariat
• Start Date: 17-Sep-2026
• Completion Date: 17-Sep-2026

• Consolidates: ISO 20752:2023 - Cork stoppers — Determination of releasable 2,4,6-trichloroanisol (TCA)
• Effective Date: 29-Jun-2024

Overview

ISO/DTS 7817-2: Building information modelling - Level of information need - Part 2: Guidance for application is an international standard developed by ISO for the building and civil engineering sector. This document describes best practices and methodologies for specifying the level of information need (LoIN) in building information modelling (BIM) projects and programmes. It builds upon the concepts and principles established in ISO 7817-1, providing a structured, plain-language approach to defining information requirements. This standard is applicable across the entire asset life cycle and supports a consistent, repeatable way to communicate information requirements, benefiting all parties involved in BIM-enabled projects.

Key Topics

• Specification of Prerequisites: The standard clarifies how to define prerequisites such as project purpose, key milestones, responsible actors, and object breakdown structures. Understanding and agreeing on these is essential before specifying information needs.
• Information Requirements: ISO/DTS 7817-2 offers guidance on stating requirements for three major types of information:
  • Geometrical information: Methodologies for expressing the detail, dimensionality (0D–3D), location, appearance, and parametric behavior of objects.
  • Alphanumerical information: Approaches to specifying identification, properties, and data attributes using standardized templates and data dictionaries.
  • Documentation: Guidance on the types and level of supporting documentation to accompany the BIM data.
• Structured Templates: The document provides tabular templates and examples for expressing LoIN, ensuring requirements can be easily communicated and documented in text or spreadsheet formats.
• Verification and Validation: It expands on approaches for verifying and validating information deliverables against the specified requirements, as introduced in Part 1.
• Independence from Tools: The methodology is intentionally not tied to any specific classification system, software tool, exchange format, or data schema. This promotes broad applicability and supports international harmonization.

Applications

Implementing ISO/DTS 7817-2 offers practical value for a wide array of building and infrastructure projects. Typical applications include:

• Asset Lifecycle Management: Supports LoIN specification from strategic planning to design, construction, operation, maintenance, refurbishment, and end-of-life stages.
• Consistent Information Exchange: Facilitates repeatable, clear communication of BIM information requirements among owners, designers, contractors, specialists, and regulators.
• International Collaboration: Promotes harmonized practices across markets and organizations, reducing confusion and inefficiency, particularly on multi-national projects.
• Contractual Clarity: Serves as a reference for establishing information exchange requirements between appointing and appointed parties, supporting compliance with ISO 19650 and other BIM-related frameworks.
• Digital Workflows: Provides the baseline for digital and machine-interpretable information requirement specifications, paving the way for adoption of advanced information management practices, digital twins, and interoperability.

Related Standards

ISO/DTS 7817-2 is part of a broader family of international standards that support information management in the built environment:

• ISO 7817-1: Building information modelling - Level of information need - Part 1: Concepts and principles
• EN 17412-1: Provides European guidance on LoIN concepts
• ISO 19650 Series: Organization and digitization of information about buildings and civil engineering works, including information management using BIM
• ISO 29481 (IDM): Information Delivery Manual for exchange requirements
• ISO 16739-1 (IFC): Industry Foundation Classes for data exchange
• ISO 23386 / 23387: Data dictionaries and templates for BIM attributes and object properties
• ISO/DIS 7817-3: (In development) Focuses on establishing a machine-interpretable data schema for LoIN

Conclusion

ISO/DTS 7817-2 provides vital guidance for specifying the level of information need in BIM projects, ensuring clarity, consistency, and efficiency in digital information management. Adopting this standard supports industry best practices, streamlines collaboration, and enhances the quality of information throughout the asset lifecycle. For any organization engaging in BIM-based workflows or seeking alignment to international standards, ISO/DTS 7817-2 is an essential resource.

FINAL DRAFT
Technical
Specification
ISO/TC 59/SC 13
Building information modelling —
Secretariat: SN
Level of information need —
Voting begins on:
2026-09-17
Part 2:
Guidance for application
Voting terminates on:
2026-12-10
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 SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/CEN PARALLEL PROCESSING LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Reference number
FINAL DRAFT
Technical
Specification
ISO/TC 59/SC 13
Building information modelling —
Secretariat: SN
Level of information need —
Voting begins on:
Part 2:
Guidance for application
Voting terminates on:
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 SUPPOR TING DOCUMENTATION.
© ISO 2026
IN ADDITION TO THEIR EVALUATION AS
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/CEN PARALLEL PROCESSING
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
or ISO’s member body in the country of the requester.
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland Reference number
ii
Contents Page
Foreword .vi
Introduction .vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 General . 3
5 How to specify the prerequisites for the level of information need . 5
5.1 General .5
5.2 Consider the purpose(s) .5
5.3 Consider the information delivery milestone(s) .6
5.3.1 General .6
5.3.2 Program delivery of milestones .6
5.4 Consider the actor(s) .7
5.4.1 General .7
5.4.2 Actor .8
5.4.3 Consider the objects within a breakdown structure .9
5.4.4 Specifying a breakdown structure .9
5.4.5 Requirements inheritance across the breakdown structure .10
5.4.6 Multiple requirement assignment .10
5.5 Consolidation or aggregation of requirements by shared prerequisites .11
6 How to specify geometrical information .13
6.1 General . 13
6.2 Assemblies of objects and their representation .14
7 Geometrical information: specifying required detail . 14
7.1 General .14
7.2 Object assembly into shapes. 15
7.3 Specify the outer shell of the object representation .16
7.3.1 General .16
7.3.2 Outer shell represented by bounding primitive .17
7.3.3 Outer shell represented by a single shape .19
7.3.4 Outer shell is represented by a set of shapes . 20
7.3.5 Indicating a threshold extent for outer shell (optional) .21
7.4 Specify shape connections .21
7.4.1 General .21
7.4.2 No connections are included in the shape . 22
7.4.3 The shape of the object is altered to represent connections. 23
7.4.4 Connection represented as separate shapes in the object . 25
7.4.5 Connection represented as separate objects in the breakdown structure . 25
7.4.6 Indicating a threshold extent for connections (optional) . 26
7.5 Specify operating zones and clearance geometry . 26
7.5.1 General . 26
7.5.2 No operating or clearance zone(s) are required .27
7.5.3 Representation includes operating or clearance zone(s) .27
7.5.4 Indicating a threshold extent for operation or clearance zones (optional) . 28
7.6 Specify openings in the outer shell of a shape . 29
7.6.1 General . 29
7.6.2 No openings or penetrations are included . 29
7.6.3 Openings are included . 29
7.6.4 Indicating a threshold extent for openings (optional) .31
7.6.5 Considerations on the management of openings as separate objects .31
7.7 Specify inside geometry .31
7.7.1 General .31

iii
7.7.2 Inside geometry is not required .32
7.7.3 Inside geometry as part of the shape .32
7.7.4 Inside geometry as separate shapes . 33
7.7.5 Inside geometry as separate objects in the breakdown structure . 33
7.7.6 Indicating a threshold extent for inside geometry (optional) . 33
7.8 Specify features . 34
7.8.1 General . 34
7.8.2 No features are required . 34
7.8.3 Features are included as part of the shape . 35
7.8.4 Features are included as separate shapes of the same object . 36
7.8.5 Features are included as separate objects in the breakdown structure . 36
7.8.6 Indicating a threshold extent for features (optional) .37
7.8.7 General advice and relation to manufacturer objects .37
8 Specifying the dimensionality of the geometric representation .38
8.1 General . 38
8.2 0D — Zero dimensional . 38
8.3 1D — One dimensional . 39
8.4 2D — Two dimensional .41
8.5 3D — Three- dimensional .43
8.6 Considerations and recommendations . 44
9 Location .44
9.1 General . 44
9.2 Absolute location .45
9.3 Relative location . 46
9.3.1 General . 46
9.3.2 Specifying relative locations of objects. 46
10 Appearance . 47
10.1 General .47
10.2 Appearance is not applicable . 48
10.3 Appearance is symbolic or mapped (not based on material) . 49
10.4 Appearance is defined by material . 50
10.4.1 General . 50
10.4.2 Appearance defined by singular or multiple materials . 50
10.4.3 Photo-realistic appearance .51
10.5 Methods to describe appearance . 53
10.6 Appearance versus alphanumeric information or documentation . 53
11 Parametric behaviour .54
12 Placeholders for geometrical information .56
12.1 General . 56
12.2 Detail . 56
12.3 Dimensionality . 56
12.4 Location .57
13 Alphanumerical information .57
13.1 General .57
13.2 Identification . 58
13.3 Information content . 58
13.4 Combining identification and information content for disambiguation .59
13.5 Relation to other initiatives related to requirement specifications . 60
13.5.1 General . 60
13.5.2 Information delivery specification . 60
13.5.3 Shapes constraint language. 60
13.5.4 Data dictionaries .61
13.5.5 Data templates .61
13.5.6 Information delivery manual and exchange requirements .61
14 Documentation . 61

iv
15 Verification and validation .63
15.1 General . 63
15.2 Verification of the information delivery . 64
15.3 Validation of the information delivery . 64
15.4 Relation with the assessment of the design and construction specifications . 64
Annex A (informative) Example of specifying the level of information need .65
Bibliography .72

v
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), in collaboration with the European Committee
for Standardization (CEN) Technical Committee CEN/TC 442, Building Information Modelling (BIM), in
accordance with the Agreement on technical cooperation between ISO and CEN (Vienna Agreement).
A list of all parts in the ISO 7817 series can be found on the ISO website.
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.

vi
Introduction
This document provides technical specifications and guidance on the specification of the level of information
need, following the concepts and principles from ISO 7817-1.
Having good quality information is the foundation for information management and the application of other
methodologies and technologies, such as digital twins, artificial intelligence and the digital product passport.
The level of information need provides a framework for defining relevant information requirements.
Internationally there are several guidance documents, specifications, national standards and templates that
have been published on similar concepts to the level of information need. However, they are not mutually
aligned, creating confusion and difficulty in operating across the international market.
In addition, the material available so far often generates misunderstanding of the concept, leading to
discussions and conflicts in projects and programmes (including legal claims, delays and increase of costs).
This document supports the built environment sector in using a consistent approach to adopt the level of
information need and optimize the information exchange in projects and programmes, avoiding a lack of
information or the waste of information production, or both.
The guidance contained in this document is aimed at all those involved in the asset life cycle. These
include, but are not limited to, the asset owner/operator, the client, the asset manager, the design team, the
construction team, an equipment manufacturer, a technical specialist, a regulatory authority, an investor, an
insurer and an end-user.
vii
FINAL DRAFT Technical Specification ISO/DTS 7817-2:2026(en)
Building information modelling — Level of information
need —
Part 2:
Guidance for application
1 Scope
This document provides guidance for the application of the level of information need in projects and
programmes. It further clarifies how to state the prerequisites and then elaborates a methodology on
how to specify information requirements for geometrical information, alphanumerical information and
documentation, in line with the concepts and principles from ISO 7817-1. This document includes various
examples and diagrams to help the information receiver in defining the level of information need framework.
This is illustrated with examples from building and infrastructure projects and considering the variety
of classification systems, software tools, exchange formats and data schemas. The guidance supports a
structured approach to support a machine-interpretable data schema to capture the level of information
1)
need, which is the subject of ISO 7817-3 .
In addition, this document expands on verification and validation aspects as defined in ISO 7817-1. This
document supports the verification and validation of information deliverables against the information
requirements expressed in the level of information need.
This document is applicable to the whole life cycle of any asset, including strategic planning, initial
design, engineering, development, documentation and construction, day-to-day operation, maintenance,
refurbishment, repair and end-of-life.
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 7817-1, Building information modelling — Level of information need — Part 1: Concepts and principles
ISO 6707-1, Buildings and civil engineering works — Vocabulary — Part 1: General terms
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 7817-1, ISO 6707-1 and the
following 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/
1) Under preparation. Stage at the time of publication: ISO/DIS 7817-3:2026.

3.1
graphical symbol
visually perceptible figure with a particular meaning used to transmit information independently of
language
[SOURCE: ISO 17724:2026, 3.9]
3.2
zero-dimensional
0D
geometry having or seeming to have no dimensions
Note 1 to entry: A graphical symbol (3.1) is typically represented as zero-dimensional.
EXAMPLE A point in space.
3.3
one-dimensional
1D
geometry having or seeming to have one dimension
Note 1 to entry: Some objects can be represented only by a spline without representing its diameter.
EXAMPLE Vectors and lines.
3.4
two-dimensional
2D
geometry having or seeming to have two dimensions
EXAMPLE An object with height and width.
[SOURCE: ISO 6707-2:2017, 3.2.10, modified — The domain of geometry has been applied. The word
“drawing” has been removed. The words “such as width and height and no depth” have been removed and
moved into an example. The Note to entry has been removed.]
3.5
three-dimensional
3D
geometry having or seeming to have three dimensions
Note 1 to entry: Three-dimensional element could be used to specify a mass in 3D coordinate system.
EXAMPLE An object with height, width and depth.
[SOURCE: ISO 6707-2:2017, 3.2.11, modified — The domain of geometry has been applied. The word “drawing”
has been removed. The words “length, width and depth” have been replaced with “three dimensions” and
moved into an example. The Note to entry has been replaced.]
3.6
geometric representation
set of shapes (3.7) which represent an object
EXAMPLE Examples include points, curves, surfaces, volumes.
3.7
shape
mathematical generic description defining the ideal geometry of an object
EXAMPLE Planar shape, cylindrical shape, spherical shape, conical shape.
[SOURCE: ISO 17450-1:2011, 3.3.1.1.4, modified — “(of an ideal feature)” has been replaced with “object”. The
NOTE and EXAMPLE 2 have been removed.]

3.8
placeholder
object which is inserted at, or near, the place where another object is planned to be located
Note 1 to entry: Placeholders are used to recognize objects, but their geometry is not directly related to the object;
their size, dimension, detail, dimensionality or appearance may be different.
3.9
outer shell
boundary that represents the extent of an object
Note 1 to entry: An outer shell is the smallest enclosure or hull of a representation. Outer shells can be convex or
concave.
3.10
bounding primitive
outer shell (3.9) which is defined by a single geometric primitive
Note 1 to entry: Geometric primitives are non-decomposed objects that present information about generic
configuration. They include point, curves, surfaces and solids.
EXAMPLE Shapes such as a box, rectangle, sphere, circle or cylinder.
3.11
feature
local geometric configuration belonging to a shape (3.7)
Note 1 to entry: Features bring the representation of an object closer to the physical/real-world object.
Note 2 to entry: Features can add or remove a part of the shape.
EXAMPLE Typical features are fillets (rounded corners), chamfered edges/corners, but also protrusions, holes or
other geometry which alters the shape of the object.
[SOURCE: ISO 10303-108:2005, 3.7.17, modified — The words “product” and “description, having significance
in some application context associated with the product model” have been removed. Notes 1 and 2 to entry
and an EXAMPLE have been added.]
3.12
actor
person, organization or organizational unit involved in a process or project
[SOURCE: ISO 29481-1:2025, 3.1.1, modified — The word “business” has been replaced with “project”.]
4 General
As explained in ISO 7817-1, to be able to specify the level of information need for an information delivery, the
information receiver first states the prerequisites which give context to the requirement.
When the prerequisites have been stated, the information receiver further specifies the different
requirements expressed as a combination of required geometrical information, alphanumerical information
and documentation. Depending on the chosen prerequisites, some or all the required aspects may be
omitted.
This process is repeated for all considered prerequisites and is compiled into the level of information need
specification for the project or programme. This specification can be compiled into a shareable specification,
following the level of information need data model and schema of ISO 7817-3.
The methodology of specifying the level of information need can be applied in the formal context of an
appointment between appointing and appointed parties, as defined in ISO 19650-1, but also in an informal

context of specifying the level of information need between other project partners, regardless of any
contractual agreement or formal appointment being in place.
EXAMPLE When a structural engineer requires information from the mechanical engineer, they can specify such
requirements using the same level of information need specification methodology, as applied by the appointing party
when specifying requirements from the different appointed delivery teams.
Finally, the methodology supports both human and machine-readable specification of the level of information
need. This document focuses on how to specify the level of information need, whereas ISO 7817-3 introduces
a data model and schema to enable digital exchange of such specification and its integration in digital
workflows and tools. Examples specifying the level of information need are provided in Annex A.
Figure 1 explains the process to specify the level of information need and relates it to a series of possible
reference standards or reference documents, including international or local guidelines, classification
systems and data dictionaries. The prerequisites include the purpose, information delivery milestones,
actors and objects as identified in ISO 7817-1. The purpose can be identified using ISO 2948-1 and/or
national guidelines. The information delivery milestone can be identified using ISO 22263, ISO 2948 series,
plan of works and/or national guidelines. The actor can be identified using ISO 19650 series and/or roles
and functions defined at national level. The objects identified in the breakdown structure can be identified
using ISO 12006-2, ISO 16739-1 and/or other classification systems. The alphanumerical information can be
specified by using properties and data templates included in data dictionaries as defined in ISO 23386 and
ISO 23387. The level of information need can be compiled in a machine-interpretable data model and schema
as defined in ISO 7817-3 that considers the requirements of ISO 23386 and ISO 23387 for the definition of
the alphanumerical information.
Figure 1 — How to specify the level of information need framework and its relations to other
standards
5 How to specify the prerequisites for the level of information need
5.1 General
As stated in ISO 7817-1, before the level of information need can be specified, different possible prerequisites
are to be considered: purpose, information delivery milestone, actors (both requesting and delivering) and
the breakdown structures used to organize the considered objects.
The prerequisites can be based upon existing standards and guidelines and when preparing the level of
information need specification, they can be referred to, either using an agreed label or using a reference.
EXAMPLE A reference can be expressed using a unique resource identifier (URI).
It should be clear for the receiving actor which sources are applied when stating the prerequisites, so further
information and context can be queried when needed.
NOTE This document does not define the prerequisites but uses examples to which the specifier can refer.
5.2 Consider the purpose(s)
The purpose defines the context of why information is required. Without stating the purpose, requirements
may appear arbitrary and lack a justification for proper delivery. In addition, the purpose defines the
intended use of information.
EXAMPLE 1 When information is required for the purpose of energy analysis, the information provider is
responsible for submitting information suitable for that specific purpose. If the information receiver is using the
information for other purposes, such as cost estimation, the information provider is usually not responsible of possible
errors or misinterpretations.
NOTE 1 The purpose is sometimes referred to as a use case or an information use which can be applied following
ISO 29481-1 (information delivery manual – IDM).
Purposes can have different scopes in relation to the appointment. Both high-level purposes and more
specific purposes or sub-purposes can be identified.
EXAMPLE 2 The high-level purpose “facility management” can include different sub-purposes as “asset tracking”
and “building inspection”.
Purposes can be stated in different ways, but the information receiver should consider standardized
references, including international, national, or portfolio/project-specific purpose references. Using
standardized purposes enables repeatability within the same project and across projects, as well as across
companies and markets.
NOTE 2 International or national organizations can collect common purposes which can be referred to, often
applying a label or a number.
If no generally agreed standard purposes are deemed relevant for the project, the information receiver
should provide a custom set of purposes using a unique identifier.
It is recommended to assign a unique identifier (ID) to each purpose.
The purpose can be defined using the data model outlined in ISO 7817-3. It can include name, definition,
reference document, description, dictionary, language of creator and country of origin.
EXAMPLE 3 A unique identifier can have numerical digits from 0000 to 9999 or a mix of letters and numbers, such
as AA00.
NOTE 3 According to the ISO 19650 series, the information requirements cover different purposes such as
organizational purpose, asset purpose and project purpose. When purposes have a unique identifier, it becomes
straightforward to identify different purposes and the associated level of information need in the information
requirements according to the ISO 19650 series.

Table 1 presents a possible set of metadata to describe each purpose. By defining a unique identifier, each
purpose can be easily referred to across the level of information need specification.
NOTE 4 In a machine-interpretable approach, using a unique resource identifier (URI) or a uniform resource locator
(URL) reference is more suitable, than using a table. The use of URI/URL is further defined in ISO 7817-3.
Table 1 — Example of a set of metadata related to the purpose
Unique identifier Name Description Reference
(ID)
Short code or Short title Description of the purpose Source reference or link to additional infor-
label mation documenting the purpose.
The purpose is a prerequisite. It is independent from the level of information need (geometrical information,
alphanumerical information and documentation) definition. It is advised to avoid using guidelines that mix
prerequisites (e.g. for “design intent”, “construction-level coordination”, or “shop drawings”) with the level
of information need definition.
5.3 Consider the information delivery milestone(s)
5.3.1 General
Aligning a need for information to a project timeline is suggested to ensure the required information is
prepared and supplied at the appropriate time. Following ISO 19650-2, information delivery milestones
can be inferred by the project information requirements (PIR) and the related master and task information
delivery plans (MIDP/TIDP).
Potential for information to change as a project progress negates any perceived benefit in providing
information other than that needed; more information is not always better. Multiple delivery schedule
timelines exist within a project, from high level milestones defining contracted deliverables through to
specific discipline design requirements. These timelines relate to either the needs of the overall project or
individual disciplines, or actors having a requirement to progress the maturity of the delivery of information.
The level of information need is to be defined and requested to a timeline that allows the information to be
created, checked and issued in readiness to be used by those requesting.
It is recommended to assign a unique identifier (ID) to each information delivery milestone.
The information delivery milestone can be defined using the data model outlined in ISO 7817-3. It can include
name, description, reference document and date.
5.3.2 Program delivery of milestones
Project or program milestones identify key information requirements associated to specific dates within
the overall project or program where the level of information need is specified for legal or functional
requirements.
EXAMPLE 1 An environmental impact assessment (EIA) report is often identified as a key milestone in the delivery
of a design and construction project. The EIA sets a baseline to establish legal requirements within the design and
project delivery process; information defined for the EIA can influence other design criteria. The information required
for a milestone delivery can be provided by multiple disciplines with the possibility that these disciplines are at
different design phases
...

ISO/TC 59/SC 13
Secretariat: SN
Building Information Modellinginformation modelling — Level of
information need —
Part 2:
Guidance for application
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication
may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying,
or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO
at the address below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: + 41 22 749 01 11
E-mail: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
Contents
Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 General . 4
5 How to specify the prerequisites for the level of information need . 6
5.1 General . 6
5.2 Consider the purpose(s) . 6
5.3 Consider the information delivery milestone(s) . 7
5.4 Consider the actor(s) . 10
5.5 Consolidation or aggregation of requirements by shared prerequisites . 14
6 How to specify geometrical information . 16
6.1 General . 16
6.2 Assemblies of objects and their representation . 17
7 Geometrical information: specifying required detail . 18
7.1 General . 18
7.2 Object assembly into shapes . 18
7.3 Specify the outer shell of the object representation . 21
7.4 Specify shape connections . 28
7.5 Specify operating zones and clearance geometry . 34
7.6 Specify openings in the outer shell of a shape . 38
7.7 Specify inside geometry . 42
7.8 Specify features . 45
8 Specifying the dimensionality of the geometric representation . 51
8.1 General . 51
8.2 0D — Zero dimensional . 51
8.3 1D — One dimensional . 53
8.4 2D — Two dimensional . 56
8.5 3D — Three- dimensional . 58
8.6 Considerations and recommendations . 59
9 Location . 60
9.1 General . 60
9.2 Absolute location . 61
9.3 Relative location . 63
10 Appearance . 64
10.1 General . 64
10.2 Appearance is not applicable. 66
10.3 Appearance is symbolic or mapped (not based on material) . 66
10.4 Appearance is defined by material . 68
10.5 Methods to describe appearance. 70
10.6 Appearance versus alphanumeric information or documentation . 71
11 Parametric behaviour . 71
12 Placeholders for geometrical information . 73
12.1 General . 73
12.2 Detail . 74
iii
12.3 Dimensionality . 74
12.4 Location . 75
13 Alphanumerical information . 76
13.1 General . 76
13.2 Identification . 76
13.3 Information content . 77
13.4 Combining identification and information content for disambiguation . 78
13.5 Relation to other initiatives related to requirement specifications . 79
14 Documentation . 81
15 Verification and validation . 82
15.1 General . 82
15.2 Verification of the information delivery . 83
15.3 Validation of the information delivery . 83
15.4 Relation with the assessment of the design and construction specifications . 83
Annex A (informative) Example of specifying the level of information need . 84
Bibliography . 92

iv
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), in collaboration with the European Committee for
Standardization (CEN) Technical Committee CEN/TC 442, Building Information Modelling (BIM), in
accordance with the Agreement on technical cooperation between ISO and CEN (Vienna Agreement).
A list of all parts in the ISO 7817 series can be found on the ISO website.
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.
v
Introduction
This document provides a technical specificationspecifications and guidance on the specification of the level
of information need, following the concepts and principles from ISO 7817-1.
Having good quality information is the foundation for information management and the application of other
methodologies and technologies, such as digital twins, artificial intelligence and the digital product passport.
The level of information need provides a framework for defining relevant information requirements.
Internationally there are several guidance documents, specifications, national standards, and templates that
have been published on similar concepts to the level of information need. However, they are not mutually
aligned, creating confusion and difficulty in operating across the international market.
In addition, the material available so far often generates misunderstanding of the concept, leading to
discussions and conflicts in projects and programmes (including legal claims, delays and increase of costs).
This document supports the built environment sector in using a consistent approach in adoptingto adopt the
level of information need and optimize the information exchange in projects and programmes, avoiding a lack
and/orof information or the waste of information production, or both.
The guidance contained in this document is aimed at all those involved in the asset life cycle. These include,
but are not limited to, the asset owner/operator, the client, the asset manager, the design team, the
construction team, an equipment manufacturer, a technical specialist, a regulatory authority, an investor, an
insurer and an end-user.
vi
Building information modelling — Level of information need —
Part 2:
Guidance for application
1 Scope
This document provides a guidance for the application of the level of information need in projects and
programmes. It further clarifies how to state the prerequisites and then elaborates a methodology on how to
specify information requirements for geometrical information, alphanumerical information and
documentation, in line with the concepts and principles from ISO 7817-1. This document includes various
examples and diagrams to help the information receiver in defining the level of information need framework.
This is illustrated with examples from building and infrastructure projects, and considering the variety of
classification systems, software tools, exchange formats and data schemas. The guidance supports a
structured approach to support a machine-interpretable data schema to capture the level of information need,
1)
which is the subject of ISO/DIS 7817-3. .
In addition, this document expands on verification and validation aspects as defined in ISO 7817-1. This
document supports the verification and validation of information deliverables against the information
requirements expressed in the level of information need.
This document is applicable to the whole life cycle of any asset, including strategic planning, initial design,
engineering, development, documentation and construction, day-to-day operation, maintenance,
refurbishment, repair and end-of-life.
2 Normative references
There are no normative references in this document.
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 7817-1, Building information modelling — Level of information need — Part 1: Concepts and principles
ISO 6707-1, Buildings and civil engineering works — Vocabulary — Part 1: General terms
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 7817-1, ISO 6707-1, and the
following 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

1)
Under preparation. Stage at the time of publication: ISO/DIS 7817-3:2026.

3.1
dimension
measurable extent
[SOURCE: ISO 6707-1:2020, 3.7.2.1]
— 3.2IEC Electropedia: available at https://www.electropedia.org/
3.1
graphical symbol
visually perceptible figure with a particular meaning used to transmit information independently of language
[SOURCE: ISO 17724:2026, 3.9]
3.2 3.3
zero-dimensional
0D
geometry having or seeming to have no dimensions (3.1)
Note 1 to entry: A graphical symbol (3.1(3.2)) is typically represented as zero-dimensional.
EXAMPLE : A point in space.
3.3 3.4
one-dimensional
1D
geometry having or seeming to have one dimension (3.1)
Note 1 to entry: Some objects can be represented only by a spline without representing its diameter.
EXAMPLE: Vectors and lines.
3.4 3.5
two-dimensional
2D
geometry having or seeming to have two dimensions (3.1)
EXAMPLE: An object with height and width.
[SOURCE: ISO 6707-2:2017, 3.2.10, modified. — The domain of geometry has been applied. The word
"“drawing"” has been removed. The words "“such as width and height and no depth"” have been removed and
formed into an example. The words “such as width and height and no depth” have been moved into an
example. The noteNote to entry has been removed.]
3.5 3.6
three-dimensional
3D
geometry having or seeming to have three dimensions (3.1)
Note 1 to entry: Three-dimensional element could be used to specify a mass in 3D coordinate system.
EXAMPLE: An object with height, width, and depth.
[SOURCE: ISO 6707-2:2017, 3.2.11, modified. — The domain of geometry has been applied. The word
"“drawing"” has been removed. The words "“length, width and depth"” have been replaced with "“three
dimensions"” and formedmoved into an example. The noteNote to entry has been removedreplaced.]
3.6 3.7
geometric representation
set of shapes (3.7(3.8)) which represent an object
EXAMPLE: Examples include points, curves, surfaces, volumes.
3.7 3.8
shape
mathematical generic description defining the ideal geometry of an object
EXAMPLE: Planar shape, cylindrical shape, spherical shape, conical shape.
[SOURCE: ISO 17450-1:2011, 3.3.1.1.4 – “, modified — “(of an ideal feature”)” has been replaced with “object”,”.
The NOTE and EXAMPLE 2 have been removed “Note to entry”].]
3.8 3.9
placeholder
object which is inserted at, or near, the place where another object is planned to be located
Note 1 to entry: Placeholders are used to recognize objects, but their geometry is not directly related to the object; their
size, dimension, detail, dimensionality, or appearance may be different.
3.9 3.10
outer shell
boundary that represents the extent of an object
Note 1 to entry: An outer shell is the smallest enclosure or hull of a representation. Outer shells can be convex or concave.
3.10 3.11
bounding primitive
outer shell (3.9(3.10)) which is defined by a single geometric primitive
Note 1 to entry: Geometric primitives are non-decomposed objects that present information about generic configuration.
They include point, curves, surfaces and solids.
EXAMPLE: Shapes such as a box, rectangle, sphere, circle, or cylinder.
3.11 3.12
feature
local geometric configuration belonging to a shape (3.7(3.9))
Note 1 to entry: Features bring the representation of an object closer to the physical/real-world object.
Note 2 to entry: Features can add or remove a part of the shape.
EXAMPLE: Typical features are fillets (rounded corners), chamfered edges/corners, but also protrusions, holes or
other geometry which alters the shape of the object.
[SOURCE: ISO 10303-108:2005, 3.7.17, modified – — The wordwords “product” was removed, removed,and
“description, having significance in some application context associated with the product model”]” have been
removed. Notes 1 and 2 to entry and an EXAMPLE have been added.]
3.12 3.13
actor
Personperson, organization or organizational unit involved in a process or project
[SOURCE: ISO 29481:2015-1:2025, 3.1.1, modified – — The wordsword “business process” have” has been
replaced with “processproject”.]
4 General
As explained in ISO 7817-1, to be able to specify the level of information need for an information delivery, the
information receiver first states the prerequisites which give context to the requirement.
When the prerequisites have been stated, the information receiver further specifies the different requirements
expressed as a combination of required geometrical information, alphanumerical information, and
documentation. Depending on the chosen prerequisites, some or all the required aspects may be omitted.
This process is repeated for all considered prerequisites and is compiled into the level of information need
specification for the project or programme. This specification can be compiled into a shareable specification,
following the level of information need data model and schema of ISO/DIS 7817-3.
The methodology of specifying the level of information need can be applied in the formal context of an
appointment between appointing and appointed parties, as defined in ISO 19650-1, but also in an informal
context of specifying the level of information need between other project partners, regardless of any
contractual agreement or formal appointment being in place.
EXAMPLE When a structural engineer requires information from the mechanical engineer, they can specify such
requirements using the same level of information need specification methodology, as applied by the appointing party
when specifying requirements from the different appointed delivery teams.
Finally, the methodology supports both human and machine-readable specification of the level of information
need. This document focuses on how to specify the level of information need, whereas ISO/DIS 7817-3
introduces a data model and schema to enable digital exchange of such specification and its integration in
digital workflows and tools. Examples specifying the level of information need are provided in Annex A.
Figure 1 explains the process to specify the level of information need and relates it to a series of possible
reference standards or reference documents, including international or local guidelines, classification systems
and data dictionaries. The prerequisites include the purpose, information delivery milestones, actors and
objects as identified in ISO 7817-1. The purpose can be identified using ISO 2948-1 and/or national guidelines.
The information delivery milestone can be identified using ISO 22263, ISO 2948 series, plan of works and/or
national guidelines. The actor can be identified using ISO 19650 series and/or roles and functions defined at
national level. The objects identified in the breakdown structure can be identified using ISO 12006-2, ISO
16739-1 and/or other classification systems. The alphanumerical information can be specified by using
properties and data templates included in data dictionaries as defined in ISO 23386 and ISO 23387. The level
of information need can be compiled in a machine-interpretable data model and schema as defined in ISO/DIS
7817-3 that considers the requirements of ISO 23386 and ISO 23387 for the definition of the alphanumerical
information.
Figure 1 — How to specify the level of information need framework and its relations to other
standards
5 How to specify the prerequisites for the level of information need
5.1 General
As stated in ISO 7817-1, before the level of information need can be specified, different possible prerequisites
are to be considered: purpose, information delivery milestone, actors (both requesting and delivering) and
the breakdown structures used to organiseorganize the considered objects.
The prerequisites can be based upon existing standards and guidelines and when preparing the level of
information need specification, they can be referred to, either using an agreed label or using a reference.
EXAMPLE A reference can be expressed using a unique resource identifier (URI).
It should be clear for the receiving actor which sources are applied when stating the prerequisites, so further
information and context can be queried when needed.
NOTE This document does not define the prerequisites but uses examples to which the specifier can refer.
5.2 Consider the purpose(s)
The purpose defines the context of why information is required. Without stating the purpose, requirements
may appear arbitrary and lack a justification for proper delivery. In addition, the purpose defines the intended
use of information.
EXAMPLE 1 When information is required for the purpose of energy analysis, the information provider is responsible
to submitfor submitting information suitable for that specific purpose. If the information receiver is using the information
for other purposes, such as cost estimation, the information provider is usually not responsible of possible errors or
misinterpretations.
NOTE 1 The purpose is sometimes referred to as a use case or an information use which can be applied following ISO
29481-1 (information delivery manual -– IDM).
Purposes can have different scopes in relation to the appointment. Both high-level purposes and more specific
purposes or sub-purposes can be identified.
EXAMPLE 2 The high-level purpose “facility management” can include different sub-purposes as “asset tracking” and
“building inspection”.
Purposes can be stated in different ways, but the information receiver should consider standardized
references, including international, national, or portfolio/project-specific purpose references. Using
standardized purposes enables repeatability within the same project and across projects, as well as across
companies and markets.
NOTE 2 International or national organizations can collect common purposes which can be referred to, often applying
a label or a number.
If no generally agreed standard purposes are deemed relevant for the project, the information receiver should
provide a custom set of purposes using a unique identifier.
It is recommended to assign a unique identifier (ID) to each purpose.
The purpose can be defined using the data model outlined in ISO/DIS 7817-3. It can include name, definition,
reference document, description, dictionary, language of creator, and country of origin.
EXAMPLE 3 A unique identifier can have numerical digits from 0000 to 9999 or a mix of letters and numbers, such as
AA00.
NOTE 3 According to the ISO 19650 series, the information requirements cover different purposes such as
organizational purpose, asset purpose and project purpose. When purposes have a unique identifier, it becomes
straightforward to identify different purposes and the associated level of information need in the information
requirements according to the ISO 19650 series.
Table 1 presents a possible set of metadata to describe each purpose. By defining a unique identifier, each
purpose can be easily referred to across the level of information need specification.
NOTE 4 In a machine-interpretable approach, using a unique resource identifier (URI) or a uniform resource locator
(URL) reference is more suitable, than using a table. The use of URI/URL is further defined in ISO/DIS 7817-3.
Table: 1 — Example of a set of metadata related to the purpose
Unique Name Description Reference
identifier
(ID)
Short code or Short title Description of the purpose Source reference or link to additional
label information documenting the purpose.
The purpose is a prerequisite. It is independent from the level of information need (geometrical information,
alphanumerical information and documentation) definition. It is advised to avoid using guidelines that mix
prerequisites (e.g. for “design intent”, “construction-level coordination”, or “shop drawings”) with the level of
information need definition.
5.3 Consider the information delivery milestone(s)
5.3.1 General
Aligning a need for information to a project timeline is essentialsuggested to ensure the required information
is prepared and supplied at the appropriate time. Following ISO 19650-2, information delivery milestones can
be inferred by the project information requirements (PIR) and the related master and task information
delivery plans (MIDP/TIDP).
Potential for information to change as a project progress negates any perceived benefit in providing
information other than that needed,; more information is not always better. Multiple delivery schedule
timelines exist within a project, from high level milestones defining contracted deliverables through to specific
discipline design requirements. These timelines relate to either the needs of the overall project or individual
disciplines, or actors having a requirement to progress the maturity of the delivery of information.
The level of information need is to be defined and requested to a timeline that allows the information to be
created, checked, and issued in readiness to be used by those requesting.
It is recommended to assign a unique identifier (ID) to each information delivery milestone.
The information delivery milestone can be defined using the data model outlined in ISO/DIS 7817-3. It can
include name, description, reference document, and date.
5.3.2 Program delivery of milestones
Project or program milestones identify key information requirements associated to specific dates within the
overall project or program where the level of information need is specified for legal or functional
requirements.
EXAMPLE 1 An environmental impact assessment (EIA) report is often identified as a key milestone in the delivery of
a design and construction project. The EIA sets a baseline to establish legal requirements within the design and project
delivery process; information defined for the EIA can influence other design criteria. The information required for a
milestone delivery can be provided by multiple disciplines with the possibility that these disciplines are at different
design phases relative to the project timeline of this EIA milestone (see Figure 2). The creation of the EIA is a final design
deliverable for the environmental team defined by a project timeline, but the drainage design team who are information
providers for water drainage and flood management are at a preliminary design stage and the operations team who are
information providers for environmental asset monitoring and management are at briefing stage.

Brief Design Delivery Utilise

D1 – Environmental team A – Project milestone
D2 – Alignment team B – Need for information
D3 – Drainage team C – Information provider / actor(s)
D4 – Operations team M1 – M6 - Milestones
Key
D1 environmental team
D2 alignment team
D3 drainage team
D4 operations team
A project milestone
B need for information
C information provider/ actor(s)
M1 – M6 milestones
brief
design
delivery
utilize
Figure - 2 — Requirements from multiple disciplines to satisfy information needs for a project
milestone
This need for information is expected to evolve as the project progresses, although the potential for needs to
be reducesreduced should not be ignored either.
EXAMPLE 2 At the design stage, a need can exist for the geometry of an asset to be displayed as a 3D volume. Later in
the project at operation stage, this need can reduce to a lower detail or dimensionality.
A need for information aligns towith ISO 19650-1 which identifies that only the information required at a
particular milestone should be collected, no more or no less.
When considering scheduling the delivery of information needs, there is a requirement for the information to
be available to satisfy the earliest common need/ or requirement, where the same information is required at
later milestones.
5.4 Consider the actor(s)
5.4.1 General
In the context of requesting and delivering information, the level of information need should be used to discuss
and agree on the information delivery between actors.
Actors in a level of information need framework are those that have an interest, an input, or a use for
meaningful data. Actors should be suitably qualified or competent for the roles that they are undertaking.
According to ISO 19650-4, actors may provide information, receive information or review information.
Usually, the level of information need is shared within a transaction between two actors.
In addition to providing, receiving or reviewing information, an actor may also be an information requestor.
It is conceivable that anAn actor couldcan engage in a singular information-related activity or any combination
of request, provide, receive,requesting, providing, receiving and review ofreviewing information.
EXAMPLE 1 A main contractor can provide information (1) to a sub-contractor to allow the sub-contractor to carry
out construction works (see Figure 3Figure 3).).

Figure 3 — Example of singular information related activity
EXAMPLE 2 A main contractor can request information (1) from an architect to clarify a brief, receive information (2)
and then review the information (3) before providing the information (4) to a sub-contractor (see Figure 4Figure 4).).
Figure 4 — Example of multiple information related activity
Information The information provider, receiver and reviewer are described in ISO 19650-4. All these
information-related activities require a trigger to begin the process (see Figure 5). The trigger wouldcan be
the request for information from the information requestor.
The linked image cannot be displayed. The file may have been moved, renamed, or deleted. Verify that the link points to the correct file and location.

Figure 5 — Example linear information flow
It is recommended to assign a unique identifier (ID) to each actor.
The actor can be defined using the data model outlined in ISO /DIS 7817-3. It can include role, description,
address (e-mail), first, middle, last names, and affiliation.
5.4.2 Actor
The built environment sector has many and varied actors, differing between countries or local regions.
When the level of information need is specified, all appropriate actors who request, provide, receive and
review the information should be considered.
Project activities are allocated as tasks to actors.
EXAMPLE In a construction project, actors usually carry out different roles and can be positioned across any of the
information related activities as shown in Table 2.
NOTE 1 Countries or local regions can have their own terms and classifications for actors and project phases.
NOTE 2 ISO 22263:2008, Annex A gives examples of activities within a construction process
Table: 2 — Information activity and actor roles using the example of a topographical survey
ISO 22263 Stagestage Requestor Provider Receiver Reviewer
Inception Client  General
contractor
Example: within the identification of needs, the client requests a survey
Brief General  Surveyor Client
contractor
Example: the general contractor requests the survey information. The surveyor receives the request and actions the
information production. The client conducts a review to confirm the inception of the level of information need is
satisfied
Design For this example, design is not required
Production General Surveyor Surveyor Civil engineer
contractor
Example: The surveyor carries out the survey at the request of the general contractor. The civil engineer reviews the
provided information aligns with the information requirements of the client
Demolition For this example, demolition is not required
5.4.3 Consider the objects within a breakdown structure
To clearly define the scope of an information requirement, the actor requesting an information delivery
referrefers to the applicable object, identified within a relevant breakdown structure. It is recommended that
the chosen breakdown structure is applied consistently across the project, for all information requirement
specifications.
NOTE Objects in the breakdown structure represent an object type, thus representing all objects with shared
characteristics: doors instead of one singular door. Throughout this document, requirements related to an object are
considered to be applicable to all objects which share its type.
It is recommended to use ISO 23387 to define the data templates for describing the characteristics of objects.
The object can be defined using the data model outlined in ISO/DIS 7817-3.
5.4.4 Specifying a breakdown structure
The information standard, as part of the exchange information requirements (EIR), should be considered to
specify relevant breakdown structures in relation to the appointing party. Multiple breakdown structures may
be selected, depending on their scope or purpose.
Alternative or complementary breakdown structures can be included in the amendments to the information
standard, by the different appointed delivery teams in the project.
It is recommended to refer to national or international standardized breakdown structures, when available
and applicable to the project.
EXAMPLE 1 A structural engineer requests that the architectcan providearchitect provides an initial architectural
model which includes slabs, columns, and beams, by identifying them as IfcSlab, IfcColumn, and IfcBeam within the
ISO 16739-1 schema (industry foundation classes - (IFC),)), used as the breakdown structure.
Preference should be given to a breakdown structure based on a classification structure which adheres to
ISO 12006-2.
EXAMPLE 2 An asset manager requests the Mechanical Electrical Plumbingmechanical electrical plumbing (MEP)
contractor to deliver the as-built model with all objects identified with their class code following the European Technical
Information Model (ETIM) classification system.
5.4.5 Requirements inheritance across the breakdown structure
Due to the often-hierarchic nature of objects in a breakdown structure, the specification of information
requirements linked to such objectobjects implies that the requirement also pertains to objects deeper in the
breakdown structure: requirements are to be understood as being inherited across the breakdown structure
(Figure 6). This helps to limit the amount of requirement assignments the information receiver needs to
formulate.
Figure 6 — Requirement inheritance in a breakdown structure
EXAMPLE When a requirement is defined for all doors in the project, it can be assigned to the generic door type or
class in the breakdown structure. Consequently, the requirement is inherited to specific door types, such as fire doors or
exit/ or entrance doors as well, without requiring the information receiver to repeat the requirement explicitly.
It is recommended to specify requirements at the highest possible level in the breakdown structure. This way,
the total amount of requirement statements can be minimized. Only supplementary requirements need to be
formulated for the derived object classes.
NOTE It is easier to add the requirement for an asset code and a product name to all managed assets at once, rather
than having to repeat that requirement for each asset type separately.
As an added benefit, routines which verify information requirements can be configured with a smaller set of
rules if they can be assigned to a top-level object in the breakdown structure.
5.4.6 Multiple requirement assignment
Requirements can also be applied repeatedly, for different objects in the breakdown structure which cannot
be directed to a single ancestor object type or class. Instead of having to repeat or copy-paste the requirement
for multiple objects, the requirement can be referenced by multiple objects in the breakdown structure,
allowing a so-called many-to-many relationship: the same requirement can be assigned to different objects,
and multiple requirements can be assigned to the same object (Figure 7).

Figure 7 — Multiple assignments of a requirement
EXAMPLE An agreed numbering convention needs to be applied to doors, windows, spaces, and all mechanical
assets which require maintenance. However, the common ancestor class for these objects also inherits many other classes
which don’t require this number, such as columns or walls. Here the user can limit the reference to just the set of
applicable objects from the breakdown structure.
5.5 Consolidation or aggregation of requirements by shared prerequisites
Information requirements are accumulative and become a federated information need when they are
combined or consolidated. Aggregation can be considered based on shared or related purposes, milestones,
actors, or objects in the breakdown structure.
EXAMPLE Multiple receiving actors can have similar or complementary requirements, providing an opportunity to
collect them into a single set of requirements, to be delivered by the actor providing the information.
NOTE 1 As shown in Figure 8, it can be beneficial to label requirements to maintain a reference to individual
requirements from the different actors.
Figure 8 — Requirement consolidation by actor
Similarly, requirements are commonly consolidated by information delivery milestone, to avoid fragmenting
the information delivery.
Alongside the possibility to consolidate information requests from different actors, there
...