A practitioner’s view on why drawings are more than graphic output — and why structured handover starts with the information teams already create.

Drawings = Data: The COBie Perspective

From my experience, one of the most important shifts in BIM is understanding that drawings are not just drawings.

Drawings are data.

That does not mean every drawing should become a spreadsheet. It does not mean every line, note, tag, symbol, and schedule needs to become a database record. But from my perspective, drawings already contain a large amount of structured project information. The issue is that we often treat that information as graphic output first and reusable data second.

A room schedule is not just a drawing table.

A door schedule is not just a sheet annotation.

An equipment schedule is not just something placed on a drawing set for review.

Those schedules contain information that someone may need later for construction, commissioning, handover, operations, maintenance, reporting, or asset management.

As I see it, this is where the COBie perspective becomes useful.

COBie Is Not Just a Spreadsheet

Many people first experience COBie as a spreadsheet. That can make it feel like an administrative task, a data-entry burden, or a handover requirement that appears too late in the project.

From my perspective, COBie is better understood as an information exchange method — a defined view of the project information needed for handover, much like the logic behind a Model View Definition, where only the information required for a specific purpose should move forward.

That matters because owners do not operate drawings. They operate spaces, systems, equipment, components, warranties, maintenance information, and asset records.

Drawings may describe those things. Models may contain those things. But unless the information is structured, checked, and delivered in a usable format, the owner may still receive a handover package that is difficult to trust or reuse.

In practice, COBie exposes the gap between project documentation and operational information.

COBie as an Information View of the Model

From my perspective, COBie is also useful because it forces the industry to think in terms of a specific information view, not the whole model.

In simple terms, this is close to the idea behind an IFC Model View Definition. A model can contain a lot of information, but not every use case needs all of it. A defined exchange view helps identify the subset of information needed for a specific purpose.

That is how I tend to look at COBie.

COBie is not asking for the entire model. It is focused on the information needed to support handover and operations. It is a way of saying: from the larger project information environment, this is the information view that matters for this purpose.

That distinction is important.

The value is not in exporting everything. The value is in defining the right exchange, for the right use case, at the right point in the process.

What Are Owners Asking For That Is Not Already in the Drawings?

This is where I think the conversation needs to become more honest.

Owners often ask for better data, better handover, better asset information, and better operational readiness. That is fair. But from my perspective, the first question should be:

What are owners asking for that is not already somewhere in the drawings, schedules, specifications, submittals, or commissioning records?

Riddle me that.

The issue is not always that the information does not exist. In many cases, the information exists, but it is buried in human-readable documents, disconnected schedules, inconsistent model parameters, PDFs, or project records that were never structured for reuse.

A door may already be in the drawing.

A room may already be in the room schedule.

A piece of equipment may already be in the mechanical schedule.

A system may already be described in the drawings and specifications.

A finish may already be listed.

A panel, valve, pump, AHU, fixture, or device may already be documented somewhere.

So the better question is not always, “Can we create more data?”

The better question is:

Can we retain, structure, validate, and reuse the information we are already producing?

In my view, the owner’s real ask is often not “give me more data.” It is “give me the information you already created in a form I can trust, validate, and use.”

Each Phase Is Not a Silo

From my perspective, it is too easy to describe the project lifecycle as a set of silos. Owner, project manager, designer, contractor, commissioning team, and operator are often discussed as separate groups with separate priorities.

There is some truth to that, but I do not think it is the full picture.

Each phase is not a silo. Each phase is part of the process. The issue is not that each group has a different role. The issue is that the information created in one phase is not always retained, structured, or prepared for the next phase.

Designers do what designers are supposed to do. They design. They coordinate. They produce drawings, schedules, models, and design intent. Contractors do what contractors are supposed to do. They plan, procure, build, coordinate, install, and confirm work in the field. Owners and operators carry the building forward after the project team leaves.

None of those roles is wrong.

The problem begins when the information produced by each role is treated as temporary project output instead of part of a larger information chain.

From my experience, when downstream use is considered early, the work does not necessarily need to be done twice. A schedule created for drawings can also become a better data source if the required fields, naming rules, and validation expectations are understood from the beginning. A model element can support design documentation and future handover if the right information is structured at the right time.

This does not mean designers should carry every future operational requirement without scope, fee, or governance. That would be unfair and unrealistic.

It means that when the downstream information need is clearly defined, priced, governed, and built into the process, the same work can create more value. Information can be authored once, checked once, and retained through the lifecycle instead of being recreated later by someone else.

As I see it, the goal is not to turn every phase into the same phase.

The goal is to make sure useful information does not fall apart between phases.

Drawings Are Human-Readable. Operations Need Machine-Readable Information.

Drawings are excellent at communicating intent to people.

They organize geometry, annotations, schedules, references, and notes in a way that designers, contractors, reviewers, and owners can understand. Drawings are still critical. I am not suggesting that drawings are obsolete.

But from my experience, drawings alone are not enough for modern information delivery.

