Create an AIR for Asset Information Requirements

Build an AIR following ISO 19650 - create assets, define requirements, contract with teams and verify models in Plannerly. Step-by-step.

TL;DR

An Asset Information Requirements (AIR) document is not really a document - it is a system. It identifies the assets you need to maintain, defines exactly what information you need to know about them, and acts as the contract for what should appear in the models. This guide walks through building an AIR end-to-end inside Plannerly's Scope and Verify modules, contracting for it, and then verifying that the models that come back actually meet what you asked for. For the broader ISO 19650 workflow, see our ISO 19650 requirements management guide.

Watch: A full walkthrough of creating an AIR in Plannerly - from setting up the list of maintainable assets, to contracting for the information, to verifying the models against your requirements, to producing a COBie-style handover report.

ⓘ
Good to know
The AIR sits beneath the wider OIR (organizational information requirements) - the strategic goals of the asset owner. The OIR explains why you collect information; the AIR translates that into a maintainable list of assets and the specific data you need on each. Get the AIR right early, and you avoid reverse-engineering the handover eighteen months later.

What You Will Build

By the end of this guide you will have a structured list of maintainable assets, a clear set of information requirements against each one, responsibilities assigned to teams, a signed contract for the deliverable, and an automated way to verify the models you receive against everything you asked for. You will also be able to export a COBie-style handover spreadsheet at the end.

This guide covers 6 steps. Work through them in order and you will have a complete AIR workflow, from creation to handover.

Start Step 1 Free Certified Training Courses
Step 1 - Set up your project and understand the AIR

Before you build anything, you need a Plannerly project and a clear picture of what an AIR is for. The AIR is the bridge between the asset owner's strategic goals (the OIR) and the actual information that has to live inside the models.

 Module - Scope and Verify   Output - A new project ready for AIR work 

Video: Creating a free Plannerly project and selecting the Scope and Verify modules.

Required checklist

  • A free Plannerly account at plannerly.com
  • A new project created (the example uses Southbank Business Park)
  • Scope and Verify modules enabled on the project
  • An understanding of the OIR that the AIR will support

1.1 - Create the project

Sign in to Plannerly and create a new project. You only need two modules for this workflow: Scope, which is where the AIR is built, and Verify, which is where models get checked against it. Keeping the module selection focused makes the project easier to navigate later.

  • Use a memorable project name - asset owners often run several AIRs in parallel
  • You can add other modules later if the project grows beyond the AIR
Why this matters: A focused project is easier to govern. Owners and operators tend to come back to the AIR repeatedly across the asset life cycle, so a clean workspace pays off long after handover.

1.2 - Anchor the AIR to your OIR

The OIR defines the strategic goals - why the organization wakes up every morning, what it is trying to achieve with its built assets. The AIR is the practical translation of those goals into a list of maintainable assets and the data you need to manage them. If you can not link a requirement back to an OIR, you probably do not need it.

  • Identify the maintainable assets that drive the OIR (mechanical, electrical, fire safety and so on)
  • Define the key information fields you need per asset
  • Be ready to defend each requirement - "we collect this because..."
Why this matters: Information requirements that are not anchored to a real operational need become noise. The AIR is most useful when every field on it earns its place.
Step 2 - Create your list of maintainable assets and information requirements

There are three ways to build the list - manually, from the buildingSMART Data Dictionary (BSDD), or by importing a CSV. In practice you will usually mix all three. The goal is the same: a structured, classified list of assets, each with a clear set of information requirements and verification rules.

 Module - Scope   Output - A populated list of assets with requirements 

Video: Creating assets manually, importing them from CSV, and defining the information requirements that go with them.

Required checklist

  • An idea of which assets are maintainable on this project
  • Optional - a CSV from the client describing what they need
  • Optional - a project linked to a BSDD dictionary (Uniclass 2015 in the example)
  • A view on the verification rules you want to enforce per requirement

2.1 - Create assets manually

In the Scope module, start a task row for each asset - "heat pump", "storage tank", "air terminal", and so on. If your project is linked to BSDD with a dictionary like Uniclass 2015, typing the asset name surfaces the right entry and adds the classification code automatically. You can ignore the suggestions if you do not need classification, but accepting them keeps you compliant downstream.

  • Use folders (Mechanical, Electrical, Fire Safety) to group assets
  • Drag assets in from the Plannerly library if they are already defined - many come with graphics
  • Use the AI image generator on assets that do not have an icon yet
Why this matters: Classification is what allows different stakeholders to read the AIR the same way. A "pump" can mean almost anything - a Uniclass-coded heat pump can not.

2.2 - Define information requirements with verification rules

For each asset, decide what you actually need to know - manufacturer, system classification, switch voltage, and so on. In Plannerly each requirement comes with a verification rule, so a model can later be checked against it automatically. Rules can be Boolean, numeric, date-based, text patterns, or even AI-generated regular expressions for complex naming conventions.

  • "Any value excluding empty" is a sensible default for free-text fields
  • Use numeric ranges with units (e.g. switch voltage = 120V) where the value matters
  • Let AI generate the regex for naming patterns - you do not have to speak that language
