What is an Asset Information Requirement (AIR)
A client-side guide to defining what asset information you actually need
Overview
An Asset Information Requirement (AIR) is an organisation-level document that sets out the information a client needs to operate, maintain and manage its built assets.
It defines what data is required for every asset type the organisation holds building fabric, mechanical and electrical plant, fire systems, lifts, and so on what format that data should be in, and how it should be structured to work with the organisation's operational systems, typically a CAFM platform.
The AIR is, in practice, the single most important document an estates-owning organisation can produce, and the one most consistently missing. It is the document that determines whether every future project delivers asset data your team can actually use, or another disorganised handover package requiring months of manual rework.
This guide explains what an AIR is, why it sits at the centre of effective information management, what it should contain, and how to develop one if your organisation does not currently have one.
What are Asset Information Requirements?
Under BS EN ISO 19650, the AIR defines the information requirements relating to the operation of an asset, in accordance with the organisation's asset management strategy. In practical terms, it answers a single question: what do we need to know about every asset we own in order to manage it properly?
The AIR is not a project document. It sits above any individual capital project and applies across the organisation's entire estate. A well-developed AIR can be reused, with appropriate adaptation, on every project the organisation undertakes new build, refurbishment, or minor works because the operational information needs of a fire damper or an air handling unit do not change from one project to the next.
In plain english
• The AIR is your organisation's own specification for the data you need to run your buildings.
• It exists independently of any project it describes what your estates and FM teams need
to do their jobs, not what a particular contractor happens to produce.
• Every other information requirement on a project, including the EIR should ultimately trace back to it.
Where the AIR sits in the hierarchy
BS EN ISO 19650 establishes a clear cascade of information requirements, with the OIR at the top.
The critical point is the direction of flow. The AIR should inform the EIR, not the other way round. In practice, many organisations skip the AIR entirely and produce an EIR directly often copied or adapted from a previous project, or a generic template.
Without an AIR behind it, that EIR has no consistent foundation. Different projects end up specifying different
asset data requirements, in different formats, with no organisational standard to check
delivered information against.
The most common mistakes
• Producing an EIR without first developing an AIR is the single most common information management failure among estates-owning organisations.
• It results in asset data requirements being defined fresh, often inconsistently, on every project rather than once, properly, at an organisational level.
• It also means there is no organisational reference point against which to check whether delivered information actually meets operational needs, because operational needs were never formally defined.
Why the AIR matters
It is what makes asset data usable
CAFM systems, maintenance schedules and compliance registers all depend on structured, consistent asset data. A CAFM system populated with data that uses inconsistent naming, missing attributes, or incompatible classification will never perform as intended, regardless of how good the underlying software is.
The AIR is what defines, in advance, the structure that asset data must follow in order to populate these systems correctly so that data delivered from any project, by any contractor, in any year, is consistent with data already in the system.
It removes ambiguity from project requirements
Without an AIR, every EIR has to define asset data requirements from scratch usually by someone without detailed knowledge of how the FM team actually uses the data day to day.
The result is requirements that look reasonable on paper but miss critical operational detail: attributes the maintenance team actually needs are omitted, while data of little practical use is requested because it appeared in a previous template.
It gives you a basis for checking delivered information
At handover, the question that matters is not 'has the contractor delivered something' but has the contractor delivered what we actually need.' Without a documented AIR, there is no objective standard against which to assess this acceptance becomes a matter of judgement rather than a check against agreed criteria.
With an AIR, the acceptance criteria are established before the project even begins, giving the client clear and defensible grounds for rejecting information that falls short.
It protects the organisation when staff change
Asset data requirements are often held informally in the knowledge of a particular estates manager, BIM lead, or FM contractor. When that person moves on, the knowledge goes with them, and the next project starts from a position of uncertainty. A documented AIR captures organisational knowledge in a durable form, independent of any individual.
What should an AIR contain?
ISO 19650 frames asset information requirements across three dimensions: managerial, commercial and technical.
In practice, for an estates-owning organisation, a usable AIR typically addresses six areas.
1. Asset taxonomy and classification
A clear definition of how assets are categorised and classified covering every asset type the organisation manages, from structural elements to individual items of mechanical and electrical plant. This taxonomy needs to align with the structure already used (or intended to be used) in the organisation's CAFM system.
2. Required attributes by asset type
For each category of asset, the specific data fields required. This is the most detailed and most valuable part of the AIR. For example, for an air handling unit, this might include manufacturer, model, serial number, installation date, warranty expiry, maintenance interval, location reference, and associated drawings. Attribute requirements will vary significantly by asset type and by organisation.
3. Data format and delivery method
How the asset data should be structured and delivered for example, as a COBie spreadsheet, a direct CAFM import file, or another agreed format. This section should specify not just the format but the exact field mapping required, so contractors know precisely how to structure data for direct import rather than producing something that requires manual translation.
4. Documentation requirements
The operation and maintenance documentation required to accompany the asset register, O&M manuals, commissioning certificates, warranties, and as-built drawings including how this documentation should be linked to specific assets, named, and structured.
5. Model and geometric requirements
Where a BIM model is required as part of the asset information model, the AIR should specify the level of information need for different asset categories, the model structure expected, and how the model should integrate with non-graphical asset data.
6. Validation and acceptance criteria
How delivered asset data will be checked before it is accepted, completeness checks, format validation, and any automated or manual review process the organisation will apply.
This section gives the AIR teeth: it is what allows the organisation to reject information that does not meet requirements, with clear and pre-agreed grounds for doing so.
Common mistakes with the AIR
1. Not having one at all
The most common situation. Many organisations move directly to writing an EIR for each project, without ever developing the underlying AIR. This results in inconsistent requirements from project to project and asset data that does not align across the estate.
2. Copying a generic industry template
AIR templates are available from various industry sources, but a generic template developed for the sector as a whole will not reflect your organisation's specific CAFM system, maintenance regime or compliance obligations. A template can be a useful starting structure, but it must be adapted, not adopted wholesale.
3. Specifying requirements that are never checked
An AIR is only as useful as the organisation's willingness to check delivered information against it. Where information is accepted at handover without formal validation, the AIR's requirements have no practical effect, regardless of how well they were defined.
4. Treating it as an IT or BIM document
The AIR is most effective when it is owned by the estates and FM function, with input from BIM and IT specialists not the other way round. AIRs developed primarily by technical specialists, without close engagement from the people who actually use the data operationally, tend to specify what is technically elegant rather than what is operationally
necessary.
5. Never updating it
Organisational needs change, CAFM systems are replaced, compliance obligations evolve, and lessons are learned from each project. An AIR that is written once and never revisited gradually drifts out of step with what the organisation actually needs.
Why clients ask Lynefield to support their AIR development
Most organisations find that the people who know what the FM team actually needs are not the same people who can translate that into a structured, deliverable specification and that bridging that gap from the inside is harder than it looks.
Lynefield works exclusively on the client side. We help estates owners develop Asset Information Requirements that are grounded in operational reality, mapped to existing CAFM systems, and written in a way the supply chain can actually deliver against.
If you are preparing for a capital project or recognise that your current asset data requirements are not producing usable information at handover, get in touch
Frequently Asked Questions
What is the difference between an AIR and an EIR?
The Asset Information Requirements (AIR) is an organisation-level document that defines the asset data needed to operate and maintain built assets, independent of any single project. The Exchange Information Requirements (EIR) is a project-level
document, included in procurement documentation, that specifies what information the supply chain must deliver on a particular project.
The AIR should inform the EIR the asset data clauses in an EIR should be derived directly from the organisation's AIR, not written from scratch.
Who should be responsible for developing the AIR?
Ultimately, the AIR should be owned by the organisation's estates or asset management function, since they are the principal users of the information it defines. In practice, development typically requires input from FM and maintenance teams, the CAFM system administrator, and a specialist with BIM and information management expertise who can
translate operational needs into a structured, deliverable specification.
Does every organisation need a full AIR before starting a project?
Ideally, yes but a partial AIR is far better than none. Many organisations develop their AIR iteratively, starting with the most critical asset categories and building it out over successive projects. Even a focused AIR covering life safety systems and major plant gives a project significantly more structure than no AIR at all.
How does the AIR relate to COBie?
COBie is a structured data format commonly used to deliver asset information at handover. The AIR defines what information is needed; COBie (or a direct CAFM import format) is one of the mechanisms by which that information can be delivered. The AIR should specify which delivery format is required, and the precise field mapping the contractor needs to follow.
Can the AIR be applied retrospectively to assets we already own?
Yes, and this is often where the AIR delivers the most immediate value. Once developed, the AIR provides a clear specification against which existing asset data can be audited and improved even where no current capital project is underway. Many organisations use their AIR to drive a structured data cleansing or asset survey programme for their existing estate.
How often should the AIR be reviewed?
There is no fixed interval, but reviewing the AIR after each significant project and a minimum every two years helps ensure it keeps pace with changes to the CAFM system, compliance obligations and lessons learned from recent handovers.
Note: Organisations undergoing a CAFM system change should review their AIR as part of that process, since the target system's data structure directly shapes what the AIR should specify.
Need help turning this into a useable document?
Lynefield helps estates and capital teams develop proportionate information requirements that suppliers can understand, price and deliver. While providing usable deliverables at handover that align with existing systems and processes.
Related Guides
The following guides from the Lynefield Knowledge Hub explore topics covered in this guide in greater depth:
• What is a Digital Twin?
• What are Organisational Information Requirements?
• What is an Exchange Information Requirements document?
• What is a BIM Execution Plan?
• What is COBie?
• Why BIM handovers fail