Information Requirements in BIM: OIR, AIR, PIR, EIR
Explains common BIM information requirement layers and how they help teams ask for the right information at the right time.

Information only — not legal advice.
Information requirements describe what a recipient needs to know to make a decision or perform an activity. They work best when they identify the purpose, delivery point, responsible producer and acceptance test—not merely a list of file formats.
“Provide BIM” is difficult to price, deliver or verify. “Provide a usable asset register for the maintainable equipment before operational acceptance” is a starting point that can be made specific.
Connect business needs to exchanges
In ISO 19650 terminology, organisational information requirements (OIR) relate to organisational objectives; asset information requirements (AIR) relate to asset operation; project information requirements (PIR) relate to project delivery; and exchange information requirements (EIR) specify information for an appointment's exchanges.
The important task is to maintain the connection between a business need and a deliverable. These are not four templates to complete independently. In older material, EIR may mean “Employer's Information Requirements”; check the terminology used by the actual contract.
Write a requirement that can be tested
For each exchange, record:
- The recipient, decision and intended use.
- The objects, systems or locations covered, including exclusions.
- Required geometry, data and supporting documents.
- Definitions, units, permitted values and identification rules.
- Delivery milestone, format and relevant schema or version.
- Producer, reviewer and acceptance criteria.
Include dependencies: a supplier's final serial numbers cannot be confirmed before the installed equipment is known. Plan interim information and final confirmation separately.
Example: maintenance information for pumps
A fictional operator needs to plan maintenance for each installed pump. The agreed exchange requires a unique asset identifier, location, manufacturer and model, serial number, commissioning date, maintenance instructions and the relevant warranty document.
Acceptance checks confirm that identifiers are unique, locations match the agreed building structure, mandatory values are not placeholders, document links work for the operator and a sample can be imported into the receiving asset system.
The team also defines who verifies the data against the installed equipment. Passing a file-format check does not establish that a serial number belongs to the real pump.
Use automated checks where they fit
buildingSMART IDS allows suitable information requirements for IFC to be expressed in a computer-interpretable form. It can support repeatable checks of specified objects and information.
Other checks still require suitable tools and competent review: geometry, engineering adequacy, document usability and correspondence with the installed asset. An IDS result should state what was tested rather than imply that the entire delivery is correct.
Test the requirement before the deadline
Run a small exchange early. Ask the producer to create a representative package and the recipient to use it. Ambiguous field definitions, unsupported exports and unusable document links are easier to resolve before hundreds of assets are populated.
Control changes to requirements. Record the reason, cost and programme implications, approval and the deliveries affected. Adding a field at final handover can require substantial rework if nobody collected it earlier.
For a deeper explanation, see the UK BIM Framework guidance on developing information requirements. Continue with level of information need and asset handover.
Important information
This article provides general information and does not constitute legal advice or replace a qualified professional's assessment of your circumstances. Laws, official guidance, standards and product features can change. Check current primary sources and the requirements applicable to your jurisdiction, contract and project before making decisions. Examples illustrate the discussion; they are not official rulings or instructions for a particular case. For legal decisions, consult a qualified lawyer; for technical or other specialist matters, consult the responsible professional.
Enable JavaScript to use reading progress and usefulness ratings.
