MEP Engineers: Specify for Operations, Not Just Construction

Your MEP specifications are complete.

Performance requirements: ✓

Equipment schedules: ✓

Installation requirements: ✓

Everything needed to install the correct equipment, but there’s something missing. The specification that tells anyone what was actually installed and where to find it six months from now. You already know this information. The contractor will know it during installation. But if you don’t specify how to capture it, it disappears into fragmented sources, and your client will spend years compensating for that loss.

The Fragmentation Problem

During construction, fragmentation is functional:

  • Electrical contractors need electrical information
  • Mechanical contractors need mechanical information
  • Controls contractors need controls sequences
  • Everyone works in their discipline, installs correctly, moves on

This is how construction works. This is how it should work.

But what construction naturally fragments, operations needs consolidated.

That chilled water valve isn’t just a plumbing component, it’s part of the HVAC control strategy. That controller isn’t just an electrical device, it manages sequences across multiple systems. Every sensor exists in both physical space and logical control relationships.

The facility manager trying to optimize performance or respond to a failure needs to understand these relationships. But by the time they take over, the information is scattered across:

  • Electrical as-builts
  • Mechanical submittals
  • Controls vendor documentation
  • Commissioning reports
  • Equipment schedules (if they’re lucky)

Different sources. Different formats. Different levels of detail. Different accuracy.

The facility manager faces a choice: spend significant effort recreating this consolidated view, work without it and accept the performance penalty, or simply give up and work around the missing information.

Most choose option three.

What Gets Lost

Not the design intent, that’s in your drawings and specifications.

What gets lost is clear indication of what was actually installed.

You specified a control valve. The contractor installed a Belimo valve, model number EQB24-SR, serial number 47821, mounted in the mechanical room on level 3, wired to controller MAC address A4:C3:F0:2B:1D:8E, controlling chilled water flow to AHU-5.

All of that information exists briefly during installation and commissioning. The electrical contractor knows where they mounted the controller. The mechanical contractor knows which valve they installed. The commissioning agent tested the sequence and confirmed it works.

But unless you specify how to capture this information in a consolidated format, it fragments immediately:

  • Controller location: maybe in electrical as-builts
  • Valve model: maybe in mechanical submittals
  • Control relationship: maybe in commissioning report
  • System context: in your head, and nowhere else

Recreating this information represents significant effort. Or it simply never gets recreated, and the fidelity is lost forever.

Why Engineers Don’t Currently Specify for Operations

Let’s be honest about the structural problem: operations teams aren’t decided upon during the design phase, typically.

They’re not part of the design process. They’re not interviewed as stakeholders. They’re a different budget, a different phase, a different problem. By the time they show up, your work is done.

So you specify for construction, the stakeholders who are at the table.

There may also be an assumption that specifying for operations would require more effort on your part, or would add complexity and cost to the construction process.

This could not be less true.

In fact, engineers benefit significantly from consolidated commissioning data. It gives you better information about what was actually installed, not what you specified, but what’s in the building. You can use that to:

  • Track post-construction performance
  • Support future commissioning work
  • Feed better data into your next project
  • Demonstrate actual outcomes to clients

And with the right tool, this doesn’t add complexity or time to the construction process. Contractors are already capturing this information, they’re just capturing it in fragmented tools and formats. The costs of capturing it in a consolidated platform are negligible and inline with the efforts they’re already doing. You’re not asking them to do more work; you’re asking them to do the same work in a format that doesn’t evaporate.

The information already exists during construction. The question is whether you specify that it gets captured in a usable format, or whether it evaporates into fragmented sources.

What Engineers Can Specify

You can specify a manufacturer-agnostic and system-agnostic platform to track what devices were installed and where.

This should include:

  • Common unique identifiers for each device
  • Physical location (room, space, access panel)
  • Logical relationships (what it controls, what controls it)
  • Key datasets (model numbers, commissioning data, network addresses)

Timing matters: This needs to be specified during the specification phase, early enough that contractors select the platform and capture data during installation and commissioning. If you wait until substantial completion, the information is already gone.

Format matters less: The critical requirement is that information can be exported and used across multiple platforms and applications. It shouldn’t be locked in a vendor-specific system or a static PDF.

The key aspect to specify is the functionality to capture this information during installation and commissioning phases such that it can be shared.

Not just delivered at turnover. Captured progressively as the work happens.

The GLAR Approach

GLAR (GreenLight Asset Register) is a proven, field-friendly platform that does exactly this.

It’s designed to be:

  • Manufacturer and system agnostic – works with any equipment, any vendor
  • Field-friendly – contractors can capture data during installation without disrupting their workflow
  • Operations-focused – consolidates information into a single source of truth
  • Export-ready – delivers data in formats that work across applications and platforms

When you specify GLAR (or a platform with equivalent functionality), you’re ensuring that:

  1. Contractors capture device information as they install
  2. Commissioning agents validate and enrich that information
  3. Operations receives a consolidated view at turnover
  4. You receive better feedback on what was actually installed

The client benefits most: Reduced costs from not having to recreate or compensate for missing information. Immediate operational capability instead of months of information archaeology.

But you benefit too: Better information shared back to you about what was installed. Future commissioning opportunities. Performance tracking that feeds into your next project. At minimum, demonstrated commitment to delivering value beyond construction completion.

The Action for Engineers

Add one specification requirement:

“Contractor shall capture and maintain device-level information (equipment identification, location, system relationships, and key technical data) in a manufacturer-agnostic, exportable platform throughout installation and commissioning phases. Platform shall be accessible to owner and design team. Complete consolidated asset register shall be delivered at substantial completion in exportable format compatible with common facility management systems.”

That’s it. One specification requirement that ensures the information you already know, that contractors briefly possess, gets captured in a format operations can actually use.

A slightly more involved approach would be to define the agnostic platform in the general requirements section and ensure that every specification section providing devices in the building includes the paragraph above with reference to the general requirement that defined the tool to be utilized by all contractors.

The Bottom Line

You’re specifying for construction because construction is at the table during design. Operations isn’t.

But construction naturally fragments what operations needs consolidated. Unless you specify otherwise, that fragmentation becomes permanent, and your client pays the price for decades.

You can consolidate at specification what construction will fragment during installation.

It doesn’t require more effort from you. It provides better information back to you. And it demonstrates something increasingly rare: engineers who think beyond construction completion to actual operational success.

The operations team wasn’t at the table during design. But you can specify what they’ll need anyway.

Closing

Six months after substantial completion, when the facility manager needs to understand what that controller actually does and where to find it, your design intent drawings are irrelevant. What matters is whether someone specified that this information should be captured and delivered in a usable format.

That someone is you.

Share article

Related Articles

Why Manual Consolidation Is Draining Your Resources, And How to Fix It The true cost of fragmented as-built documentation extends far beyond...

No. But you do need to know what you have, where it is, and whether it’s vulnerable. Let’s address what’s happening right...

The handover from project teams to operations teams in construction is a critical moment. Still, it’s often riddled with problems, especially when...