DIS/ISO 19650-1:2026 — New Concepts

Last week I tried to map the current ISO 19650-1:2018 with the concepts as they’re now laid out in the DIS/ISO 19650-1:2026, in public consultation until June 2nd. I hope if was helpful to all those who were feeling lost, but the changes aren’t the most significant aspect of this new ISO: what’s more significant is what’s new. So, this is what we’re looking at this week. I’ll highlight the main new ideas, give you a complete overview, and then I’ll tell you what I think of the whole thing. Bear with me.

1. Information Purposes

Do you remember model uses? This is not the same. Not exactly, at least.

The concept is introduced in Clause 5 and articulates the idea that every item of information must be produced in response to one or more clear information purposes, identified by the users of that information. If you remember, I’ve adopted this approach in BIM execution planning since the earlier stages (and the domestic market still can find it articulated in this book): you start from stakeholders, that the ISO calls perspectives, you understand their high-level goals, you distill them into model uses, and this has a direct impact on the information and geometry and documentation of your objects (call it Level of Information Need, call it Level of Development, it’s that thing).

This clause represents one of the most mature contributions of DIS 2026; I believe, and I think that the purpose-driven approach to information management is conceptually superior to the implicit approach of Ed. 2018, where requirements were defined primarily based on project structure rather than the needs of end users. Its practical application, which I’ve been preaching for years, requires organisational analysis competencies not yet widely distributed across the AEC sector, and this will be interesting work.

The intellectual lineage of this concept is worth noting: the purpose-driven approach to information has deep roots in knowledge management theory and in the use case methodology of software engineering (particularly the Information Delivery Manual tradition, ISO 29481, which the DIS 2026 explicitly cites). The DIS 2026 is, in part, an attempt to bring these more sophisticated analytical traditions into the mainstream of built environment information management practice.

Table 1 of DIS 2026 tries to map perspectives, purposes and examples of information requirements. Unfortunatly, it falls flat on its belly when it comes to the project management perspective: instead of carrying it onwards the idea of the information model as the basis for reliable decision, it gives us a project manager that “needs to visualize the intended asset in 3-d to support asset user engagement and feedback”. They want the video. Seriously? Is that the best we can do in 2026?

2. Normative Ecosystem

We’ve already seen this in the previous part of the analysis, last week: the new section 0.2 of the Introduction explicitly maps the relationships between ISO 19650-1 and a set of related standards, with Figure 1 graphically illustrating this ecosystem. This is new: Ed. 2018 cited other standards in a dispersed manner across the Bibliography and body text, without a systemic overview. This is a useful and long-awaited editorial contribution. However, it also highlights how costly the correct implementation of the ISO 19650 framework has become: to apply the standard in the manner intended by its authors, an organisation would need to acquire and study at least ten standards. This creates a significant access barrier, particularly for Small and Medium Enterprises, unless their Trade Associations step in to support them.

The relationship between ISO 19650-1 and the related standards is also expanded in Annex A, which replaces Annex of Ed. 2018 that contained illustrations of federation strategies. The decision represents a repositioning of the standard, from an applicative tool to a conceptual reference framework. More mature market participants may appreciate this conceptual clarity, but new entrants may find the standard less accessible, which is a fil rouge of this whole operation.

3. Information constraints: formalising what cannot or must not be produced

Closely related to information purposes, but conceptually distinct, is the introduction of information constraints, defined as “a statement that formally defines or constrains the scope or use of information due to some aspect of the business, a rule under which an organisation operates or a policy or decision that influences a process.”

The 2018 edition had no equivalent concept: security considerations appeared in passing (Clause 9, principle f; Clause 3.3.13 on status codes), and the standard acknowledged that information requirements could be “required or suppressed” for security or risk management reasons (Clause 5.1). But there was no formal category of constraint, no conceptual space in the framework for the idea that some information should not be produced, or cannot be shared, or must be produced in a particular form due to regulatory, legal, or security obligations.

The DIS 2026 makes constraints a first-class concept throughout the framework, as they appear alongside information requirements in virtually every clause where requirements are discussed: requirements and constraints are defined together (Clause 7), issued together in procurement (Clause 8), planned against together (Clause 9), and reviewed against together in the CDE workflow (Clause 11). The parallel treatment of requirements and constraints signals that the framework now understands information management as operating within a field of both positive obligations (produce this) and negative obligations (do not produce that, or do not share it with these parties, or produce it only in this format).

