Delivering ISO 19650 on a Saudi gigaproject: field notes

Every Saudi giga package I have worked near turns up with the same two documents. There is a client information requirement that cites ISO 19650 by clause and reads as though it was drafted in Leeds. And there is an appointment naming a platform nobody else on the plot is using. The first is the ambition; the second is the job. Between them sits a document controller with four logins, a register living in a spreadsheet because none of the four will export cleanly, and a municipal e-service that rejects the filename the naming convention insists on.

Work of this size holds or breaks at five fairly ordinary points: several common data environments rather than one, a municipal permit desk that is not a CDE and was never trying to be, language treated as a second source instead of a transform, volume mistaken for maturity, and an issued set with no owner. None of them need a project name to describe.

What actually tells you anything

Field notes that name a resort, a line or a joint venture are usually marketing in a hard hat. The objects worth asking about are smaller and duller than that.

Who appointed the information manager for each appointment? Which CDE state did that shop drawing occupy on the day it was built from? Were the permit model and the construction model ever the same object? Which language was the municipal pack stamped in, and does that pack still pair back to the English container in the library? A case study that cannot answer those four is a photograph of a skyline.

Thresholds, forms and portal names all move, so check the current circular before you quote one at anybody. The pattern underneath moves far more slowly.

The appointment stack, not the skyline

A gigaproject is a delivery authority, a masterplan consultant, enabling-works contractors and a row of package joint ventures. Each package contractor is an appointing party to its own supply chain, which is the part the organogram tends to flatten. ISO 19650-2 never asks those appointments to share a database. It asks each appointment to manage information containers through a process, and it asks the appointing party to establish a project CDE while allowing a delivery team its own connected environment.

What the slide draws is one logo and a hope that two hundred firms will complete the same onboarding. What the appointments actually say is three or four named platforms, a municipal e-service nobody calls a CDE, and a line promising the programme will "comply with ISO 19650". Compliance is not a login; it is a managed process for containers — work in progress, shared, published, archive — with a status the next person is forced to look at, and an issued set the works are permitted to build from. Ask for those objects appointment by appointment, and if nobody can point at them, the rest of the conversation is decoration.

Several CDEs, one process — or none

The characteristic pattern out here is not an absence of a CDE. It is too many systems of record and nothing written down about the exchange between them.

The international consultant arrives with a CDE already in the fee. The local contractor arrives with another, priced into the contract and defended by lawyers who will not accept "everyone has a login". The PMC holds a third. Package joint ventures on adjacent plots are competitors on next year's tender, and while permissions inside a platform can hide a folder, they cannot hide the fact that the folder sits on a rival's tenant. Data residency closes the argument. A package whose records must sit in-country on a named platform is not going to migrate quietly into a programme tenant procured two years earlier for a different appointment.

Federation in the ISO sense is still one CDE, provided the workflow is shared. On the ground that is rare. What you get instead is a weekly zip, an open folder, or a promise that the BIM coordinator will federate it. That is a courier service. It says nothing about the state the file left in, the state it arrived in, which suitability was acceptable, or who is allowed to supersede it.

The version that works is boring. Each package CDE stays authoritative for the containers of its own appointment. The receiving environment — programme, employer's, or the package next door — takes a bounded set: these containers, this revision, this state, this suitability, this purpose, this transmittal, this date. And somebody is named as owner of the cross-package issued set: grids, levels, plot limits, shared utilities, the masterplan sheet two packages are both building from. Without that name, federation is a diagram of arrows, and arrows do not issue anything.

The Monday version of this test takes an hour. List every appointing party and the CDE each execution plan names. If the list says "the project CDE" and three contracts name something else, you have a federation whether you planned one or not. You have simply not written the exchange.

MOMRA is a permit desk

MOMRA, on an appointment document, still means the Saudi municipal building-permit track: a national or municipal e-service, stampable sheets, a licensed Saudi consultant, and a demonstration that the Saudi Building Code has been applied. The ministry's public name has changed more than once. The information ask has not turned into a login to your construction library.

