When standards are not aligned, the model becomes the place where unclear requirements, unpaid effort, and downstream expectations collide.

From my experience, the clash usually does not happen because ISO 19650, internal standards, drafting standards, IFC, COBie, or data standards are wrong. The clash happens because they are solving different problems, and projects often treat them as if they are the same thing.

As I see it, ISO 19650 asks for managed, purposeful, exchangeable information. Internal standards often produce project documentation. IFC expects structured, mappable data. COBie can help structure asset and facility information so it can be checked, exchanged, and reused when it is entered and governed properly.

Those are related, but they are not the same.

A design firm may have a clean Revit template, good sheets, proper title blocks, solid view templates, disciplined drafting rules, and reliable internal QA/QC workflows. From my perspective, that does not automatically mean the model contains structured asset data that can survive IFC export, COBie extraction, handover, validation, or long-term reuse.

This is where I think the real gap begins.

Owners, operators, facility managers, vendors, sub-trades, software platforms, and data teams may expect structured information that was never clearly defined, priced, governed, validated, or included in the delivery process. I am not only talking about ISO 19650, IFC schema, MVDs, or software interoperability. I am talking about whether the information need was properly identified, scoped, assigned, produced, checked, accepted, and maintained.

At the same time, I can see why designers may push back. Asking a designer to restructure internal business rules, Revit templates, parameters, naming conventions, classification methods, family libraries, schedules, export settings, and QA/QC workflows can affect time, cost, liability, and profitability. That work is not free. It changes how the designer produces information, how the team checks information, and how risk is carried.

I used to think that if a model was delivered, the information was mostly there. I do not see it that way anymore.

Many internal standards are built to support drawing production and project delivery. They help teams issue coordinated drawings, maintain consistent sheets, follow company naming rules, organize views, manage annotations, and produce schedules. Those standards matter. But they are not always data standards, and they are not always written for downstream reuse by another organization.

That is an important distinction.

A model may be delivered to an owner or another organization as a Revit project file, but the internal logic of that model does not automatically transfer. The receiving organization may not understand the original browser structure, worksets, view templates, shared parameters, family naming, schedule setup, filters, internal abbreviations, or QA/QC assumptions. The authored model is technically received, but the production logic behind it may not be reusable.

This creates a second level of information loss.

Extracting data from a model is one option, but that extraction can become static. Sometimes I think we focus too much on the export and not enough on the model as a reusable dataset. If the real reuse is tied to the authored model itself, then the model’s internal structure becomes part of the dataset. In that case, the issue is not only whether information can be exported to IFC, COBie, or spreadsheets. The issue is whether the authored model can be navigated, understood, trusted, maintained, and reused by another party after delivery.

This is where internal standards and ISO 19650 can come into tension.

ISO 19650 expects information to be managed through defined requirements, responsibilities, exchange processes, review states, and acceptance criteria. But from my perspective, if the project only defines file deliverables and does not define the reusable information structure, the receiving party may inherit a model that looks complete but is difficult to use.

IFC can help with open exchange, but IFC does not fix unclear information requirements. COBie can help structure facility and asset data, but COBie does not fix missing governance. MVDs can help define a specific exchange view, but they do not decide what the owner actually needs. Internal standards can support production, but they do not automatically support external reuse.

I can see why someone would say, “We already have a BIM standard.” In many cases, that is true. The issue is whether that standard supports only internal production or whether it also supports downstream information use.

The burden appears when one standard is expected to do the job of another.

If an owner expects lifecycle asset information, that expectation must be defined early. If a vendor or operator needs specific data, that data must be assigned to the correct party at the correct stage. If IFC or COBie is required, the project must define mapping, validation, and acceptance criteria. If a native model is expected to be reused, the project must define what “reuse” means beyond simply handing over the file.

Without that clarity, the project creates hidden costs.

The designer may be asked to become a data miner. The BIM manager may be asked to clean up inconsistent parameters. The contractor may be asked to complete missing asset information. The vendor may be asked to populate fields that were never part of procurement. The owner may receive a model that appears useful but requires significant effort to validate, translate, or rebuild into an operational dataset.

That is not a technology problem alone. From my experience, it is a scope, governance, and delivery problem.

The key point is this:

A drafting standard can make drawings readable.
An internal BIM standard can make production consistent.
IFC can structure model exchange.
COBie can structure asset and facility information.
ISO 19650 can manage the information process.

But none of them automatically guarantee useful, reusable information unless the project defines what information is needed, why it is needed, who provides it, when it is required, how it is checked, and how it will be reused.

As I see it, the clash is not really ISO 19650 versus IFC, or IFC versus internal standards. The clash is between downstream expectations and upstream delivery realities.

If structured information was never defined, priced, governed, validated, or included in the delivery process, then the cost does not disappear. It simply moves to someone else later.

That cost shows up as rework, manual cleanup, failed exports, unusable handover data, broken schedules, duplicate parameters, unclear asset ownership, and models that cannot be confidently reused.

A stronger approach is to align the layers:

The owner or organization defines the information purpose.
ISO 19650 defines the management process.
The project information standard defines the rules.
The design and engineering teams define how they will produce the information.
Drafting standards define how drawings will be presented.
IFC, COBie, and other data exchanges define how information will be transferred and validated.

When those layers are aligned, standards support each other.

When they are not aligned, standards become competing obligations, and the model becomes the place where every unclear requirement, unpaid task, and downstream expectation collides.

This is only my perspective, but I think this is where many BIM standards discussions need to mature: away from simply asking for more information, and toward defining the right information, at the right time, from the right party, for the right purpose.

AI-Assisted Writing Note

This article reflects my practitioner perspective, professional experience, and original ideas. AI tools were used to help refine wording, structure, and presentation, but the opinions, interpretation, and perspective remain my own.

Steven Spry
BIM Specialist | Founder, BIMxcel Inc.