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