The typical pack is architectural, structural, MEP and civil sheets, a geotechnical report, ownership and planning permissions, and an occupancy or completion file later on. Civil defence runs its own track. Housing and municipal forms are not always the same desk. None of it is a BIM execution plan.

BIM is where two asks end up wearing one word. A delivery authority will write model, classification and handover requirements that read like ISO 19650. The municipal form still wants drawings, stamps and reports. Mapping your issued set to MOMRA is not the same labour as mapping it to the client's information requirements, and teams that talk about "submitting the BIM to MOMRA" are usually pushing a construction model at a drawing gate, or handing a municipal sheet pack to a client who asked for a structured asset register. Both go wrong in ways you could have predicted at the kick-off meeting.

A stamp does not travel. A London or Dubai licence is not a Riyadh licence. If the mapping table does not name the Saudi licensed author per pack, your source set can be immaculate and the submission still cannot start. I have watched a package stall on that alone while everyone hunted for a technical fault.

Local portals sit beside MOMRA and share neither a filename rule, a file-size limit, nor a definition of the word model. Utility and civil-defence NOCs keep their own sheet lists, and a green cell in the drawing register moves none of them. Treat the portal as a second source and you will discover at inspection that two buildings have been living on the plot in parallel: the one that was permitted, and the one the works are building.

The fix is the same mapping any multi-authority job needs. One issued set is the source; the municipal pack is an extract of it. Write the pairing down — source identity, destination authority, destination pack, format transform, identity transform, licensed author, revision pairing, and what is deliberately not sent. If the transform reads "upload the Revit", nothing has been mapped.

One more thing, because it happens constantly. Do not federate the permit model back into the construction environment as though it were as-built. It is thinner on purpose. Once it becomes the unofficial coordination model, the works follow the permitted building and the issued construction set turns into a rumour.

Language is a transform, not an afterthought

Official submissions in the Kingdom are not an English courtesy. Title blocks, stamps, ownership documents and a large share of the municipal pack travel in Arabic. The construction CDE, the international consultant's models and most of the naming convention travel in English. Left unwritten, that stops being a translation problem you can tidy up at the end and becomes a second identity for every container.

The failure is ordinary enough to be dull. Someone produces an Arabic sheet set for the portal and an English set for the package. Both are sincere. Neither is paired. A window moves in the English published set and stays last month's unit in the Arabic pack. A filename that satisfied the project convention is rejected by the portal, so it gets renamed by hand and the register carries on showing the old identity. A comment sits in a coordination model in English while the instruction reaching the gang is an Arabic plot with no status code on it. In a dispute, the contemporaneous record is the print in the trailer, not the column in the library.

What works is keeping the project container name as the persistent identity and treating Arabic portal names, sheet indexes and stamps as aliases of it. Overwrite the source name with the portal name and you cannot find your way home. Keep two unlinked sources and you have not delivered bilingually — you have two projects sharing a plot number.

That labour belongs in the information requirement rather than in somebody's evenings. An EIR that cites ISO 19650 and never says which language is authoritative for which purpose has skipped a clause-level question, however tidy the folder names are.

Volume is not maturity

The volume on a gigaproject is unlike a UK frame job. Hundreds of firms. Tens of thousands of containers. Models that will not open in a permit viewer. Shop drawings arriving faster than anyone can apply a suitability code, and transmittals degenerating into weekly dumps because the desk cannot keep up. The controller on that desk is not short of diligence; they are short of hours.

Volume then gets presented as proof of digital maturity, when usually it is proof that state has collapsed. Work in progress, shared and published end up in one pile labelled Latest. S2 goes on everything, because the field has to be filled with something. The unofficial hut set — the plotter tray the gang actually trusts — outruns the published set, because the published set is three days behind and three platforms away.

