Somebody is walking the plant rooms with a phone, photographing nameplates. It is the month before practical completion, the mechanical subcontractor demobilised a fortnight ago, and folders named Final have started appearing on the server. A COBie workbook is being filled in the evenings from those photographs and a walk.

Most of us have worked that fortnight. The awkward part is not the effort, which is considerable, but that the building described in those files is not quite the one installed — and nobody finds out for about a year.

Sequence the same work differently and it costs fewer hours, not more. Validate the asset data while delivery is still producing it: a tag on the thing before the first check, an inspection and test plan instance recorded against that tag at every hold point, and a draft O and M that closes when the package closes. The owner then inherits a register that was live while the job was live. The twelve-month wait is what refusing that costs, and end-loaded COBie is how the refusal usually shows up on a programme.

Acceptance and information travel together

Progressive does not mean more meetings or a workshop bolted onto week eighty. It means each accepted slice of the works leaves behind a validated slice of the asset information. If a package is complete enough to be valued and paid, it is complete enough to be queried: which assets, which records, which draft operating information.

Handover on that method is a state rather than an event; practical completion confirms what is already queryable instead of inventing it.

The last-month dump inverts that order. Delivery happens, quality happens, and then somebody manufactures an asset information model out of whatever still opens. The pack looks industrious — thousands of files, a great deal of unpaid evening — but its facts are late. You buy the building twice, once in the works and once in the typing.

Validation is a join, not a filing job

Validation is not "the PDF landed in the right folder". A folder can be immaculate and still say nothing useful about the thing an operator will maintain in February. The test is whether a stranger to the job can start from an asset and retrieve its identity, its quality history and its draft operating information, and find the three agree.

Four questions, asked while the installer is still on site:

  1. Identity — does this maintainable thing have a tag, on the casing and in the register, that will survive the client renaming every room on level two?
  2. Bind — do the inspection, the certificate and the serial sit on that tag, or only on a package name?
  3. Operability — can a draft O and M page for that class or instance be opened from the tag, or is it still a vendor brochure in somebody's mailbox?
  4. Custody — is the record in project custody, or will it leave with the trade?
01IdentityDoes this asset have a tag, on the casing and in the register, that survives a room rename?
02BindDo the inspection, the certificate and the serial sit on that tag, or only on a package name?
03OperabilityCan a draft O and M page be opened from the tag, or is it still a vendor brochure?
04CustodyIs the record in project custody, or will it leave with the trade?

If any answer is "later", a dump is being scheduled. Later means completion, and completion is when the people who could have answered from the room are loading their vans.

Volume gets mistaken for validation. A quality archive with thousands of sheets and no join key is a performance of diligence.

The hours are already in the programme

None of this needs a new ceremony. Delivery produces the facts anyway; the discipline is refusing to defer them.

The hours are ordinary ones:

  • Goods-in and factory acceptance, when the serial is cheap to read and the crate is still open.
  • The first site hold point on each tagged instance, rather than a sample against a floor.
  • Commissioning, when as-left values and the name of a witness exist for about an hour and then do not.
  • Package close-out, while the trade can still confirm what they installed and what they left behind.

Throughout is a timing rule more than a philosophy. A review with enough programme left to act as a gate earns its place in the diary; a readiness meeting at ninety-eight per cent complete is a surprise with sandwiches.

Same week is already late for a serial that was on a nameplate last Tuesday, next month is reconstruction, and the last month is folklore with a filename.

Tag it before anybody signs anything

An asset tag is the join key operations will query — a stable identity for a maintainable thing. Not a room number, not a drawing mark reused on four floors, not a work-breakdown code, and not a model identifier nobody ever printed on the casing.

Issue it before the first inspection, test or delivery check a later owner might cite. Provisional is allowed, and usually what you get; absent is the problem. A tag confirmed against the serial on arrival still counts. An anonymous signed sheet you will have to guess at later does not.

Without that key, every later inspection row, certificate, snag, commissioning sheet and O and M paragraph has nothing to hang on, and somebody will end up retyping the building. Binding inspection and test plans to tags from the first hold point is the quality-side half of the same join, and it has to be in place long before anyone says the word handover in a meeting.

The first hold point is the first chance

An inspection and test plan written for a class of plant is a recipe. An instance of that plan signed against one tagged unit is a record. Progressive handover runs on instances.

At each hold point the validation is short: which tag, which activity, who was entitled to sign, what evidence, what status. Where the only identity on the sheet is a package name or the word "typical", a trade has been witnessed but no asset data has been validated.

