Somebody writes "COBie required" into the exchange information requirements. Eighteen months later, a fortnight before practical completion, a coordinator exports every object the model still contains into a workbook roughly the size of the building it describes. A consultant is brought in to clean it. An owner's information manager opens the first sheet on a Monday, finds forty thousand rows and a horizon of blank cells, closes the laptop, and from that day the word itself means punishment. Search for help and the top results will cheerfully teach you the click-path for the export button without ever mentioning what the schema was for.
COBie is not a spreadsheet. It is a schema, and the workbook is only one way of writing it down.
What it actually is
COBie — Construction Operations Building information exchange — is a specification for handing asset information from the people who designed and built a facility to the people who will run it. It is a filtered view of the project information model: the maintainable assets, the spaces they sit in, the types they belong to, the systems they serve, the documents that prove them, and the jobs and spares that keep them going. Geometry is beside the point. A photorealistic air-handling unit that nobody can find, warrant or inspect is not a handover deliverable, however good it looks in the flythrough.
Think of it as the cut from project information to the asset register operations will actually query. The schema says which classes of fact must travel, and how those classes join. A facility contains floors. Floors contain spaces. Spaces can be grouped into zones. Installed things are components. Components belong to types. Types and components can belong to systems. Attributes hang off those rows when somebody has named them. Documents point at evidence. Jobs and spares describe the labour and the parts the operator will need at two in the morning in February. Contacts say who is still answerable once the site hut has gone.
The joins are the product. Without them you have lists. With them you have a register a stranger can interrogate: this tag, this space, this type, this warranty, this certificate. That is roughly the sequence a maintenance supervisor runs through anyway, standing in front of a failed unit with a phone in one hand, and it is worth remembering that the schema was built around that moment rather than around a review meeting.
The workbook everyone dreads is a serialisation. SpreadsheetML was chosen so that a facilities manager without authoring software could still open the exchange, read a row and reject a blank — which, at the time, was a reasonable and rather generous thought. Later US work carries the same schema in IFC and in JSON. UK practice commonly still asks for COBie 2.4; US practice has moved through the National BIM Standard toward COBie V3. Those files are not interchangeable, but they are versions of one idea: structured asset information at handover.
British practice wrote that idea into BS 1192-4:2014, and the UK national annex to ISO 19650-4 still points at COBie 2.4 as the usual exchange. ISO 19650 itself talks about the project information model becoming the asset information model, and this is one disciplined way of performing that cut. It is not a certification, not a maturity badge, and no substitute for saying what asset information you actually require. The information problem behind all of it is plain enough: operations need structured facts about the things they will run, joined tightly enough to be found.
The sheets are classes, not a homework pack
A typical workbook is a set of named tables. Facility, Floor, Space, Zone. Type, Component, System. Attribute, Document. Job, Spare, Resource. Contact, plus a handful most jobs never honestly fill in. Picklists constrain the allowed values, and an instruction sheet explains how to read the rest. The names matter because they are classes, not tabs to be colour-coded the week before handover.
Type is the catalogue row: the kind of thing, the manufacturer and product where known, expected life, the shape of the warranty, the recommended spare, the maintenance interval that applies to every instance of that kind.
Component is the instance: this unit, this serial, this tag, this space, this install date. A component without a type is an orphan. A type with no components is a brochure.
System is how the operator thinks about the building — the domestic cold water, the smoke control, the landlord's incoming power — rather than the work package that happened to install it.
Attribute is the named extra somebody asked for in the asset information requirements. It was never intended as a landfill for every parameter a family happened to be carrying.
Document is a pointer that has to keep resolving long after the laptop that authored it has been wiped: the data sheet, the certificate, the operation and maintenance extract, the warranty wording.
Job, Spare, Resource and Contact are the sheets that get left for last and usually stay that way, which is a shame, because between them they answer who to ring, what to order and how long the work takes. They are also the sheets an operator opens first.
When a dump puts a wall, a length of duct and a fire damper in the same Component list, the schema has already been abandoned. Likewise when every instance invents its own type name and the Type sheet is empty, or when Attribute runs to five hundred columns of which ninety per cent are blank. Sheets are not the problem. A workbook that no longer means its own joins is.
Where the trauma comes from
Not Excel. A schema applied once, at the end, to data nobody validated, for an owner who never said which facts they intended to query.
It gets asked for as a format rather than a need. The exchange information requirements say "COBie required". The asset information requirements never named the objects, attributes, documents or systems. The supply chain therefore prices a file, not a register, and at the end it delivers precisely that.
It is end-loaded. Design and installation ran for years with no type list, no tags recorded at inspection, and a space schedule the operator would not recognise. Practical completion then demands a complete workbook. People who left the job in year two are emailed about serial numbers. The labour is real; the contemporaneous fact is gone. You can export a model. You cannot invent the nameplate nobody photographed.
The authoring tool dumps the model, not the assets. Every wall, every fitting, every placeholder family becomes a row. Required fields are blank because they were never what the model was for. Spaces do not match the room numbering the facilities team has used for a decade. Components do not match the tags riveted to the plant. The coordinator did what the button offered, which is not what the schema asked for.
The Attribute sheet becomes a skip. Custom parameters, leftover manufacturer data, units that disagree, enumerated values typed out as prose. Volume looks like diligence in a review meeting. Nobody can query volume. A supervisor can query a short list named in advance: fire rating as installed, filter size, incoming supply, inspection access, warranty end date.
Documents die. The cell holds a path on somebody's hard drive, a filename that was never issued, or a link into a common data environment the operator has no login for. A document row that does not open is a caption.
Someone cleans it. A consultant, or more often a junior with forty thousand rows and a deadline, deletes the walls, invents types, copies serials out of a PDF and produces a file that looks tidy on screen. Tidy is a reconstruction. Facilities find that out in the first cold snap, when the unit that has failed is not the unit in the register — which is why so many teams end up rebuilding the asset register from scratch. The handover data did not survive the trip into the maintenance system.
The versions do not match. A UK job specified 2.4; a later plugin produces a V3 export. Picklists differ, required columns differ, and a month disappears into an argument about the wrapper while the assets stay blank.
Nobody can ingest it. The owner asked for COBie because a standard said so. The maintenance system, the facilities platform and the warranty tracker were never mapped. Acceptance becomes "file received", and the operator types the plant list in by hand. It did not fail as a file. It failed as an exchange.
That is the trauma: weeks of effort, a file too large to reason about, a register nobody trusts, and a perfectly sensible piece of vocabulary that now makes people flinch.
What a receiving owner needs
Not a workbook the size of the model. A register they can operate from on day one, and evidence they can still find in year five.
They need identity. Every maintainable asset carries a stable identifier the site already uses — tag, serial, location — not a model element identifier that dies at the next file upgrade. Someone new to the building should be able to find the thing from the row, and the row from the thing, without ringing the coordinator who has since moved to another job and does not remember the numbering.
They need type, then instance. What kind of thing it is, who makes that kind, how it is maintained, what warranty attaches; then the facts true only of this one — space, system, install date, serial.
They need spaces the operator already recognises. If the room schedule, the fire strategy and the cleaning contract all use one naming convention, handover does not get to invent a second.
They need the attributes they named, not the attributes the family contained. Enough to inspect, isolate, replace and prove. Level of information need is the same sentence in another doorway: purpose first, content second.
They need documents that open from project custody — data sheet, test certificate, operation and maintenance extract, warranty wording, residual-hazard note. The pointer has to outlive the laptop.
They need jobs and spares only where they will be used. A Job sheet cloned from a manufacturer's whole library, covering assets nobody will ever touch, is noise. A Spare sheet naming the filter the plant genuinely takes is worth an afternoon.
They need completeness they can test without hiring anybody. Every component has a type. Every required attribute is filled or explicitly not applicable. Every required document resolves. Systems are populated. Contacts still exist as people. A document controller ought to be able to fail a drop against those tests on their own authority, because "looks like COBie" has never been a test.
If the honest sentence is "we will map it into the register later", later has a habit of becoming the twelve-month handover: an owner waiting a year for data already paid for while someone reconstructs the list from PDFs.
A Monday diagnosis
You do not need a new appointment to work out whether this job is running a schema or heading for a punishment.
- Find the sentence that asked for COBie — exchange information requirements, asset information requirements, execution plan, contract appendix. Note whether it names objects, attributes, documents, systems and a version, or only the word.
- Open the latest workbook, or the latest promise of one. Count the Component rows, then count how many of those a facilities supervisor would actually maintain. The gap is the dump.
- Take five maintainable assets you can walk to — a plant item, a life-safety device, a door closer, a switchboard, a terminal unit — and produce for each the Component row, the Type row, the Space, one required Attribute and one Document that still opens. Twenty minutes an asset is plenty.
- Ask whether a stranger could reject the file against a written test — missing type, blank required field, dead document — without convening a meeting. A shrug is the diagnosis.
- Ask the person who runs the maintenance system whether they have ever loaded a COBie drop as received. If they retype, the exchange has already failed and everyone has been polite about it.
Five assets will tell you what you need. You are not certifying anything; you are finding out whether the schema was applied to the things operations will query.
Three things people wish were true
That a native model, an IFC file and a COBie workbook are interchangeable. They are different serialisations at different grains, and swapping one for another at handover is how blank Type sheets travel undetected.
That delivering the file is the same as delivering the asset information model. A platform that can export a workbook but cannot answer "this tag, this space, this certificate" is still producing a dump with better formatting.
That the word on the transmittal does the work. It does not. Schema first, spreadsheet second, and the owner's query — the one they will type at two in the morning in February — deciding both.
The receiving owner who wrote "COBie required" is the one who can stop the dump. Name the objects, attributes, documents, systems and version in the asset information requirements, and pay for those facts to be captured while people are still on site. That costs a specified register and the tagging and photographing nobody usually budgets; it does not cost a format line in the exchange information requirements.
Refuse the workbook as handover until a document controller can fail it against a written test on their own authority, and until the person who runs the maintenance system has said they can load it as received. If they will still retype, you have bought a file.
Read next: Progressive handover: validating asset data throughout delivery, Writing asset information requirements the supply chain can price, The twelve-month handover: why owners wait a year for data they already paid for.