Level of information need exists in the standard for exactly this moment. It asks for enough, not for everything. A federation carrying fabrication bolts, temporary works and last week's clash is no more compliant for it. It will fail a municipal size check, or pass and then be queried for objects the gate never asked about.

What you are aiming at is a published set a document-control desk can still issue on a named Tuesday, and a permit extract that is deliberately thinner. If reconstructing the programme issued set takes three exports and a weekend, the workflow has become archaeology. Most of the useful labour is refusal: what is not shared, what is not published, what does not go to the portal.

The issued set is the only interesting object

An issued set is a bounded act: these containers, these revisions, this purpose, this list of recipients, this moment. On a multi-CDE, multi-portal, bilingual programme the purpose that matters first is authorised for construction — and, separately, authorised for extraction into a municipal pack.

Most desks have something weaker. A federated model the coordinators use. A drawing register the document controller trusts. A permit folder someone zipped last month. An energy or code model a consultant never checked back into the same identity scheme. Each copy is sincere in its own corner. Together they are four buildings wearing one name.

Which is why the questions worth asking on a walk are contractual rather than scenic.

Who can move a container to published, and who can issue? If those two names are missing, the package CDE is a cupboard.

Which record is the instruction when package A changes a shared grid and package B is already in the ground? If the answer is a coordination model federated last Thursday and circulated as a screenshot, nobody owns the issued set. What you own is a meeting.

Which object was site allowed to build from on the day the concrete went in — the permit model, the construction published set, or the hut print? A programme that cannot answer that has delivered a federated file rather than ISO 19650.

Patterns you will recognise

None of these need a named gigaproject. They live in the appointments and the portals.

One zip, three destinations: programme CDE, package CDE, municipal portal. Same filename, same objects, same missing stamp.

The permit model becomes the coordination model, because it was the file that opened.

A UK naming convention is pasted into a portal that rejects the filename. Someone renames by hand. The register still shows the old identity.

A consultant stamp is used in a jurisdiction that does not recognise it. The pack is complete and cannot be accepted.

Construction level of information is dumped into a permit viewer. The upload fails, or it succeeds and then gets queried.

NOCs live in mailboxes, the model lives in a CDE, and the permit waits on a letter nobody can find.

Everything is S2. The BEP has been "complied with". No action has ever been refused on the strength of a code.

Two hundred user accounts sit empty on the programme tenant while issue happens by email.

Three document controllers, three registers, no pairing — a detail moves in one library and stays put in the other two.

What the working version looks like

It is just as ordinary, which is rather the point.

Each appointment names an information manager with the standing to refuse a suitability that still says coordination. Each appointment names a CDE. The exchange between those CDEs is written down: state out, state in, acceptable suitability, filed transmittal. The cross-package issued set has an owner, and the owner is a person rather than "the BIM team".

The municipal pack is an extract of the issued set rather than a second building. Design revision and authority-submission revision are two separate fields. When the source revises, the previous destination pack is withdrawn — no portal will do that for you.

Arabic and English are paired aliases rather than parallel sources. Volume is governed by what the next use actually needs. And the programme issued set can be produced on a named Tuesday without anyone rebuilding it from exports.

Say what you like about platforms; none of them delivers the standard for you. The process is the thing that has to be able to say, for one shop drawing and one permit sheet, which container, which revision, which state, which language and which authorised use sat beside the works on the day they were built.

What none of this settles

No software is certified against ISO 19650, and the series still governs the appointing party's process rather than a login. On the next package, that appointing party can write the exchange into the appointment — state out, state in, acceptable suitability, filed transmittal — and name a person, not "the BIM team", as owner of the cross-package issued set. Put the municipal pack on the same source as an extract, with the pairing (source identity, destination pack, licensed author, language alias) sitting in the information requirement rather than in somebody's evenings. That is a day at kick-off and a controller allowed to refuse a weekly dump; it is cheaper than four unlinked buildings on one plot. Recheck the current circular before you quote a portal rule at anyone. Thresholds move. The pattern does not wait on a new ministry name.