Skip to content
Profile & journal2026
Back to the blog

The GCC Building Code: reflections on taking part in the Riyadh meeting, 2025

On taking part in Kuwait Municipality's technical delegation to the Fourth Meeting, and why technical standards need to be connected to how they are applied.

Six paper plans fitting together into a single architectural structure, symbolising the GCC Building Code
AI-generated editorial illustration in a 1960s style; it does not document a real site or event.

In August 2025 I took part, as a member of Kuwait Municipality's technical delegation, in the Fourth Meeting of the GCC Building Code Committee in Riyadh. The report published on 3 August 2025 lists me as a member of the delegation alongside Eng. Mohammed Marzouq Al-Mutairi, who chaired the committee's meetings. I return to that participation here from the angle of the relationship between developing technical standards and making them workable in municipal practice.

The value of a shared technical language

A shared language in the construction sector helps authorities, consultancies and specialists discuss requirements clearly. How a term is defined, how a requirement is presented and what information is needed to demonstrate compliance all shape understanding before any work begins. The more precisely these elements are defined, the less disagreement arises from differing interpretations.

At the same time, joint work across the GCC needs an understanding of the local conditions in which the code is applied. Reading a technical text in light of the urban and climatic setting and the review mechanism helps raise practical questions. I do not cover the meeting's deliberations or outcomes here, only the questions that applying the code raises.

From the text to the review model

When I think about turning a requirement into a digital service, I ask: what can the applicant enter in a structured way? What needs a document or an engineering model? And what calls for professional judgement? Separating these types matters, so that we do not reduce a complex technical question to an accept-or-reject box that gives no reasons.

  • Define terms and required data consistently.
  • Link each comment to the technical reference that explains it.
  • Make clear the limits of automated checking and the cases that need specialist review.
  • Keep the version of the reference used, so the decision can be understood later.

Review tools can start with limited functions, such as checking that data is complete, to test their value before moving on to more complex questions of interpretation and design.

Collaboration we can build on

What matters to me in technical meetings is that the dialogue continues after the meeting ends: how do we organise the questions, document the differences and benefit from varied experience? I prefer experience to be presented together with its conditions and limits, because knowing the context helps judge how well it would suit a different setting.

This participation is part of my interest in municipal work that brings together engineering knowledge, regulation and technology. Opportunities for improvement still depend on our ability to explain requirements, build clear data around them, and provide professional review that is understandable and whose basis can be traced.

Sources and references

Sources last reviewed: