Spoiler: this isn’t about files and formats. It’s about choices.

In BIM (Building Information Modelling) we fall in love with technology fast. But if data isn’t born to answer specific decisions, it stays as elegant choreography. That’s where the OIR → AIR → EIR trio makes the difference. For clarity: OIR (Organizational Information Requirements), AIR (Asset Information Requirements), EIR (Exchange/Employer’s Information Requirements). Think of a funnel: at the top sits organizational strategy, then we drop to the assets we manage, and finally to the projects that bring information to the table. If you grasp the flow, you stop asking “more detail” and start asking “which detail, for whom, and when”.

One enterprise OIR, AIR per domain, EIR per project

Start with the OIR. It’s not a digital shopping list: it’s an enterprise document that states the outcomes to achieve and the risks to control. It’s one at organizational level (even if it holds ten different outcomes) and it speaks the management language: safety, business continuity, sustainability, budget.

From the OIR come the AIR. Here things get concrete: for each asset class (healthcare, schools, residential, …) we decide which data is needed across the lifecycle, with what LoIN (Level of Information Need), who updates it and in which systems it will live: AIM (Asset Information Model), CMMS (Computerized Maintenance Management System), BMS (Building Management System), IoT (Internet of Things) or an EDMS (Electronic Document Management System).

Finally, the EIR, which are per project/appointment: they specify exchange purposes, formats, naming conventions, validations and milestones. They’re not a “copy‑paste” of the AIR: they’re its operational translation inside a tender/contract context, timeline and responsibilities.

Strategy → OIR (single) → AIR (by asset class) → EIR (by project) → BEP/PGI → Models/IC → AIM/O&M

Where BEP (BIM Execution Plan) and PGI (Piano di Gestione Informativa – Information Management Plan) are the contractual actuators; IC (Information Containers) are the minimum units handled in the CDE (Common Data Environment); O&M (Operations & Maintenance) is the operational phase. Skip one step and you’ll feel it: generic EIR, overloaded models, an AIM that ages badly. Respect the chain and the BEP stops being a dusty PDF and becomes an actuator.

Case 1: Healthcare — two projects, one AIR

The organization: a healthcare operator with an OIR that reads (simplified): “patient safety”, “continuity of critical systems”, “energy efficiency”.

Healthcare AIR:

• traceability of critical systems (unique IDs, certifications, non‑conformity history);
• reliability (MTBF – Mean Time Between Failures / MTTR – Mean Time To Repair, spares, SLA – Service Level Agreement for interventions);
• energy (nominal/actual consumption, metering points, sub‑meters), with attention to HVAC – Heating, Ventilation and Air Conditioning systems.

EIR Rome: IFC – Industry Foundation Classes models with an agreed property set, COBie – Construction‑Operations Building information exchange sheets for equipment/spaces, PDF/A documents with metadata. In the CDE the checks block sharing if key properties are missing or naming is wrong. Milestones are tied to commissioning and pre‑opening.

EIR Florence: same AIR, different work packages and calendars, codifications adapted to site context and contractors. Same score, different arrangement.

Outcome: at opening, the AIM isn’t a museum of files: it’s a system that answers audits, maintenance and energy planning.

Case 2: Schools — same OIR, a new AIR

The organization is the same, the OIR doesn’t change. The domain does.

Schools AIR: fire safety and accessibility as a mantra; for typical spaces (classrooms, labs, gyms) define minimum properties on capacity, uses, equipment, evacuation routes, due dates for periodic inspections; for HVAC systems, the actual performance and maintenance plans.

EIR Milan: IFC models oriented to spaces/occupants, integration with digital evacuation plans, deliverables aligned with the school calendar.

EIR Turin: same schools AIR, but local energy requirements, municipal accessibility specs, summer delivery packages.

Outcome: repeatability without rigidity. EIR change per project; the mindset doesn’t.

Why it pays off (also on the balance sheet)

With a well‑linked OIR → AIR → EIR chain you cut rework (validations catch errors before they spread), cut ornamental data (leaner models, useful information), and reduce risk (audits, recalls, liabilities). Most of all you build an AIM that doesn’t need rebuilding on each project: it feeds itself.

The pitfalls I’ve seen (and how I dodged them)

• Starting from EIR as a list of formats or, worse, “Dx” labels: you don’t define purposes or quality. Go back to the OIR and write information uses.
• Asking for high LoIN “just in case”: then no one updates. Better less, but relevant and maintainable.
• Keeping the information standard and protocol out of contracts: the CDE turns into a shared folder. Add rules, not only permissions.

How to start tomorrow morning

1. In 90 minutes collect three measurable outcomes and three risks for the organization: that’s your OIR draft.
2. Pick one asset class (healthcare or schools) and write the minimum info profile: mandatory properties, LoIN, update responsibility → that’s your AIR.
3. For the next project, build one EIR with clear exchange purposes, explicit formats/versions and validation rules that the CDE can apply. If it isn’t automatable, it isn’t a standard: it’s a wish.

---

Practical note: none of this replaces the standards (ISO 19650, UNI 11337), but it stops you from using BIM as a label. Start from why, write what, then define how and when to exchange it. The order of words is the order of value.

Appendix: to plan deliveries, deploy MIDP (Master Information Delivery Plan) and TIDP (Task Information Delivery Plan); if integration is via services, specify API (Application Programming Interface) as well as file formats. To measure results, use QA (Quality Assurance) and don’t forget ROI (Return on Investment).