Regulatory Information Requirements

All dokuments are licensed as a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License
(Attribution-Non-Commercial-ShareAlike 4.0). Further information can be found at

creativecommons

The documents reflect the current best practice and do not claim to be complete. They should not to be understood in the sense of a generally valid recommendation or guideline from a legal point of view. The documents are intended to support appointing and appointed parties in the application of the BIM method. The documents must be adapted to the specific project requirements in each case. The examples listed do not claim to be complete. Its information is based on findings from practical experience and is accordingly to be understood as best practice and not universally applicable. Since we are in a phase in which definitions are only emerging, the publisher cannot guarantee the correctness of individual contents.

Regulatory Information Requirements is a set of recommendations for the identification of elements and properties that are :

1. relevant to Building.
2. international in their applicability
   • no properties specific to a region or country have been included
3. relevant to
   • general identification and location
   • life safety including fire and access,
   • performance including environmental
4. not excluded on technical grounds
   • already present in IFC4.3 ISO16739-1:2024 (but included in IDS) 
   • deducible from the geometry of one or more entities expected in a CV IFC model
     • no assumptions have been collated about the level of geometric development needed
   • deducible by exploring relationships expected in a CV IFC model
     • including counts and summaries
   • regulating the submission, review, commissioning or operational processes
   • uses a cross-reference to
     • other laws, regulations, standards or certifications (handled separately)
     • tables or diagrams
     • document or library references

The recommendations are available:

1. as a Use Case IDM including an IDS file summarising the expectations. The IDS is intended for localisation, by the addition or removal of clauses. 
2. properties and user defined types in the bsDD under the context ’buildingSMART Regulatory Information Requirements’

The RIR project began in 2022 and was given formal approval in Jan 2023. The RIR project was conducted from 2022-2024. It completed in May 2024.  The recommendations reflect the submissions offered at that time.

Appreciation is expressed to the individuals and organizations that contributed:

• TH, NN, WS
• Scottish Government
• Finland RAVA3 project

The regulatory information requirements included in scope span across the three common regulatory interventions:

1. Concept and zonal approvals
2. Technical design and construction approvals
3. Approvals for occupation and use.

The project will cover several categories of Regulatory Information Requirements and so will develop consistent approaches to the representation of:

1. Directly relevant information.
2. Information representing the results of analysis, simulation and calculations.
3. Information that may be dependent on local conventions and standards.

The project has identified three priority use cases: project information and identification, life safety and building performance. Others such as accessibility are being considered.

1 Machine-readable regulations

The growing adoption of IFC and the increasing quality of the representation of the facility suggests that this process can reach a sufficient quality to provide the information required. In particular jurisdictions, it may be possible to specify the content of such BIM models to satisfy a specific code requirement using locally crafted programs, scripts or procedures. In some cases, the content of the regulation may be directly encoded into the behaviour of particular object such as a staircase or structural member.

However, these applications are costly to create, maintain and accept. Their development may need the expertise of local regulatory experts, programming experts and model experts. With the regulatory environment subject to a significant rate of change and relatively short notice of the change, the development of such code-checking applications cannot be seen as a one-off investment. In practice, it requires a continuing program of maintenance.

Attention has shifted from such ‘black box’ applications towards separating out the knowledge embodied in the regulations, the knowledge embodied in dictionaries and classification and the knowledge about the proposal. This can ensure that a simple and highly consistent ‘rule engine’ can consume rules either to validate the proposal or to suggest or effect corrections.

Such ‘rule-engines’ need a machine-operable representation of the regulations. Currently, there are four methods, all of which are being trialled internationally.