This has direct practical relevance for three areas that the 2018 edition handled inadequately:

1. security-sensitive assets: the constraints framework provides a normative basis for restricting what information is produced and who can access it, which is essential for assets such as critical national infrastructure, criminal justice facilities, or defence installations.
2. Data protection: legal constraints arising from GDPR or equivalent legislation — which may prohibit certain types of information being recorded or shared — can now be accommodated within the framework as constraints rather than being treated as external interruptions to the information management process.
3. Intellectual property: constraints can formalise the conditions under which information produced by one party may or may not be reused by another, addressing a gap that the 2018 edition’s general reference to “intellectual property agreements” (Clause 9, principle a) left largely unresolved.

4. The trigger event as a structural mechanism

The concept of trigger event existed in the 2018 edition (defined in Clause 3.2.13 as “a planned or unplanned event that changes an asset or its status during its life cycle, which results in information exchange“) but played a marginal role, as it appeared primarily as a way of describing when information exchanges occurred during the operational phase, and its definition emphasised its relationship to information exchange — a downstream consequence — rather than its role as the initiating force of the entire information management process.

In DIS 2026, the trigger event is elevated to a foundational structural mechanism, and becomes the pivot around which the entire framework turns. Clause 6.3 defines it as the generic term for “something that occurs during the life cycle of the asset that changes or will change it physically or in an abstract way and for which the asset information model needs to be updated.” Every project — and therefore every activation of the information management process — is initiated by a trigger event. The holistic physical and organisational response to the trigger event is the asset-related project; the information management response is the project in the ISO 19650 sense.

Regardless of that last portion, this elevation has several consequences:

• it breaks the implicit assumption of the 2018 edition that information management is primarily a project-phase activity triggered by procurement. In the 2018 framework, the process started when an appointing party decided to procure something and issued an EIR. In the DIS 2026, the process can be started by anything, from a component failure, a change of ownership, a regulatory inspection, a strategic review. This makes the framework genuinely applicable across the full asset life cycle in a way that the 2018 edition was not, despite its stated ambition to do so.
• it narrows the character of the appointing party’s role. In the 2018 edition, the appointing party was primarily pictured as a procurer: they set requirements, they appointed parties, they accepted deliverables. In the DIS 2026, the appointing party is primarily an asset steward who must anticipate trigger events, prepare for them in advance where beneficial, and respond to them intelligently when they occur. This is a substantially more demanding role, and one that requires a level of strategic information management thinking that many appointing parties — particularly those accustomed to treating BIM as a project-phase tool — have not yet developed.
• it removes the relevance of this norm to all those appointing parties who weren’t clients (designers to their consultants, contractors to their subcontractors) unless they have an already defined organisational approach that can harvest benefits from the process and has its own goals and, even if I’ve been advocating the necessity of not doing BIM just for the client but also for yourself, leaves us in a bit of a pickle.

5. The asset-related project: decoupling physical work from information work

Closely linked to the trigger event is the concept of the asset-related project, defined in the DIS 2026 as the holistic response to a trigger event, encompassing the physical or operational work done on the asset. The project in the ISO 19650 sense is the information management and production response that runs in parallel with the asset-related project.

This conceptual separation — between the work done on the asset and the work done on the information about the asset — does not exist in the 2018 edition: the 2018 framework used “project” in both senses simultaneously, opening tricky conversations frequently encountered in practice: is the BIM Execution Plan a document about the construction project, or about the information management process, or both? Is the lead appointed party’s obligation to deliver a building, or to produce an information model of the building, or both? These conversations were heated, but necessary in order to define how strong the information model was in relation to the other ways physical work might actually happen (and I’m talking everything, from “you’re doing your calculations by counting on your fingers” to “construction did something different we’re not currently capturing”).

The DIS 2026 introduces a two-level structure:

• the asset-related project is what the builders, engineers, and asset managers do;
• the project is what the information managers do.

Which is the other way around of what you might expect.

The two are aligned through the trigger event that initiated both, and through the information requirements that define what the project (the digital part) must produce to support the asset-related project (the physical part). But they are conceptually distinct, which has practical implications for how appointments are structured, how scope is defined, and how liability is allocated when physical work and information production diverge.

Instead of pushing for people who’re doing the actual work to be more informed and involved in people who’re running around with information packages, we’re separating them. Which is gold for all those consultancy who do CAD-to-BIM and all the rest of the crap, but it’s bad for the construction industry.

