Two years after handover, a facilities manager rings the M&E contractor who left site, asking what filter fits the air handling unit on level three. Somebody eventually digs out a ZIP. The right ZIP, probably. Whether the PDF inside describes the unit that was actually installed is a separate question, and nobody on the call can answer it.

That is rarely a facilities problem — it is the last visible symptom of a chain that broke years earlier.

The chain runs like this. Exchange information requirements name what must arrive. Those requirements become information containers. Containers move through the four CDE states. What the site is allowed to build from is the issued set. What the owner runs the building from is the asset register, after a handover that actually happened. Six stages, one direction.

The AECO information lifecycleSix stages in one direction around a ring: exchange requirements, information container, CDE states, issued set, handover, and the asset register. A dashed return marks the next exchange requirements.Six stagesone directionnext EIR01Exchange requirementsNamed deliverables,owners and dates02Information containerA persistent identity,not a file03CDE statesWIP · Shared ·Published · Archive04Issued setWhat the sitemay build from05HandoverPIM acceptedinto the AIM06Asset registerWhat operationswill actually query
  1. 01Exchange requirementsNamed deliverables, owners and dates
  2. 02Information containerA persistent identity, not a file
  3. 03CDE statesWIP · Shared · Published · Archive
  4. 04Issued setWhat the site may build from
  5. 05HandoverPIM accepted into the AIM
  6. 06Asset registerWhat operations will actually query
  7. next EIR returns to exchange requirements
One direction: time and authority. The breaks sit on the arrows, not in the boxes.

How to read it

Clockwise around the ring is time and authority, not software. A file can sit in more than one box if your process is broken; the point of the diagram is that it should not. Each stage has an owner and a test. If you cannot name both, write them down before you open the CDE. The dashed return is the next appointment: the asset register is what the next exchange requirements should have asked for.

The breaks usually sit on the arrows rather than in the boxes: a container never mapped to an exchange requirement, a Shared file treated as Published, an issued set living in a chat group, a handover that turns out to be a USB stick, an asset register rebuilt from scratch. Boxes are easy to decorate. Arrows have to be connected by someone.

1. Exchange requirements

Exchange information requirements (EIR) are the questions the appointing party asks and the appointed party must be able to price. Behind them sit organisational, asset and project information requirements (OIR, AIR, PIR). Nobody needs to recite the acronyms on site. What you do need, for each deliverable, is what it is, when it is due, in what form, and who is allowed to use it.

A requirement that cannot be answered will be ignored, quite reasonably. “Provide BIM” is not a requirement. “Issue the Level 3 ICU coordinated model, IFC 4, suitability S2, five working days before the coordination meeting in week 14” is a requirement. Ask for containers, states and dates a supply chain can price.

Your test: can you point at a list of named deliverables with owners and dates, or are you still waiting for “the BEP” to turn into a register?

2. The information container

An information container is a persistent identity, not a file on a laptop. It has a name that will survive contact with site, an owner, and a number reserved before the first revision exists. The drawing, model or schedule that lands in it is a version of that container. Rename the file and you have broken the identity. Upload final_v3_USE_THIS.pdf into a new folder and you have quietly started a second container.

Naming conventions exist so a gloved hand can find the right sheet in a hut at seven in the morning. If the convention only works in a desktop folder tree, it is not really a convention. Track the container rather than the latest attachment, and most of the downstream arguments get shorter.

Your test: given a container ID, can you produce the current authorised revision and every superseded one, without asking the author?

3. The four CDE states

Work in progress, Shared, Published, Archive. ISO 19650 treats these as states of authority, not folder names.

  • WIP belongs to the task team. Nobody else should be building from it.
  • Shared is for coordination. Other teams may use it to coordinate; they may not treat it as issued.
  • Published is authorised for a stated purpose — tender, construction, a specific package. The purpose lives on the container, not in the email that announced it.
  • Archive holds the superseded and the record copies. It is not a junk drawer. It is how you prove what was current on Tuesday.

If a file can occupy two of those at once without anyone noticing, you do not have a CDE. You have a folder with permissions on it. Suitability codes (S0, S1, S2, A1 and the rest) sit on top of state and say how the information may be used, not merely that it has been uploaded. The document controller’s job here is to refuse the silent promotion: Shared does not become Published because someone printed it and put it on a trestle.

Your test: pick ten containers at random. For each, can you say which state it is in, who moved it, and for what purpose — without opening email?

4. The issued set

The issued set is the Published subset the site is allowed to build from. Not everything in the CDE. Not the last transmittal anyone happens to remember. One set, with a revision, a suitability, and a distribution you can reconstruct afterwards.

Five companies on one package means five inboxes, unless issue is treated as a numbered act: this revision, this purpose, these recipients, this date. Comments sit on that record. Supersede in public. Leaving the old sheet in the cabin and the new one in the model is how two crews end up working to different information.

Your test: can a supervisor on the package tell you, from the system, which revision is current — and can you show the owner the same answer?

5. Handover

Handover is the cut from the project information model (PIM) to the asset information model (AIM). It has no natural owner, which is why it so often has none. Name one before practical completion, or operations will invent a third model.

What was Published for construction is not automatically what operations can query. Commissioning records, O and M content, warranty fields and spare-parts data have to be accepted, not dumped. Progressive handover — validating asset data while the project is still live and the supply chain still has an interest in answering — is the method. A skip at practical completion is how owners end up waiting a year for information they already paid for.

Your test: ninety days before completion, can you list the containers that must survive into the AIM, and who will accept each one?

6. The asset register

The asset register is the operational list: tags, locations, maintainable equipment, the fields a facilities team will actually query. It is not a museum of delivery metadata, and it is not four hundred PDFs in a zip. If it cannot answer “where is this AHU, what is the filter size, and who holds the warranty?”, handover did not finish.

Facilities teams rebuild registers from scratch when the chain broke on an earlier arrow — usually the EIR never named the fields, or the container never carried them, or Published never included them. Start from what operations will query and cut the rest.

Your test: sit with the facilities manager and ask which fields they have ever searched for. Those are the fields the register must hold.

A Monday walk

Print the diagram or keep it next to the register. For one live package, not the whole project:

  1. Find the exchange requirement that named the package deliverables. If it does not exist, write a one-page list: container, owner, date, form, purpose.
  2. Confirm each deliverable is a container with a stable ID, not a filename.
  3. Mark WIP / Shared / Published / Archive on those containers. Move nothing by habit.
  4. Write down the issued set the site is building from this week. If two answers appear, stop and reconcile before you issue anything else.
  5. Ask who will accept the AIM slice of this package, and when.
  6. Check that the assets on the package already have the fields operations will query — tag, location, warranty, maintainable unit.

You will not finish the project in a morning. You will know which arrow is already broken.

Knowing is the easy half. Most of these breaks can only be repaired by the appointing party, at appointment, in writing — and the fixes cost real money in the wrong budget year.

Three are worth the argument. Write the EIR from the facilities manager’s search list rather than from a template, which means getting operations into a room during procurement, before the design team is appointed. Name whoever will accept the AIM in the appointment documents, with the fee to do the work, rather than discovering it at practical completion. And pay for progressive handover as a line item, because asking a supply chain to validate asset data for nothing, after the retention has gone, has never worked.

If your client will not fund any of it, at least make the chain visible. Put the six stages on a wall in the site office with the current package written under each one. A poor substitute for a properly drafted appointment, but it costs an hour and a roll of paper, and it puts the broken arrow where the project manager walks past it.

Read next: What information management means in AECO, and what it does not, A ninety-day information maturity audit you can run without a consultant, The most expensive thing on your project is the document nobody can find.