A facilities team does not want to manually read through hundreds of sheets to find asset information. A database does not understand a note unless the information is structured. A dashboard cannot reliably report on equipment if the required fields are inconsistent. An AI workflow cannot reason properly from unclear, duplicated, or poorly governed data.

That is why I keep coming back to this idea:

Drawings are data, but not all drawing data is ready for downstream use.

The information needs to be structured.

It needs to be governed.

It needs to be validated.

It needs to be delivered with purpose.

COBie Reveals Whether the Data Is Actually Managed

In my view, COBie is useful because it does not let teams hide behind the appearance of completeness.

A drawing set may look complete. A model may look coordinated. A schedule may look organized. But once information needs to be exchanged in a structured way, gaps become obvious.

Is the space information consistent?

Are assets named clearly?

Are components connected to the right systems?

Are required fields actually populated?

Are values duplicated or inconsistent?

Is the information tied to an operational purpose?

These are not just technical questions. They are business process questions.

That is where I think many organizations struggle. They treat COBie as a technology problem when it is often an information management problem.

From Drawing Production to Information Delivery

The drawing process asks:

Can this be issued?

Can this be coordinated?

Can this be reviewed?

Can this be built?

The information delivery process asks additional questions:

Can this be checked?

Can this be exported?

Can this be mapped?

Can this be trusted?

Can this be reused?

Can this support operations?

Can this support automation or AI?

That is the shift.

Drawings remain important, but they are no longer the only deliverable that matters. The information behind the drawings is becoming part of the deliverable.

This is why “Drawings = Data” is not just a slogan. It is a practical reminder that project information has value beyond the sheet.

The COBie Perspective Should Not Create Data Gluttony

There is also a risk here.

Once people understand that drawings contain data, they may want to capture everything.

That is where data gluttony begins.

From my perspective, COBie should not be treated as an excuse to collect every possible attribute. The point is not to make the model heavier or the spreadsheet larger. The point is to identify the information that has operational value and deliver it in a structured way.

Not every note belongs in handover.

Not every attribute needs to be maintained.

Not every model element should become an asset.

Not every field creates value.

The better question is:

What information does the owner actually need to manage, maintain, operate, report on, or reuse?

That question should shape the information requirements.

Not All Data Has the Same Lifecycle Value

This is where value assessment becomes important.

Can anyone quickly tell the warranty end date for a piece of equipment? Can they identify which assets have motors, which valves may need replacement, or which components are critical to operations when something fails?

That type of information can matter a great deal to an owner.

It may matter more than collecting low-value details that are not actively managed, maintained, or used. For example, warranty dates, replacement dates, motor information, valve data, access requirements, and maintainable asset records may have more lifecycle value than capturing every possible attribute for door hinges, wayfinding items, or other lower-priority information.

That does not mean those items are never important. It means their importance should be determined through a proper value assessment.

From my perspective, the question should not be, “Can we capture this data?”

The better question is:

Does this information support lifecycle value for the owner?

If the answer is yes, then the information should be defined, structured, validated, and connected to the drawings, schedules, models, and handover process. If the answer is no, then it may become data clutter.

This is why structured data needs to match the drawings and the owner’s operational priorities. The drawing may show the equipment, valve, door, device, or system, but the useful handover value comes from knowing which information needs to follow that item into operations.

A proper process should identify which assets matter, what information is required, who is responsible for it, and when it should be verified.

That is where COBie, information requirements, and practical value assessment come together.

The goal is not to collect everything.

The goal is to retain the information that has real lifecycle value.

Closing Thought

Drawings are still essential.

But drawings are no longer just drawings.

From my experience, the real value is not only in what the drawing shows. It is also in the information the drawing carries, the structure behind that information, and whether that information can support decisions beyond the drawing set.

The strongest digital delivery workflows do not erase the differences between project phases. They respect each phase while making sure useful information is retained, structured, and carried forward instead of recreated later.

The most useful BIM data is not the data that is easiest to collect; it is the data selected because it supports lifecycle value, owner decisions, maintenance, replacement, warranty, and operational use.

COBie helps make that visible.

It shows that handover is not only about issuing documents. It is about delivering usable information.

That is where BIMxcel focuses its work.

BIMxcel helps organizations connect BIM standards, drawing information, model data, schedules, business rules, and handover requirements so project information can become more structured, more purposeful, and more useful.

Because better digital delivery is not about producing more information.

It is about making the right information usable.

Credit and Acknowledgement

My knowledge and perspective on this topic are strongly credited to studying under Bill East through COBie Academy and learning from Shawn O’Keefe. Their guidance has shaped how I understand COBie, information exchange, structured handover, and the practical difference between producing data and producing usable information.

Without that guidance, I would likely be in the same pool as many others trying to understand COBie only as a spreadsheet or a project requirement, rather than as a disciplined way to think about information delivery and lifecycle value.

Source Note

This article is written from my practitioner perspective. It does not reproduce COBie specification content. For formal COBie requirements, definitions, and implementation details, readers should refer directly to recognized COBie sources such as the National Institute of Building Sciences, Whole Building Design Guide, buildingSMART COBie resources, COBie Academy, and published COBie work associated with Bill East.

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.