1. The first alternative has been to write a manual transcription of the regulatory text, tables, and diagrams into a computer programming form. This programming can be procedural (Visual Basic or Python), or it can be declarative (e.g., Lisp). The transcription process is notoriously unreliable. In one early test, 15 of the 30 concepts found in a clause actually appeared correctly in the coding.
2. Mapping the regulations onto a library of rule templates embedded in a particular application. These rule templates assume that the nature of the checks can be listed out and are of a manageable number. Solibri offers around 60 such rule templates, Xinaps offers three more generic templates. However, the content of regulations is not simple the ‘requirements’: any requirement (‘to be better than X’) is invariably qualified by sections, clauses and provisions which focus the ‘applicability’ and ‘selection’ of scope (external doors and windows’ and define any ‘exceptions’. Rule templates are dependent on these scope rules being well defined and consistent. They also cannot represent the process aspects of checking, such as ‘to the inspector’s satisfaction’.
3. In the last decade there has been investigation of the use of Natural Language Processing (NLP), a branch of AI, to parse text and use the grammar constructs to interpret the text in to rule templates. To date NLP has not been accurate in taking the context of a single sentence into account, nor in recognizing the role of lists and tables. Regulations sometimes contain detailed knowledge that is expressed in complex sentence structures that may not fit into the fixed number of templates.
4. There is a hybrid approach which allows regulatory experts to document their understanding of the regulations by using colored mark-up to highlight the roles of key phrases and sections. This mark-up can be reviewed, corrected, and improved by consensus. Once completed, the logical structure of the entire regulation and the specific metrics that is needs to test against the proposal become available automatically. This RASE (requirements, application, selection, exception) method has been used in USA, England, and Wales and in Scotland.

Once the content of a regulation has been captured, it can be used to drive a ‘rule-engine’ or to drive semi-automated check lists. For example, the checking of door and corridor widths is repetitive and error prone and may best be processed mechanically. Requirements on the facility or process as a whole, such as the issuance of neighbourly notifications’ may be best handled within an automated checklist.

2 Project description

With growing interest worldwide in improving and automating the regulatory compliance process, this project is ensuring that the regulatory information requirements common across many jurisdictions have an appropriate representation in IFC, whilst leaving jurisdictions free to add local information requirements and implement their own checklists and rules.

Implementations in Singapore, Finland, Estonia, Norway, Romania, Italy, Singapore, and the UK are developing Regulatory Information Requirements, and other buildingSMART Chapters have parallel programs at the research or implementation stage. This project is drawing on this and the prior work on Application Forms completed by the regulatory Domain and activity in other Domains to discover and document the best possible consensus.

The findings on national projects are similar. The properties and property sets within the IFC standard include a number of value fields related to building permits and other regulatory procedures.  However, the data fields are scattered across different property groups and have major shortcomings. The outcome is, that at the national level, it has been decided to define completely separate property definitions, which are in line with the IFC scheme but poorly compatible with each other.

IFC2x2 was the first IFC release to include property sets and entities specifically to support regulatory processes. The buildingSMART Regulatory Domain has already published its roadmap and reports on electronic processes and interoperable regulations. The development of the UK BS1192 and, subsequently ISO19650 has established the role of ‘Information requirements’ as key elements in information management and the use of collaborative BIM, but not yet for regulatory and other third parties.

The building permit process is one of the key processes in construction. It is a mandatory step in virtually all construction projects. A building permit's information requirements also guide many other information requirements related to the construction and use phase of real estate. The introduction of IFC models as part of the building permit material will significantly impact the use of BIM in the overall construction process.

The purpose of the use of BIM in the regulatory processes is to improve the flow of data between different systems and registers, to enable various life safety and health-supporting analyses, and to automate energy efficiency reviews of buildings. For public actors, BIM data transfer must be performed using an open BIM exchange standard. In practice, this means the IFC.

As part of national digitisation projects, many countries are exploring or implementing IFC in regulatory processes. In Finland, for example, the Ministry of the Environment is preparing regulations that will, in practice, make IFC mandatory in building permit processes, and in Estonia an IFC-based building permit system has already been developed and is currently being implemented.

‘Regulatory Information Requirements’ extends the present set of project and in-use information requirements to include the common requirements to support third-party involvement such as government, mapping authorities, regulators, and similar bodies.

The technical roadmap for the project is divided into five main phases. The first phase has analysed the results of ongoing and already implemented national projects. In the second phase, generic IDM descriptions are being generated based on the results. In the third phase, the project will use bSDD technology to connect the identified ‘Property Sets’ and ‘Properties’ into a single Regulatory Information Requirement specification. In the fourth phase, based on the IDM descriptions and bSDD/Property specifications, one or many IDS description(s) will be developed to be used for permit system definitions and authoring tool certification. Finally, guidance is being developed on how the bSDD and IDS definitions are to be used.

The key deliverables are candidate entries in the new bSDD so that, once approved, the new and revised property sets and properties can be added to the next formal release of the buildingSMART IFC schema and define a supplementary IDS “Regulatory Information’ IDS to extend the base Coordination/reference views, using bSI IDS “Information Delivery Specification” representation.

Some specific use cases, such as ‘means of escape’ and ‘energy modelling’ are already under consideration in the Building Domain. The project will liaise with these to coordinate the regulatory parameters alongside their work on simulation parameters.

Regulatory requirements are characterised by transparency and system independence. The information specifications used for these purposes should enjoy the widest possible consensus and be widely and openly available. On the other hand, they are in many respects national or local. It is, therefore, justified to develop essential Regulatory Information Requirements into international ISO and/or CEN standards insofar as they can be generalised. At the same time, detailed property fields and their content requirements are more dynamic and for them, standardisation needs to be more agile. This development can be led by buildingSMART.

“Regulatory approval” is the process gaining permission from statutory authorities for

• planning, including zoning and land-use approval, often with consultations with the public and other stakeholders regarding the external context
• technical approval , often with consultations with public utilities, regarding the internal content of the proposal 
• occupancy approval, often with periodic review of fire and health aspects

In developing the RIR deliverables, two key points have emerged. Firstly, that requirements are qualified by application, selection, and exception clauses. This requires that the properties that affect the scope should be included in the project alongside the properties describing the requirements themselves. Whilst these extra properties expand the information requirements that need to be considered, they work to reduce the amount of actual information that is required in a proposal model.  For example, in the UK not every door needs its closure-strength documented, only those that are entrance doors of public buildings. Secondly, the properties needed to represent and check regulations can be classified.

1. 1. Those reflecting specific characteristics of a local jurisdiction.
   2. Those derivable (calculable) information expected to be in the proposal model
      1. information, such as totals or net clearances.
      2. shape or extent, such as overall sizes
      3. relationships such as adjacencies
   3. Those reflecting compliance or exceptions to other specified clauses or standards
   4. Those reflecting process or procedural steps, such as notifications.
   5. Those that are already in IFC4.3
   6. Those that are common across jurisdictions and should be included in the RIR deliverables.

The facility model (BIM) can be part of an overall submission that can include:

• application form or submission with specifics of the applicant and agents
• specifications and product data
• geolocation and cadastral location information
• references to other permits, changes and licences

• To provide a library of useful userdefined types and regulatory properties in the buildingSMART Data Dictionary
  • https://identifier.buildingsmart.org/uri/bsird/rir/0.9
• To provide an outline IDS that can form the basis for localisation. 
  • See attached IDS file

• The three 'use-cases' of general information and identification, of life-safety and of 'performance' cover the largest areas of commonality. Individual countries and jurisdictions will have other areas subject to regulation which have been taken as out of scope 

• National, regional and local regulatory requirements

RIR Regulatory Information Requirements