Principles & rules

Principles are structural conditions which have to be in place before starting to collaborate and exchange information digitally. The principles are listed below.

  1. Define the employer's/client's information (exchange) requirements and key decision points.
  2. Make clear agreements on what information will be exchanged (digitally), when and how, between all actors involved in the construction process. Preferably, these agreements are laid down in contracts.
  3. Make clear agreements on what technical1 , semantic2 and process3 standards will be used between all actors involved in the construction process.
  4. Clearly define the roles and responsibilities of all actors involved at the beginning of the process.
  5. Make sure that actors involved have the necessary (basic) skills and knowledge with regards to digital information exchange.
  6. Embed digital information exchange in the way of working of all actors involved.
  7. Present information according to open standards, to ensure that information exchange:
    1. is understandable and readable for all actors involved.
    2. allows direct re-use of information (for multiple purposes) by the actors involved without the need for information duplication or information loss.
  8. Present information according to a universal or commonly agreed structure (establishing where to put what information and how to describe it).
  9. To all actors who are required to produce, use or maintain information, make a single online storage environment available that:
    1. does not require a heavy technological infrastructure
    2. does not require heavy ICT/information management knowledge
    3. does not require heavy financial investments
    4. does not rule out any operating/ ICT system
    5. enables the exchange of multiple data formats (including 3D models)
  10. Exchange information across project/construction life cycle phases
  11. Make information available (readable, understandable and re-usable) for a sustainable period of time.
  12. Protect access to information through security and privacy measures as agreed upon at the start of a project.
  13. Make sure that the information exchanged complies with the information exchange agreements, requirements and rules set by the actors involved.


1Technical standards are technical criteria/ requirements a system, product or service should comply with. This could be a document format or a way of structuring and presenting information.

2Semantic standards define terms used in construction design, in order to make sure business partners understand and interpret information in the same way.

3Communication standards focus on what communication activities should be performed by what actors within the project (e.g. at which time, which messages, attachments, etc.)

Rules are operational guidelines which can be followed to collaborate and exchange information more effectively. The rules are listed below.

  1. Determine the file name structure
  2. Determine a file folder structure (to be included in the online storage platform)
  3. Determine an identification structure (what identifiers will you use for specific information, e.g. ways to define an object and its characteristics)
  4. Determine a versioning/change log structure
  5. List the general client requirements
  6. List the project deliverables
  7. Define the purpose of each deliverable
  8. Define the required content of each deliverable (including the required level of detail of information)
  9. Define the optional content of each deliverable
  10. Define the business rules per deliverable (e.g. the bathroom needs to be at least x square meter)
  11. Define the project stage in which the deliverable is due according to standardised classification systems (e.g. through Omniclass/Uniclass/IDM standard stages)
  12. Determine the required document format per deliverable
  13. List the software used for drafting the deliverable
  14. Define the nature of the information exchange (one-way or round-trip, i.e. should information be delivered by one actor or are other actors needed to provide input or feedback)
  15. Define the player responsible for each deliverable in a standardised way (e.g. by omniclass/uniclass discipline number and name)
  16. Define the contributing players for each deliverable in a standardised way (e.g. by omniclass/uniclass discipline number and name)
  17. Define the owner(s) of each deliverable in a standardised way (e.g. by omniclass/uniclass discipline number and name)
  18. List the documentation/deliverables/sources related to each deliverable
  19. Define the milestones per deliverable (intermediate deadlines)
  20. Define the deadline/timeline per deliverable.