Why this matters: A requirement without a verification rule is a wish, not a contract. The rule is what makes the AIR enforceable later in the Verify module.

2.3 - Import assets and requirements from CSV

If you already have a list - from a client, an Excel template, or a previous project - importing is far faster than recreating it. Plannerly accepts a structured CSV for both assets and information requirements. Download the example template, match the columns, and drop the file into the project. The same approach works for tags, which let you group requirements (mechanical, electrical, COBie) and filter them on the fly.

  • Import the asset list first, then the requirements
  • Use tags so you can later filter "mechanical only" or "COBie only" with one click
  • You can also import an IDS file from buildingSMART if a client provides one
Why this matters: Reinventing the AIR from scratch on every project is one of the biggest sources of waste in information management. A reusable CSV turns it into a starting point, not a six-week exercise.

2.4 - Assign requirements to assets

Once both lists are imported, link them together. Filter the requirements by tag (e.g. "mechanical equipment") and assign them to the relevant assets at the milestone you need them. Repeat for light fixtures, electrical receptacles, cable trays, plumbing fixtures, fire safety, and so on.

  • Filter by tag to keep the list manageable
  • Assign at a milestone - typically Milestone 1 for design intent, later milestones for as-built
  • Skip assets that are not in scope for this project (e.g. lifts and elevators if they are out of scope)
Why this matters: Per-milestone assignment is what makes the AIR work across the project life cycle. Different information matures at different times - the AIR captures that, instead of asking for everything on day one.
Step 3 - Assign responsibilities and create work packages

An AIR is only useful if someone owns each piece of it. Assigning appointed parties (electrical sub, mechanical sub, fire safety designer and so on) and grouping their tasks into work packages is what turns the list into something contractable.

 Module - Scope   Output - Work packages by team, ready for contracting 

Video: Adding an electrical team, assigning responsibilities, and creating a filtered work package.

Required checklist

  • The list of assets with information requirements assigned
  • A view on which discipline (electrical, mechanical, fire safety) owns what
  • A naming convention for work packages

3.1 - Add teams as appointed parties

Click into the team cell on a task and add a new team - "Electrical Sub", "Mechanical Sub", "Fire Safety Designer". Save it as an appointed party so it can be invited and held accountable. You can assign the same team to multiple tasks at once to speed things up.

  • Use clear, role-based team names rather than company names where possible
  • Invite team members to the project so they can collaborate over the activity feed
Why this matters: Appointed parties is the language ISO 19650 uses for a reason - it ties responsibility to a defined role, not a person who might leave the project halfway through.

3.2 - Filter and create a work package

Filter the scope by team (for example, all electrical responsibilities), then create a work package. The package inherits the active filters, so the electrical work package contains exactly the electrical scope. You can save multiple work packages off the same base list - one per discipline, milestone, or contract.

  • Name work packages clearly (e.g. "Electrical Workset")
  • You can switch back to the unfiltered scope at any time
  • Use multiple views to manage complex projects without losing the big picture
Why this matters: Work packages are the unit you actually contract for. Slicing the AIR into focused, discipline-aligned packages is what makes the agreements clean and the responsibilities unambiguous.
Step 4 - Export the agreement and collect signatures

With work packages in place, you can export a clean agreement and run an e-signature workflow against it. Plannerly exports to PDF, Excel, or an IDS file from buildingSMART, with a configurable cover page and signature flow.

 Module - Scope   Output - A signed AIR agreement per work package 

Video: Exporting the electrical work package as a PDF, customizing the cover page, and starting an e-signature workflow.

Required checklist

  • At least one work package created
  • The signatories invited to the project
  • An agreed export format (PDF, Excel, IDS)

4.1 - Export to your preferred format

From the export menu, choose your format. PDF is the most common for an agreement, but Excel works for clients who want a tabular view, and IDS gives you a machine-readable export aligned to buildingSMART's open standards. Configure the cover page, switch to A4 if you need to, and select which sections to include - grid, requirements, details.

  • PDF for the signed contract record
  • IDS for handing over to model authoring tools
  • Excel for client-side review
Why this matters: The format you export in shapes who reads the agreement. A PDF is for signing, an IDS is for software, an Excel is for review. Pick deliberately rather than by default.

4.2 - Run the signature workflow

Once exported, you can either download the PDF or start an e-signature workflow inside Plannerly. Select the signatories from the project members, send the invitation email, and Plannerly tracks the status of every signature. A new cover page with full signature metadata is generated each time someone signs.

  • Signatories must be project members - invite anyone external before starting the workflow
  • Status updates show whether the document is fully approved or still waiting
  • Agreeing on the details inside Plannerly first is preferable - by the time it gets to signing, there should be no surprises
Why this matters: Most disputes during handover come from agreements that nobody really read. A signed AIR with a clear audit trail removes the "we never agreed to that" conversation.
Step 5 - Verify the models against your requirements

