How the disconnect between EIR definition and MIDP execution breaks data governance—and what that reveals about systems design
ISO 19650 and the emphasis on Employer Information Requirements (EIRs) have driven genuine improvement in how projects define information strategy. Teams now routinely produce structured EIRs, map requirements across project phases, and establish governance frameworks that would have been unimaginable five years ago.
Yet handover remains fragmented. Asset Information Requirements (AIRs) arrive incomplete. The connection between what was required and what was delivered remains elusive.
The issue isn't the standard. It's the execution layer—specifically, the Master Information Delivery Plan (MIDP) and how it actually works (or doesn't) under operational pressure.
There's a useful distinction in organizational theory between espoused theory and theory in use. Projects espouse the EIR-MIDP-AIR framework. In practice, something different emerges.
The MIDP—the contractor's operational response to the EIR—is typically defined during mobilization. It maps who delivers what, when, and via which systems. It's structured. It's often comprehensive.
Then execution begins. And the MIDP encounters reality.
Design changes happen outside the scope of the defined workflows. Site assurance becomes non-standard, requiring improvisation. Subcontractors work to their own rhythms. The pace of delivery creates cognitive load that makes adherence to planned governance frameworks genuinely difficult—not because teams are negligent, but because attention is finite and pressure creates rational triage of process rigor.
The result: data lives in the systems the MIDP specified, but it's not connected to the requirements structure defined in the EIR. The artifact exists (inspection records, design documents, delivery notes). The audit trail doesn't.
The conventional response is to demand better discipline: stricter governance, clearer approval workflows, more audit oversight.
This misdiagnoses the problem. The issue isn't that teams lack discipline. It's that the systems designed to maintain the EIR-MIDP-AIR connection are reactive, not preventative. They catch errors after they've been made. They force manual reconciliation between systems. They require individuals to maintain linkages that should be structural.
Consider an example from a recent project: design specifications were stored in the CDE. Inspection records were logged in a site management system. Change requests went through email and shared drives. At handover, the team needed to trace which design decisions had been verified through inspection. That required pulling data from three separate systems and manually matching it. Eight hours of reconciliation work for a single activity category.
This wasn't a failure of understanding. It was a failure of system architecture. The systems weren't integrated. There was no structural link between the design record and the verification record. So the connection had to be made manually, retrospectively, at the point when pressure was highest.
This distinction is crucial. Most projects operate with reactive governance:
Preventative governance does the inverse:
The difference matters under pressure. When teams are busy, reactive systems fail. The overhead of manual linkage and retrospective reconciliation becomes unaffordable. So teams stop doing it. Preventative systems, by contrast, remain effective because compliance is built into the workflow, not imposed on top of it.
The gap between EIR definition and AIR delivery isn't a knowledge problem. Teams understand what needs to be delivered. The gap is structural: the systems and processes designed to connect requirements through execution don't hold under operational reality.
Addressing this requires rethinking the MIDP not as a document, but as a data architecture problem. The question isn't "How will we manage information?" The question is "How do we design systems so that information management is effortless during normal execution?"
This means:
There's an asymmetry in how the industry treats data maturity. Advanced analytics, generative design, AI-enabled planning—these capture attention and investment. Data governance, by comparison, is seen as maintenance work.
But the reverse hierarchy should apply. You cannot meaningfully apply advanced analytics to messy, unlinked data. You cannot build reliable AI models on incomplete audit trails. The foundational work—getting data structured, linked, and governed—is prerequisite to everything else.
This is what Grace Newey from AtkinsRealis emphasized in recent discussions: "We need to balance disruptive innovation with incremental innovation. Getting the basics right. Focusing on information management and how we roll that out through projects. Disruptive innovation will trickle down as a result, but only if the foundation is solid."
The irony is that solving the EIR-MIDP-AIR connection isn't expensive. It doesn't require new technology in the abstract. It requires a different approach to system architecture—one that treats data governance as a structural property, not a compliance layer.
The construction industry has made genuine progress on requirements definition. EIRs are more structured. Standards are more widely adopted. The planning layer works better.
The next frontier is execution integrity. Not more documents. Not stricter governance through process discipline. But system design that makes the EIR-to-delivery connection structural, not optional.
When that happens, ISO 19650 frameworks don't just exist on paper. They function operationally. Requirements don't just survive planning—they persist through delivery and arrive at handover intact.
eviFile | Digital Delivery Platform