ISO standards for information management and exchange.

What ISO 19650 actually asks for

ISO 19650 is a framework for managing information over the life of an asset, not a modeling standard, and it does not tell anyone how to draw a connection. ISO 19650-1 sets the concepts and terminology; ISO 19650-2 covers the delivery phase, where a project defines its exchange information requirements, appointed parties respond with a BIM execution plan, and information is produced against an agreed delivery plan. Each appointed party works to a task information delivery plan, and these combine into a master information delivery plan for the whole project, so the delivery timetable is visible at both levels. ISO 19650-3 carries the same discipline into the operational phase, once the asset is built and being run.

What it asks for in plain terms is an answer to four questions before modeling starts: who needs which information, in what format, by when, and to what level of detail. Most of what goes wrong on a project running under ISO 19650 traces back to one of those four questions being answered vaguely, or not being answered until it is already overdue.

Containers, status codes and the common data environment

A container is the smallest piece of information ISO 19650 tracks as a single thing — a model file, a drawing, a schedule, a document — and every container carries a name built to a fixed convention and a status that states what it may currently be used for. The common data environment is where containers live as they move through four states: work in progress, where a task team develops information; shared, where it is available for other teams to coordinate against; published, where it has been authorized for a specific use such as construction or tender; and archive, where every state is kept as a record.

The discipline is in the movement, not the storage. A container that jumps straight from work in progress to published without passing through a shared, coordinated state is exactly the failure ISO 19650 exists to prevent.

IFC and open exchange under ISO 16739

ISO 16739 defines IFC, Industry Foundation Classes, the open and non-proprietary data schema published by buildingSMART International for sharing building and construction data between software that was never designed to talk to each other. A structural model built in one authoring platform can be issued as IFC and opened, coordinated against and clash-checked by a team working in a completely different one, without either side converting to the other's native format.

An IFC exchange is usually scoped to a defined subset of data agreed for its purpose — geometry and coordination data for clash detection is a smaller exchange than a full data handover — so that what is sent matches what the receiving party actually needs rather than everything the model happens to contain. buildingSMART publishes defined exchange scopes, commonly called model view definitions, for specific purposes such as coordination or design transfer, and naming which one an exchange follows removes ambiguity about what the receiving party should expect to find in the file. Native files still carry more intelligence than IFC captures, which is why we issue both rather than IFC alone.

Security-minded information management

ISO 19650-5 adds a security-minded approach on top of the standard delivery process, for projects where the information itself is a risk — critical infrastructure, defense, and increasingly some commercial and data infrastructure work. It asks a project to run a sensitivity assessment before information is produced, not after: is the asset sensitive, does the information about it need controlling, and if so, what technical, procedural and physical controls follow from that. Access typically follows a need-to-know principle rather than a project-wide default, so a consultant working on one building of a campus may never receive the full site model.

In practice that changes ordinary decisions. Who receives a federated model, whether a full model or a redacted extract, whether certain elements are modeled at all rather than issued as a note, and how access is logged all follow from the sensitivity assessment rather than from the standard project team list. Those constraints are agreed before modeling starts, not layered on afterward.

The ISO standards that govern the sheet itself

ISO 19650 decides which file reaches whom. A separate and much older family of ISO standards decides what the drawing inside that file looks like, and it is the reason a sheet produced in one country is readable by a fabricator in another without a covering note explaining the conventions.

ISO 5457 sets drawing sheet sizes and the layout of the frame. ISO 7200 sets the data fields a title block carries and what each one means — identifier, legal owner, approval and issue dates, revision — which is the same metadata a container name carries under ISO 19650, written on the sheet instead of in the file system. ISO 128 sets the general principles of presentation: line types and widths, views, sections and hatching. ISO 129 governs how dimensions are indicated, ISO 3098 lettering, and ISO 2553 the welding symbols a shop drawing depends on being read exactly one way by everyone who opens it.

These are the standards a drawing set silently either follows or does not. A set that mixes ISO welding symbols with another convention, or whose title block is missing fields ISO 7200 defines, still prints and still looks finished. It costs a query later, raised by somebody who could not tell what they were looking at, and answered by somebody who has moved on to a different job.

Management system standards, and what they are not

ISO 19650 and ISO 16739 govern project information. A second group of ISO standards governs how an organisation runs, and they appear constantly in client questionnaires and contract conditions, so it is worth being clear about which does what.

• ISO 9001 — quality management: documented processes, defined responsibilities, records, and corrective action when something goes wrong.
• ISO 14001 — environmental management, covering an organisation's environmental aspects and the controls it operates over them.
• ISO 45001 — occupational health and safety management, which replaced the older OHSAS 18001 framework.
• ISO 27001 — information security management: the standard sitting behind most client questions about where project data is stored, who can reach it, and what happens to that access when somebody leaves the team.
• ISO 50001 — energy management, which reaches construction mainly through operational targets set on the finished asset.

None of these says anything about how a structure is designed or a drawing produced. They describe how an organisation manages itself, and they are certified against by an accredited certification body rather than self-declared. A client asking for them is asking a different question from a client asking for ISO 19650 compliance, and conflating the two is how a project ends up with certificates on file and no exchange information requirements written down. Which of these a given engagement requires, and what evidence is provided against each, is agreed in the contract rather than inferred from a logo.

How we check an ISO 19650 delivery

The automated checks on an ISO 19650 delivery verify that every container is named to the agreed convention, carries the correct status, and is issued through the shared state before it reaches published. IFC exports are validated against the native model before issue, rather than trusted to have exported cleanly, and the exchange information requirements agreed at the start of the appointment are checked against what is actually delivered.

Where a project runs under ISO 19650-5, the checks confirm that only the agreed containers reach each recipient, and the record of who received what is kept as part of the delivery. A senior engineer reviews the delivery and signs it off before issue, the same as on any other package.