It is also the first chance to refuse an untagged inspection. A ten per cent sample that passed does not populate the other ninety per cent of the tags, and a certificate filed under a trade heading does not inherit a serial. Quality records are already handover records when they carry the tag; without it they are raw material for whoever compiles in week eighty.

Write the O and M while the installer can still correct it

The O and M is the object most often left to the dump. Vendor files arrive late, somebody concatenates several hundred PDFs, and facilities discover they cannot ask a question about a valve. Turning that pile into a queryable dataset afterwards is a discipline of its own; the cheaper move happens earlier.

A draft is not a finished manual. It is the operating information already knowable when a package closes: identity and location, manufacturer and model, the maintenance action the vendor named, the spare the schedule already listed, the residual hazard the installer can still point at, the drawing title and revision the work was built against. Write it against the tag, or against the class with instance exceptions noted, while somebody who did the work can still correct it over a cup of tea. A later walker will photograph nameplates conscientiously, but will not recover a hold point that never met a tag, or a setpoint that left in the tester's rucksack.

If a package can be valued as complete while its assets have no draft operating page, the works have been accepted and the information deferred. Treat the missing draft as an open item on the package rather than a chapter of a later book.

What the dump actually produces

A dump can look complete. Completeness and contemporaneity are different properties, though, and rows typed from photographs are claims while rows written on site are the asset.

The typical dump does four things, each of them lossy:

  1. It rebuilds an asset list from nameplates, PDFs and a walk.
  2. It attaches quality sheets to that new list by inference — floor, date, "the units on level two".
  3. It concatenates vendor manuals and calls the pile an O and M.
  4. It fills a handover schema once, from the reconstruction, and treats the schema as proof.

What the owner receives is a second building: the first was installed, the second narrated. An information manager on the client side tends to find this at the first data drop review, usually by picking six tags at random and failing to get from any to a signed record. Six months into occupation the FM team finds it again, less politely, when a fan coil needs a part and nobody can say which unit was commissioned to which setpoint.

Try this on one package

Pick a package that has closed, or is closing this month. Accept only a record as an answer, not "it's all in the system".

  1. Does every maintainable instance in that package have a tag, on the thing and in the register?
  2. Can you open, from each tag, the inspection and test plan instance and the last signed hold point, without unzipping a quality archive?
  3. Is there an O and M draft for that class or instance a facilities supervisor could use without a guided tour?
  4. Were the tag, the hold point and the draft written while the installer was on that package, or typed afterwards from photographs and a vendor chase?
  5. Can you list the tags with no inspection record, the signed sheets with no tag, and the closed packages with no draft?

If those five point at the same identity, the handover is already progressive. If they point at a Final folder and a walk still to come, a dump has been scheduled. The test needs the equipment schedule, last week's signed sheets and whatever currently pretends to be the O and M on one table. Where the join is missing, write it down. "Mostly linked" is not a finding.

What to change, and what it costs

ISO 19650 sets out how information should be specified, produced and exchanged; COBie sets out a shape for delivering it. Neither names the Tuesday on which a tag has to exist. CDM, the Building Safety Act and the usual contract families — NEC, FIDIC, JCT, MOMRA — assume a record already bound to the thing it describes, and none of them will schedule that binding for you. Timing is the part a project genuinely owns, and the part most often left to default, which means the last month.

So set it deliberately, in the documents that carry money.

Clients and appointing parties can put the asset identification convention in the asset information requirements, name who issues tags and from when, and align the data drop schedule with package close-out rather than practical completion. A drop reviewed at month nine tells you how good the compilers are; the first mechanical package tells you whether the method exists at all. At tender, ask bidders which validation events they intend to run and at which hold points, rather than whether they can produce COBie.

Principal contractors hold the blunter instrument, which is the valuation. If a package has no tags on its maintainable items, no signed instance against those tags and no draft operating page, that line is not complete. Write it into the subcontract before the first order: discovered at week eighty it is an argument, written at award it is a price.

Be honest about the bill. Tags, a tagging walk, somebody owning the register from the first delivery and QA templates carrying an identifier all take hours a supply chain has to price — and asked after award, it will be priced as a variation, correctly. That is still the cheaper half. The expensive half is the year an owner spends rebuilding a register they already paid for.

The last piece is free. Whoever refuses the untagged hold point on Tuesday morning needs something to point at and somebody senior behind them, or by week eighty they will have stopped refusing.

Read next: COBie explained without the spreadsheet trauma, Writing asset information requirements the supply chain can price, The twelve-month handover: why owners wait a year for data they already paid for.