6. Information production as a redefined concept

The 2018 edition used information delivery as its primary term for the activity of producing and providing information, and this use of “delivery” not just for the… well, delivery, but also for production was confusing enough. The DIS 2026 replaces this term with information production defined as “the generation, coordination, checking, reviewing, approval, authorization, acceptance and aggregation of information containers.” This definition reveals a substantively different understanding of what producing information involves.

In the 2018 framework, in fact, information delivery was essentially a logistics concept: information was produced somewhere, checked, and delivered to the party who needed it. The DIS 2026’s definition of information production encompasses the entire quality assurance cycle — from generation through the distinct stages of approval (by the appointed party), authorisation (by the lead appointed party), and acceptance (by the appointing party) — as components of production itself rather than as subsequent governance activities. The boundary between production and delivery collapses: information is not produced until it has been accepted, and everything that happens in between is part of the production process. Which is good.

This redefinition, as we were seeing last week, has significant implications for how the CDE workflow is understood. In the 2018 edition, the CDE managed the states through which information passed after production: from the author’s work in progress, through sharing and review, to publication. In the DIS 2026, the CDE manages the states through which information passes as part of production: there is no conceptual point at which information is produced and then separately managed or delivered. The two activities are continuous and coextensive.

The production springs from requirements but there’s also mention of:

• standards (Clause 7.3), everybody’s least favourite thing and one of my main areas of work;
• methods and procedures (Clause 7.4) defined as a library of stuff that’s available to achieve one or more intended outcomes.

7. Approve, authorise, accept: the differentiation of governance acts

This is another integration, on top of adding a status (as we discussed last week).

The 2018 edition described the transitions between CDE states in terms of “check/review/approve” (the transition from work in progress to shared) and “review/authorise” (the transition from shared to published). The agents performing these acts were not consistently differentiated, and the distinction between approval and authorisation was often unclear in practice. In the National Norm, we had to expressly state that the transition from work in progress to shared had to undergo an internal check, as if it’s not obvious that you don’t submit to the client random stuff before being sure they’re correct.

The DIS 2026 introduces three formally defined governance acts — approve, authorise, and accept — each assigned to a specific party and producing a specific outcome:

• approval (Clause 3.2.21) is performed by the authoring appointed party and confirms that an information container is suitable for a specified use;
• authorisation (Clause 3.2.22) is performed by the relevant lead appointed party and confirms that an information model meets the requirements for its approved use;
• acceptance (Clause 3.2.23) is performed by the appointing party and confirms that the information model meets their requirements.

The three-level governance structure maps precisely onto the three-level party structure of the framework — appointed party, lead appointed party, appointing party — creating a clean alignment between organisational accountability and information governance, and it’s an evolution of what was already specified in the 2018 edition. Each party at each level of the appointment hierarchy has a defined governance act that they and only they can perform. This more rigorous and operationally clearer treatment has direct implications for how CDE platforms should implement workflow permissions and how appointment documents should define information governance obligations.

It also has a downside, for smaller projects or projects where the lead appointed party was also one of the appointed parties (for instance, one of the design firms involved), because you can’t reasonably have the means and mental clarity to both approve and authorise your own stuff, unless you have an internal coordinator that approves (and talks to the delivery team), and another guy who authorise and doesn’t talk to anybody (and everybody hates, for sure).

The norm seems to think this is indeed a possible scenario:

• the definition of lead appointed party in Clause 3.1.5 reads: “actor fulfilling an appointment to manage information production,” with Note 1 stating that the term is used whether or not there is a formal written appointment in place,” which is a nice way to avoid taking a position but of course doesn’t work for anybody.
• the definition of appointed party in Clause 3.1.4 reads: “actor fulfilling an appointment to generate information,” with Note 1 stating the same thing and adding “whether or not this is the same organisation as a lead appointed party.”

8. The information production archive and journal: formalising memory

The archive state has always been a problem. The 2018 edition described it as “a journal of all information containers that have been shared and published during the information management process as well as an audit trail of their development,” but it always was unclear whether this was a space for stuff that had been shared and supeseded (my interpretation), or a space for stuff that had been confirmed and delivered (a narrower scope).

The DIS 2026 clarifies and separates this into two distinct concepts:

• the information production archive (Clause 3.2.24), defined as a record of all superseded revisions of each information container within the enabling technologies;
• the information production journal (Clause 3.2.25), defined as a record of each information container state transition within the enabling technologies.

