Subscribe
Share
Share
Embed
Reimagining AEC is Dr Sepehr Abrishami's independent podcast on how the built environment handles information. Each episode takes one subject from digital construction, from the ISO 19650 series and the common data environment to the golden thread, soft landings and the arrival of artificial intelligence in design and surveying practice, and tells it as a single argument built on the published standards, guidance and evidence. Sepehr is a researcher and former architect who leads the Centre for AI in Construction and teaches building information modelling at master's level. The episodes are written for postgraduate students and practitioners who want the reasoning behind the rules, not a summary of them.
Some lines in a client's environmental policy reach a contractor's appointment, and others stay where they were written. The researcher following one of them here is me, Dr Sepehr Abrishami, and my research covers building information modelling, or BIM, and the circular economy. The line in question commits the client to halve its energy consumption by 2030, measured against 2015. The show is Reimagining AEC, and this episode follows that commitment through a client's information requirements.
Take an example that Guidance Part D of the UK BIM Framework, published in 2021, uses to show the risk of vague requirements. A main contractor, appointed as a lead appointed party, plans to set out the building digitally on site, taking dimensions straight from the geometrical models. That plan never appears in the information requirements it gives its designers. Without that knowledge, the designers produce traditional setting-out drawings. In the guidance's words, they end up wasting time, money and effort creating drawings that are not required. The failure lay in a requirement that nobody wrote down.
The policy line from the opening faces the same danger on a larger scale. In the guidance, the line belongs to a client called Organisation X, the subject of its worked examples. Organisation X is fictional, so every detail of it is illustrative, and the energy commitment is the first line of its environmental policy. That line states a real need, and it is a long way from anything a contractor could price, produce or prove. So the question is how a client turns a purpose like that into requirements precise enough that a provider knows what to deliver and the client can check what arrives.
By the end you should be able to explain why requirements start with whoever receives information, and to tell apart the four types of requirement in the ISO 19650 series: organisational, asset, project and exchange information requirements, known as OIR, AIR, PIR and EIR. That includes setting project requirements from the points ISO 19650-2 asks a client to consider, writing exchange requirements with purposes, structure, acceptance criteria and a level of information need, and judging whether a finished set is fit to issue. My source throughout is that guidance, Developing information requirements, edition two, edited by David Churcher, Sarah Davidson and Anne Kemp and published in February 2021. Since May 2025, nima, formerly the UK BIM Alliance, has maintained that framework as the IMI Framework, named after the Information Management Initiative. We will go in four steps: why requirements come first, then the three high-level types and their timing, then exchange requirements, where Organisation X's policy becomes deliverables, and last, how much information to ask for and what weakens a set of requirements.
The first step begins with a claim the guidance makes plainly: without information requirements there is no information management process. What makes it true is direction. In the familiar order, an information provider generates information and shares it, and an information receiver uses it to carry out some action. The guidance turns that order around, and the reversed sequence has three moves. First, the receiver, which the guidance also calls the specifier, works out the purposes for which it needs information. Second, it defines its requirements and communicates them. Only then, third, does the provider know the scope of what to produce. Most people on a project play both parts at different times. This is why ISO 19650-2, for the delivery phase, and ISO 19650-3, for the operational phase, both open with assessment and need in clause five point one. The guidance states the rule directly. You should not provide someone with information unless they have told you what they require.
Breaking that rule produces two opposite problems. The first is risk, which comes from asking too vaguely. Where requirements are imprecise, providers fill the gaps with their own assumptions, and errors can push programme and budget past their limits. The setting-out drawings belong here. The second is waste, which comes from asking too broadly. Clause five point six point two, in both ISO 19650-2 and ISO 19650-3, is explicit about not generating wasteful information. The guidance's example is thermal analysis. A client should not ask for thermal analysis information unless someone will carry out thermal analysis. It may still need evidence of thermal performance to support operation, which is a different purpose, and it is then for the delivery team to define what its own analysis needs. Risk and waste lead to one discipline. Ask early, ask precisely, and ask only for what you will use.
Asking precisely needs a shape for each requirement, and the guidance gives one with two levels. The high level is the purpose, the day-to-day reason the information is needed, and it always comes first. The detailed level is the information itself, described across four facets. The first facet is purpose again, the need the information fulfils, such as conveying the fire performance of elements. Content has a summary, such as a fire strategy, and a breakdown across objects, such as a wall carrying a fire rating property. Form is how the information is presented, as a drawing or a schedule, for instance. Format is how it is encoded, for example as a portable document format file, or PDF, or as an Industry Foundation Classes file, or IFC. A client need not fill in every facet. It might specify a fire strategy by its content summary alone and leave the rest to the delivery team. For a topographical survey, by contrast, it might ask for the building, the car park and the access routes, shown as a drawing, in PDF. So the first step closes with a principle: the receiver's purpose drives everything, and the facets describe what it needs.
The second step goes to the top of the hierarchy and works down. Think of four layers, with the flow running from strategy to appointment. At the top sit organisational information requirements, which are strategic. They describe what an organisation needs to run its business across all its assets. On the layer below sit two high-level types side by side. Asset information requirements serve the operation of assets. Project information requirements serve the key decisions on one design and construction project. Each feeds a detailed type on the third layer. Asset requirements feed exchange information requirements for the operational phase, and project requirements feed exchange information requirements for the delivery phase. Together these form a master set. On the fourth layer, the master set is filtered for each appointment and met when the appointed party delivers its part of the information model. Detail grows as you move down, and every layer traces back to a purpose above it.
Organisational information requirements, or OIR, are explained in clause five point two of ISO 19650-1 and clause five point one point two of ISO 19650-3, and they are the starting point for all information management. They cover the high-level information an organisation needs across its whole portfolio and its departments, from finance to facilities management. The appointing party defines them as part of running its business, not as part of any project. The guidance suggests taking high-level activities from Annex A point two of ISO 19650-3, such as maintenance and repairs or asset operations, and asking why each needs information. The answers fall into three groups: to meet the organisation's own objectives and policies, to satisfy stakeholders and regulators, and to run everyday business tasks. The guidance adds a warning. A list of such activities, copied into exchange requirements, tells a provider nothing. Organisation X writes three OIR from its environmental policy. One is the energy target. A second commits it to showing reduced embedded carbon per cubic metre in new developments, and a third to evidencing sustainable sourcing of materials for them. On its own, the energy target still tells no contractor what to deliver.
Asset information requirements, or AIR, take that organisation-wide view and apply it to particular assets. They are explained in clause five point three of ISO 19650-1 and clause five point one point four of ISO 19650-3. The appointing party creates them, led by its own asset and facilities management team where it has one, and they must be in place before any related appointment. The guidance asks organisations to settle what they need in use before what they need from projects, because the in-use phase is where information is used longest. Organisation X turns each of its three OIR into an AIR. Halving energy use becomes a rule that every new built asset achieves an energy performance certificate, or EPC, rating of A. Reduced embedded carbon becomes an embodied carbon value below the corporate benchmark for that type of asset. Sustainable sourcing becomes a rule that all wood comes from sustainable sources. Each of these can now be tested. Information is exchanged to meet them whenever exchange requirements under ISO 19650-3 are answered.
Projects need a parallel set. Project information requirements, or PIR, are explained in clause five point four of ISO 19650-1 and clause five point one point two of ISO 19650-2. Like OIR they are high level, and they identify the information the appointing party needs at its key decision points, the moments when it must make an informed decision. There is only one set per project. Part of it already exists in the OIR, such as statutory requirements or corporate delivery policies. The rest is added at inception, before any consultant or contractor appointment goes out to tender. The sources fall into two kinds. Some come from what the client already knows about itself, such as its corporate key performance indicators, or KPIs, and its business case, with tests like value for money and affordability. Others come from the project: its strategic brief, its stakeholders, such as local residents, and the tasks the client must carry out itself. Organisation X adds one PIR from its strategic brief, which supports local workforces: eighty per cent of its sub-contractors should be based within a thirty-mile radius of the site, with evidence at information delivery milestones four, five and six, which are the dates set ahead of decisions when information falls due. Keep those three milestones in mind. The client need not issue a separate document called PIR.
What the client does need is a way to arrive at them, and clause five point one point two of ISO 19650-2 lists seven points to consider. The guidance treats the list as a tool with no required order, to be worked through alongside strategic project management. Its points come down to two concerns. The first is what the project is and who needs information from it. That covers the scope, meaning what is being built, why and to what objectives, and the purposes of different departments and stakeholders. The second is how and when decisions will be made. That takes in the plan of work, which sets the stages, and the procurement route, which changes how information flows, in design and build compared with alliancing, for example. It also takes in the number of key decision points with the decisions to be made at each, and the plain-language questions that become KPIs. A question such as whether the energy performance is acceptable becomes a measurable indicator. For the plan of work, the guidance pointed to editions that have since been replaced. The current references are the Royal Institute of British Architects, or RIBA, Plan of Work 2020, and the British Standard BS 8536 of 2022, which replaced Parts 1 and 2 of BS 8536.
Decisions then need dates, and the guidance plans them backwards in four moves. It starts with the key decision point, such as whether the project is viable enough to proceed, or which contractor to appoint. ISO 19650-1 could be read as tying decisions to the end of a work stage, but the guidance points out that decisions can fall at any time, and clause five point one point three of ISO 19650-2 asks for them to be mapped at the start. Working back from each decision, the client sets its information delivery milestone, a number of weeks before, for example. Each exchange requirement then sets the actual exchange dates, and one milestone may need several exchanges. Last comes acceptance. The provider submits into the workflow of the common data environment, or CDE, and the exchange is complete only when the receiver accepts the information, so the review period in clause five point seven point four has to be built into the dates. Organisation X's sub-contractor evidence at milestones four, five and six sits on this timeline. That closes the second step: strategy translated for assets and for one project, and every exchange dated backwards from a decision.
The third step reaches the appointment, where purposes become a specification that can sit in a contract. Exchange information requirements, the EIR, specify the information a lead appointed party or an appointed party must deliver at each information exchange. They are detailed enough to be written into the contract, and the guidance describes them as the information part of the employer's requirements. ISO 19650-1 explains them in clause five point five. In the delivery phase, clause five point two point one of ISO 19650-2 covers the appointing party's EIR for each lead appointed party, and clause five point four point three covers the lead appointed party's EIR for its own appointed parties. ISO 19650-3 mirrors this for the operational phase and labels its version separately, so the two are not confused. EIR work before an appointment and during it. Before, they help select the party best able to deliver. During, they specify exactly what each exchange must contain, they let systems be mapped in advance, which improves interoperability, and they give the basis for checking compliance. Every appointment needs them, whether or not a model is involved.
EIR also cascade, through four levels. At the top, the appointing party develops one master set for the project. Next, it filters that set into a tailored EIR for each appointment, so a project with several appointments has several EIR. Then each lead appointed party takes the EIR it receives and, under clause five point four point three, combines them with its own requirements to form the lead appointed party's EIR. At the bottom, that set is filtered again for each appointed party in the delivery team, so each receives only what applies. Annex A point six of the guidance shows why the lead's own layer matters. A main contractor using offsite manufactured components needs to know how they can be lifted safely. It adds its own EIR, asking the design consultant and the manufacturer for a time sequencing analysis of delivery and installation, and for manufacturer information, during RIBA stage four. The client never asked for any of this, because the purpose belongs to the contractor.
Inside each EIR the guidance identifies three building blocks: purposes, structure and acceptance criteria. Purposes come first, and at this level the guidance treats each purpose as a small system with inputs, a process and outputs, linked to the next purpose by an information exchange. Its worked chain begins with authoring, the primary purpose, which produces the design model. The first exchange, which the guidance labels EIR B, carries what an energy analysis needs, namely the spaces as symbolic volumes with their areas, volumes and occupancy, the real-world coordinates of the site, and the energy ratings of elements, delivered as an energy analysis model in IFC. The analysis, which the guidance labels coordination analysis, then produces the outputs for the second exchange, EIR C. These are the building's energy use per year, options, carbon output and choices of utility provider, set out in an operational cost report in PDF. At the end of the chain, the receiver makes its decision. The same pattern would serve Organisation X's energy target. It also explains why the guidance criticises labels such as 4D, 5D and 6D. They are umbrella terms that say nothing about the information required.
Purposes overlap, so the second building block is structure. The guidance recommends building EIR purpose by purpose into one master set, then filtering the result by appointment. An EIR that is not specific to its appointment undermines the contract and loads providers with information that is unnecessary, duplicated or contradictory. Consistency comes down to two things. One is a single vocabulary. A consistent schema and classification system has to cover the objects, anything from a pump to a whole facility, their attributes and properties, and the information containers that hold them. Naming shows the trap. If one purpose asks for a property called OccupancyMax and another asks for MaxOccupancy, the same data is requested twice. The other is tools that hold the vocabulary together: linked tables or a database to keep the relationships intact, and open standards such as IFC, so teams can reuse their methods across projects. The guidance cited an earlier edition of the IFC standard, and the current edition is ISO 16739-1 of 2024.
Structure makes checking possible, which brings in the third building block, acceptance criteria. They tell the provider how its delivery will be judged, and where structured information has been specified, the guidance says they can become automated rules. The rules come from project-wide or asset-wide resources that the appointing party establishes under clauses five point one point four to five point one point six of ISO 19650-2, among them the information standard and the information production methods and procedures. Beyond checking that the information arrived, the rules test three things. First, that the information is correctly constructed, with the right syntax, case, spelling and delimiters. Second, that its metadata, such as value type and units, is correct. Third, that each value meets its defined value or range. The guidance also asks for supporting information, and suggests giving tenderers examples of what is expected rather than blocks of text copied from standards.
Here Organisation X's policy arrives at the contract, with its Safety, Health and Environment Department as the receiver and each requirement ending as a deliverable with a provider and a date. Three of them come from the AIR, so they are EIR for the operational phase, even though they are delivered during a new build project. For the energy target, the design team or the main contractor must show at every information delivery milestone that the design meets the EPC A rating for regulated energy use, in an energy report that includes the EPC value, and must supply the EPC certificate and a carbon report at handover. Embodied carbon is compared with the corporate benchmark at each milestone too. Wood sourcing is proved by Forest Stewardship Council, or FSC, certification at handover. The fourth deliverable comes from the PIR, so it is an EIR for the delivery phase. The main contractor reports at milestones four, five and six on the distance between each sub-contractor's base and the site, with calculations showing that more than eighty per cent are based within thirty miles. Every one is a PDF report or certificate. That resolves the third step. EIR are built from purposes, held in one structure and judged by stated criteria.
The fourth step deals with quantity. A requirement can name the right purpose and still ask for too much or too little, and the level of information need is the framework that controls this. It replaced an older UK approach. Under PAS 1192-2, a Publicly Available Specification since superseded by the ISO 19650 series, the level of definition combined a level of detail and a level of information, with metrics from one to seven describing geometry and data. The numbers were too generic to check automatically, and detached from purpose. The guidance's example is an air terminal specified at level four during construction, with no purpose stated and no mention of the sound frequency, sound pressure or manufacturer that were needed. ISO 19650-1, in clause eleven point two, introduced the level of information need instead, a framework for the quality, quantity and granularity of information, defined by purpose. The guidance pointed to BS EN 17412-1 of 2020, which has since been withdrawn and replaced by BS EN ISO 7817-1 of 2024. Anything beyond the minimum a purpose needs is waste, and both over definition and under definition carry risk.
Defining the level of information need builds on the facets from the first step. The appointing party states the purpose first and then, only where they apply, three kinds of information. Geometrical information covers detail, dimensionality, location and appearance. In Annex A point six, the main contractor with the offsite components asks for component assemblies in three dimensions, at real-world coordinates, with the positions of the lifting hooks shown. Alphanumerical information means properties, with their type and units. Annex A point two follows Organisation X's maintenance and repairs. There a spreadsheet based on Construction Operations Building information exchange, known as COBie and described in Guidance Part B of the UK BIM Framework from 2020, needs no geometry at all. It needs named properties for doors and pumps, such as manufacturer, model and installation date, plus an acoustic rating for doors, with metadata giving the value type and units, thirty-five decibels, for example. Documentation means documents linked to objects, so a pump carries its operating instructions and its manufacturer information.
Three practical matters remain: who sets it, when, and where it is recorded. The appointing party defines the level of information need for each deliverable, and if it lacks the skills to do so in detail, it must at least define the purpose. ISO 19650-1 lets it seek help from a prospective lead appointed party or an independent third party, while avoiding conflicts of interest. The guidance's example is an asset owner that must report embodied carbon to the building authority and defines only the purpose, embodied carbon analysis. As for timing, the whole definition should be made at the start of each appointment rather than changed part-way, although it can grow from one appointment to the next. A quantity surveyor may need only the number of occupants for an order of cost estimate at feasibility, and the gross internal floor area later for cost planning. And the framework is written into three places: the information standard, the EIR and the task information delivery plans.
The guidance condenses the method into five steps in two halves. The first half settles why and who. You summarise each EIR and its information purpose, then collate the purposes, naming who receives and who provides, and set the information delivery milestones. The second half settles what. You sort the deliverables into structured and unstructured information. Structured information is machine-readable and can be queried, as databases, models and spreadsheets can. Unstructured information, such as drawings, reports, images and video, needs a person to interpret it. For both kinds, you tabulate how each deliverable is presented, with its content summary, form, format and exchange date. The guidance does this with Uniclass 2015 classification codes and adds content comments wherever it expects more than a typical provider would deliver. Organisation X's site location plan, for example, must show its wider estate marked out in blue. Finally, for structured deliverables, you define the geometrical, alphanumerical and documentation content and the metadata, using the level of information need.
A sound method can still fail through weak wording. The guidance closes its first part with a checklist, and the faults it warns against fall into two groups. The first is wording that specifies nothing. A statement that requirements must reflect the UK BIM Framework, or the outdated term BIM Level 2, gives a provider nothing to deliver against, and a client that names delivery software without a purpose encroaches on the delivery team's remit. The second is wording that hides what matters. Long lists of obvious requirements bury the critical ones, so where industry practice already sets a generic group of information, the requirement should simply reference it. And where some purposes are still unknown, the client should deal with the known ones and say plainly that others may follow. Behind both groups sits a point about skills, because the people doing this work must be able to break information down using standard schemas and classification. The guidance then offers one test for a whole set of requirements. Put yourself in the provider's place, and ask whether, if you had to provide this information, you would know what you had to deliver.
That brings the argument together, so return to Organisation X and its commitment to halve energy use by 2030. The answer to the opening question is a chain of four translations, each narrower than the last and each tied to a purpose. The OIR state the target as the business sees it. The AIR make it testable, as an EPC A rating for every new built asset, with matching rules for embodied carbon and timber. The PIR add what the project must decide, and when, including the local supply chain target with its evidence at milestones four, five and six. The EIR then give every requirement a provider, a format and a milestone, filtered for each appointment and cascaded down the supply chain, while the level of information need holds each request to what its purpose needs. The contractor's setting-out method never entered such a chain, and its designers drew for nobody.
Three things are worth carrying into your work. Begin every requirement from the receiver's purpose, and treat a request with no purpose behind it as waste. Plan exchanges backwards from the decisions they serve, and leave room for review, because an exchange is complete only when it is accepted. Write structured requirements in one consistent vocabulary, with a level of information need and acceptance criteria, so that what arrives can be checked, by software where possible.
For reading, start with Guidance Part D and its worked examples in Annex A, alongside ISO 19650-1 and ISO 19650-2, both of 2018, ISO 19650-3 of 2020 and BS EN ISO 7817-1 of 2024. One note on currency. In March 2026, nima reported that revised drafts of ISO 19650 Parts 1 and 2 had gone out for consultation, so check the clause numbers when new editions appear. The episode on tendering and appointments follows EIR out to tender, the episode on information delivery planning shows how delivery teams plan to meet them, and the episode on open data, buildingSMART and COBie goes further into structured handover information.
Organisation X's policy was read here one line at a time, as far as the contracts it should reach. I hope, as Dr Sepehr Abrishami and as host of Reimagining AEC, that you give a policy from an organisation you work for or study the same reading.