An EIR that actually produces a model.

An Employer's Information Requirements document is the single most important piece of paper a developer issues on a BIM project. It is also, almost without exception, the worst-written.

Why generic EIRs produce slop

Most EIRs we receive are eight pages of PAS 1192 boilerplate followed by a sentence that says "models shall be delivered at LOD 400." There is no LOIN matrix. There is no acceptance criteria. There is no schedule of information exchanges. There is, frequently, no clear statement of who the model is for or what decision it is meant to support.

The result is predictable. The consultant treats the EIR as a procurement formality. The contractor treats their inherited deliverables as a contractual obligation rather than a working tool. At handover the developer receives a federated model that nobody can open, populated with parameters nobody can read, and the asset information model that was meant to feed facilities management ends up as a 14 GB file on a forgotten SharePoint.

This is not a software problem. It is a requirements problem. An EIR that does not specify the deliverable in operational language cannot produce the deliverable. Consultants do what the EIR asks them to do. If the EIR asks for nothing in particular, that is what gets produced.

What an EIR is for, exactly

An EIR is a client-side document. The developer or owner writes it (or has it written on their behalf) and issues it to every party tendering for a design or construction appointment on the project. It defines what information the supply chain must produce, in what format, at which milestones, and against which acceptance criteria.

The audience is specific:

• Consultants, to scope their BIM production and respond with a pre-appointment BEP.
• Main contractors, to inherit, augment, and pass down to specialist subcontractors.
• Specialists, to understand what they're producing into a federated environment they don't control.
• Authorities, where municipal submissions reference BIM models (Dubai, Riyadh, increasingly Abu Dhabi).

The EIR is not a technical document for the developer's BIM team to admire. It is an instruction set issued to a supply chain of fifteen or twenty companies who will spend the next two to four years producing information against it. If it is ambiguous, the supply chain will resolve the ambiguity in whichever direction reduces their effort.

Five things every EIR must specify

Strip an EIR back to its job and there are five things it has to nail down. Everything else, process narrative, technology preferences, naming conventions, is supporting material. If one of these five is missing or vague, the EIR cannot enforce delivery.

1. LOIN matrix per discipline

   Level of Information Need, broken out by discipline and by project stage, covering all three dimensions: geometric (LOD), alphanumeric (data attributes), and documentation (drawings, schedules, reports). Without this, "LOD 400" means nothing, it could mean a fully fabricable model with manufacturer-specific data, or it could mean a primitive box with a part number.

2. CDE structure expected

   The Common Data Environment is where information is exchanged, reviewed, approved, and archived. The EIR must specify the platform (or platforms acceptable), the folder hierarchy, the workflow states (WIP, Shared, Published, Archived), and who has access at each stage. "ACC or equivalent" is not a CDE specification.

3. Acceptance criteria and gate reviews

   Every information exchange needs a definition of done. Clash thresholds, model audit reports, parameter completeness checks, drawing register completeness. Without explicit acceptance criteria, the model is "accepted" because the deadline arrived, not because it meets the standard.

4. Information delivery schedule

   A Master Information Delivery Plan (MIDP) or its equivalent, what is delivered, by whom, to whom, at which date, in which format. Tied to the project programme. Without this, deliverables drift to the end of each stage and quality is sacrificed to the calendar.

5. IFC and native handover requirements

   State the IFC schema (IFC 2x3 vs IFC 4), the MVD, the property sets to be populated, the classification system (Uniclass, OmniClass, custom). State whether native files are required at handover, in which versions, with which content. Vague handover requirements are the single largest cause of unusable Asset Information Models.

Common mistakes we keep seeing

Across roughly forty live Gulf projects, the same patterns recur. None of them are subtle. All of them are avoidable.

PAS 1192 boilerplate

An EIR that opens with three pages quoting the (now withdrawn) PAS 1192 standard, references ISO 19650 in passing, and then says nothing about the actual project. Boilerplate is filler. It tells the supply chain that the author has not engaged with the specifics of this project, and the supply chain will respond accordingly.

Unenforceable verbs

"The consultant should consider." "The model may be delivered." "The contractor is encouraged to." None of this is contractually binding. Use shall, must, and will. Anything softer is decoration.

Vague handover requirements

"All BIM models shall be handed over at project completion." In what format? With which parameters populated? Federated or separate discipline files? Linked or unlinked? Are point clouds included? CAD drawings? Vendor cut sheets? This single line, unspecified, can cost the developer six months and a six-figure consultancy fee to retrofit at handover.

No QA cycles

An EIR that lists deliverables but does not specify the QA process before those deliverables are accepted. No model audit checklist. No clash threshold gates. No requirement to demonstrate parameter completeness. Without QA cycles, "delivery" is just the act of uploading a file.

The enforcement question

An EIR is only as strong as its contractual integration. A well-written EIR pinned to a procurement document that doesn't reference it is wallpaper.

The enforcement mechanism has three parts. First, the EIR must be a contractually binding appendix to the appointment, not an aspirational document circulated alongside it. Second, the appointment must reference the EIR in the deliverables clause, with the EIR taking precedence over the supplier's pre-appointment BEP where they conflict. Third, payment milestones must be tied to acceptance against the EIR's criteria, not to calendar dates.

Without these three, the EIR is advisory. With them, it has teeth, non-conformance has a financial consequence, and the supply chain will price and resource accordingly.

A workable EIR outline

Most useful EIRs we've seen, and written, share roughly the same seven-section structure. It is not the only structure, but it is one that works.

1. Project information and BIM uses, what the project is, what the model is for (design coordination, cost certainty, facilities management, authority submission), and which BIM uses are in scope.
2. Information standards and references, ISO 19650 parts in force, classification system, naming conventions, units, coordinate systems. Concise, project-specific.
3. LOIN matrix, discipline by stage, with geometric, alphanumeric, and documentation columns. The longest section. The most important section.
4. CDE structure and workflows, platform, folder structure, status codes, approval gates, access matrix.
5. Information delivery schedule, the MIDP or its equivalent, tied to project milestones.
6. Acceptance criteria and QA, clash thresholds, audit checks, parameter completeness, drawing register requirements, the gate for each information exchange.
7. Handover requirements, IFC schema, native files, AIM structure, parameter sets, classification, and the format in which the project archive is delivered.

Where to start

If you are issuing an EIR in the next quarter, the highest-leverage move is to start with the LOIN matrix. The other six sections can be assembled from templates with relatively little risk. The LOIN matrix has to be written from scratch for every project because it depends on what the model is for, what the disciplines are, and what the procurement strategy looks like.

Get the LOIN matrix right and the rest of the EIR follows. Get it wrong and no amount of boilerplate process documentation will save the deliverable.