In other words, the archive preserves the content of superseded revisions — what each version of a container contained — and the journal records the events: when each container moved from one state to another, and by whom. Together they provide both a content history and a process history, which serve different purposes: the content history supports dispute resolution (what did the model say at a given point in time?) while the process history supports accountability and audit (who approved this revision, and when?). This reflects a more sophisticated understanding of what organisational memory in information management actually requires.

9. Enabling Technologies and Linked Enterprise Systems

The enabling technologies mentioned above are defined at Clause 3.2.26 as “one or more technologies integrated to enable the information production workflow”, with Note 1 adding: “Enabling technologies form part of the CDE operational framework.” It’s brief and technology-neutral, the standard gives no list of qualifying technologies in the definition itself, though Clause 11.4 provides examples in the body text: information modelling platforms, databases, geospatial information systems, and electronic document management systems.

The companion concept of linked enterprise system is defined immediately after, at Clause 3.2.27, as “an enterprise system linked to one or more enabling technologies,” with examples in the notes including work planning and scheduling systems, CAFM systems, and ERP systems. The distinction the standard draws is that enabling technologies are the core operational apparatus of the CDE — they enable the workflow — while linked enterprise systems are external systems that connect to the enabling technologies for specific organisational purposes without being part of the CDE framework itself.

The Complete Overview

Taken together, these conceptual innovations tell a coherent story in itself, and it’s prejudicial to understand that this DIS 2026 isn’t a revised and updated version of the 2018 standard but a different animal and, in its intention, a more mature and more ambitious framework that moves in three consistent directions.

The first direction is towards intentionality. The introduction of information purposes, information constraints, and reference information all serve to make explicit what was implicit in the 2018 framework: that information management is not a mechanical process of specification and delivery, but a purposive activity driven by organisational needs and bounded by organisational realities. Information exists for reasons, and those reasons should govern every decision about what information is produced, in what form, by whom, and for whom. This I approve.

The second direction is towards governance. The differentiation of statuses between approve, authorise, and accept; the separation of the archive from the journal; the introduction of the submitted state; and the formalisation of the information protocol all serve to make the governance of information production more precise, more traceable, and more accountable. The 2018 edition described governance in general terms; the DIS 2026 defines the specific acts, agents, and conditions under which governance decisions are made. This, too, I approve.

The third direction pushes towards continuity across the asset life cycle. The elevation of the trigger event, the introduction of the asset-related project (whatever the fuck that is), the redefinition of the CDE as an enterprise-level operational framework, and the formalisation of reference information all serve to extend the framework beyond the project-phase orientation of the 2018 edition into a genuinely life-cycle perspective. Which is fine in theory. The DIS 2026 imagines an appointing party for whom information management is a permanent organisational function, not a project-phase activity that begins when a contract is signed and ends when a building is handed over. This is what I take issue with.

The operational stage of the asset on one side, and the commissioning, design and construction stage on the other, are two separate segments of the market. They operate within different frameworks, use different tools, and employ separate, existing standards. Is this a problem? Yes, of course it is. We’ve seen it multiple times, and we’ve said it in every possible way: the operation and maintenance people, the asset managers, need to be sitting at the table when information requirements are issued to the design and construction time, otherwise we’ll keep working with information that’s just serving a very small segment of the asset lifecycle and facility managers will keep receaving models with which they can wipe their noses at best.

The specificity of the stages, however, needs to be preserved and, if anything, I would have preferred to see the norm further splitting information management in the design stage from information management in the construction stage, because there are specificities in the latter that we aren’t addressing properly. To see everything thrown together and delegated to the asset managers has two effects:

• abandoning the design and construction with very few specifications on how to actually produce what’s needed because, even if it’s true that asset management takes up more resources than anything else, there’s no asset if I don’t fucking build it;
• positioning this norm as a virtual continuation of its weakest chapter, Part 3 of Ed. 2018, and entering uncharted territories that are already regulated by different norms;
• assuming there’s a universal kind of project information manager (whatever that is) and dramatically downplaying the role of coordination.

Even if my concern seems to be concentrated on the third point, the challenge for the market is not whether these directions are correct — because they all are, even number 3 — but whether the transition from the more familiar, more operationally accessible 2018 framework can be managed without losing the adoption momentum that the industry has built over the past seven years. I don’t think it can, and it will take a lot of additional work (and some corner-cutting) to make this digestible.

If I sound worried, it’s because I am.