Once the assets are being modeled, you need to check that the information you asked for is actually there. The Verify module turns this from a side-by-side document/model review into an automated check across IFC, Revit, or any of the 60+ formats Plannerly supports.

 Module - Verify   Output - Colour-coded verification of every requirement against the model 

Video: Loading an MEP model into the Verify module, linking elements to requirements, and creating a model rule for automated checking.

Required checklist

  • A signed AIR with information requirements
  • One or more models uploaded (IFC, Revit, or other supported formats)
  • An understanding of which property links elements to requirements (name, classification code, etc.)

5.1 - Switch to the model viewer

Open the Verify module and switch to the model viewer. Load the relevant model - in this example an MEP model rather than a structural one, since the AIR is focused on mechanical and electrical assets. The kanban board view alongside it lets you follow each requirement through your own QA statuses.

  • Default statuses cover most workflows - you can rename or add your own
  • One project, many models - load whichever discipline you need to check
Why this matters: The kanban view is where the AIR stops being a static contract and starts being a live tracker - which gives non-modellers a way to see progress without ever opening a model viewer.

5.2 - Link elements to requirements

For each requirement, set up a rule that links it to the matching elements in the model. The simplest rule is "name contains 'mechanical equipment'" or "name contains 'light fixture'". Plannerly counts the matched elements and shows you how many pass, fail, or sit in the middle - green, red, and orange/papaya.

  • Green - the value is present and matches the rule
  • Orange/yellow - the value is present but does not match the rule
  • Red - the value is missing entirely
Why this matters: The colour coding makes the gap between what was promised and what was delivered visible at a glance - which is the conversation you actually want to have at every milestone.

5.3 - Use a model rule for automated linking

Linking each requirement one by one works for small lists, but a model rule scales the same logic across the whole project. Set the rule to "task name = element name" (or "task code = assembly code" if you classify by Uniclass) and Plannerly links everything in one go.

  • Name-based rules are the simplest and work for most demo projects
  • Classification-code rules are more robust on real projects
  • You can mix and match across the same project
Why this matters: Manual linking does not scale. A model rule is what lets you treat verification as a continuous activity instead of a one-off audit.

5.4 - Report issues back to the team

When a requirement fails, raise it from inside the model viewer. Add a comment ("please add manufacturer information"), assign it to the responsible team member, and move the task to a custom QA fix status. The kanban board picks it up automatically, so anyone overseeing the project can see what is pending without ever opening a model.

  • Custom statuses (QA fix, ready for review, complete) reflect your real process
  • Appointed parties only need to look at models when status is "ready for review"
  • Comments and document attachments live on the same task card
Why this matters: The biggest cost on most BIM projects is the back-and-forth of issue tracking. Centralising it on the same task that owns the requirement collapses that loop.
Step 6 - Produce a COBie-style handover report

At the end of the project, the AIR data should be ready for handover. Plannerly generates a structured spreadsheet with tabs for contacts, facility, components, and so on - aligned with COBie if you used a COBie library of requirements, or generic if you did not.

 Module - Verify   Output - A handover spreadsheet ready for the operator 

Video: Adding COBie requirements, generating a handover report, and reviewing the structured spreadsheet output.

Required checklist

  • A verified set of models linked to your AIR
  • Optional - COBie-aligned requirements imported from the Plannerly library
  • A clear scope for the report (which models, which milestones, which teams)

6.1 - Add COBie-aligned requirements (optional)

Plannerly ships with a COBie library of information requirements, named in the typical "sheet.property" format (e.g. "Component.Manufacturer"). Adding these to your AIR keeps the handover aligned with COBie expectations without you having to type them by hand.

  • Use COBie requirements where the receiving operator expects them
  • Mix COBie and custom requirements freely on the same asset
Why this matters: COBie is still the lingua franca of facility handover for many operators. Aligning to it during creation is far cheaper than retrofitting it at handover.

6.2 - Generate the handover report

From the Verify module, create a handover report. Choose which models to include, which requirement types to filter for (all, COBie only, or specific tags), and any team or milestone filters. Plannerly produces a tabbed spreadsheet that pairs the model data with the requirements, in a COBie-style layout.

  • Filter to MEP models if the AIR is mechanical and electrical
  • Filter to COBie tags if the operator wants a strict COBie-only deliverable
  • The report reflects the model state at the moment of generation - re-run after fixes
Why this matters: The handover spreadsheet is the moment of truth - it is the artefact the operator actually uses. If the AIR was set up well, the spreadsheet writes itself.

6.3 - Review what made it - and what did not

The first tabs cover contacts and facility information. Then come the components, with the model data filled in against each requirement. Anything that came back red in Verify will be missing here too. That is exactly the point - the spreadsheet does not lie about what was delivered.

  • Use the gaps as a final QA loop before sign-off
  • Re-run Verify, fix the gaps, regenerate the report
  • Hand over the spreadsheet alongside the models, not instead of them
Why this matters: A handover report that is honest about its gaps is more useful than one that hides them. The AIR workflow is what makes the gaps visible early enough to actually do something about them.

Related resources