A handover acceptance checklist for owners

Handover week is the last cheap moment an owner gets. Once the keys move, the contractor's account starts closing, the specialist vendors demobilise, and every missing field turns into a variation with a filename attached. What actually arrives in that week is usually a ZIP, or a shared-drive folder somebody has been filling since March, or a trolley of PDFs labelled Close-out. Signing for it feels like a courtesy at the end of a long job, and it is treated that way in most diaries. It is closer to a procurement decision about what operations will be able to query for the next twenty years.

The person making that decision is normally the client-side information manager, standing next to the asset manager who has to live with the building and a document controller who can already tell, roughly by weight, that the pack is thinner than it looks. All three of them can still say no on that day. None of them can say it a fortnight later.

So run the checks on the live set the contractor is offering, not on the cleaned extract prepared for the meeting. And do not build a second register to test the first against. Test the thing you are about to own.

On the day the keys are offered

Start by naming what you are testing against: the information standard, the asset information requirements, the employer's information requirements — whichever of them actually publishes a tagging convention, a status-code list and a definition of the issued set. If none of them does, write that down before anything else. It is a finding in its own right, and it belongs to the contractor rather than to you.

Then walk six objects, in this order. The asset register comes first, because nothing downstream can point at an identity operations will use until the register exists. O and M second, since a manual that cannot find a tag is shelving. Warranties third — a date that is not on the same row as the tag has a habit of becoming folklore inside a month. As-builts fourth, because the register and the manuals will both claim to describe what was built. Then the issued set, since everything else cites a title, and two current-looking revisions will poison the lot. Last, the AIM owner: a named person in the receiving organisation.

Write findings as tag numbers, vendor titles, warranty identities, sheet numbers and a person's name. "Substantially complete" is not a finding. It is a way of avoiding one, and it tends to appear in minutes written by whoever most wants the meeting to end.

One live system is enough for a first pass — a plant room, a lift bank, a fire-alarm loop, a floor of terminal units. If that system fails, the pack fails. Nobody needs to sample four hundred assets to refuse something that cannot produce six facts about twenty.

The register operations will actually query

The technician who gets called out at two in the morning does not search on a procurement code, a vendor's filename or a room schedule from year two of the job. They search a tag, a location and a system. Those identities have to exist, in a form findable by someone who was never on the project, before the keys move.

For every asset on the sampled system — installed, spare, or still sitting in the store — you should be able to produce six facts from the system of record. Not from memory, and not from a folder of site photographs:

the tag as installed, matching the label on the unit
the location an operator will use, not only the procurement zone
the system the asset belongs to
manufacturer, model, and serial, as they sit on the nameplate
the drawing identity the tag is supposed to match
the residual open item, if any — defect, outstanding test, or missing field — written against that tag, not against "the package"

A tag on the unit with no matching row is folklore. A row with nothing on the unit is a spreadsheet exercise. Worse than either is a tag that does not match the title in the issued set, because that leaves two identities for one piece of plant, which is how an O and M becomes fiction the first time anybody searches it.

Plant that has been bought but not installed needs a reserved identity too. Registers that count only what is bolted down leave the spares, the attic stock and the late deliveries to be invented after demobilisation, usually by the person least equipped to invent them. Write the reserved tags. Write the holes as holes, because a blank that looks like a future is a hole you are about to buy.

If you cannot list the tags on the live system without opening a ZIP or emailing a vendor, what you have is the promise of a register. Promises are cheap in that room and expensive afterwards.

O and M that points at the same tags

O and M usually arrives as four hundred PDFs, and the temptation is to check that the folder is full rather than whether anything in it can be found. Fullness of a folder named O+M is not the test. The test is whether someone who was never on the job can retrieve the identity, the maintenance action and the related title without unpacking an archive first.

For each tagged asset on the sampled system, ask:

Is there a manual or structured pack — not a vendor email saying "to follow," not a contents page for a ZIP that is still being compiled?
Does it point at the same tag and location the register uses?
Can you find the identity, the maintenance action, and the cited drawing without opening more than one container?
If it is wrong, can you still refuse it under the purchase order or the information requirements, or has the vendor already closed the account?

That fourth question is the one people skip, and it is the one that decides the next two years. A pack you cannot refuse is not really a handover deliverable at all; it is the eventual reconstruction, arriving early enough to look industrious. "Vendor will supply after practical completion" is a finding, not a status. Write down the title you are missing and the order it sits on. An hour spent refusing a draft while the vendor is still contracted is cheap. The same work after the account has closed comes back as a variation, and somebody in operations does it twice.

The longer argument about turning four hundred PDFs into something queryable sits in O and M manuals: from four hundred PDFs to a queryable dataset. On acceptance day the narrower question will do: does the object in front of you already meet a tag?

Warranties, on the same row as the tag

A warranty filed as a letter in a folder stays a letter in a folder. The cost usually surfaces as a replacement that lands a fortnight outside the window because nobody recorded the start date, and by then there is no leverage left to recover it. The moment to demand the fields is the moment you can still decline to sign.

For each tagged asset on the sampled system that carries a manufacturer, contractor or design warranty, reconstruct five facts from the record rather than from a cover letter:

the tag the warranty attaches to — not "AHUs," not "the package"
the warrantor, as a name that will still mean something after demobilisation
start date, end date, and the event that started the clock — practical completion, first beneficial use, or a named commissioning pass
what is covered and what is excluded, in a form operations can read without a lawyer on the first call
spare-parts identity: part number, recommended holding, and the lead time as the vendor actually stated

A start date of "handover" with no calendar day is not a date. A warranty citing a procurement code the register does not use hands you two identities again. And the spare-parts list that lives only inside a vendor PDF the register cannot find is precisely the dull field that costs real money the first time a long-lead component fails.

The field-level method sits in warranty and spare parts data: the boring fields that save millions. At acceptance, all you are checking is whether those fields are already on the row you are about to own.

As-builts: the record of what was actually built

Ask for the as-builts and you will sometimes be handed a red-line set that was photographed the week before the meeting. That is a picture of a marked-up drawing, and it is not the bounded record of what was installed against the identities the register and the issued set already use. If the as-built cannot say which revision of which title the installer followed, and what departed from it, operations inherit a drawing that looks current and a building that does not match.

For the sampled system, each as-built title must carry five facts:

identity — number plus revision, not a filename hint
the issued-set title it supersedes or records a departure from
the departure, written as a mark, a schedule row, or a coordinated change — not "as site"
the date the as-built became the one the owner may rely on
the asset tags and locations it now describes

A cloud on a print with no revision does not make an as-built, and neither does a model that froze at a coordination issue and was never touched again. A record model that cannot produce the same tag the register uses is a twin that stopped being useful at practical completion.

If the contractor offers a scan, a point cloud or a federated model instead, ask the same five questions of it. Geometry without identity is a picture of a building. What you are accepting is information; the file format is a detail that follows.

The issued set everything else cites

The issued set is the bounded list of current, authorised containers for the package and the purpose. Not everything sitting in a folder called Published. Think of it as the list a competent person could hand over this afternoon and still defend next month.

Tags, O and M, warranties and as-builts all cite drawings. If two revisions of the same title both look current, every check after that is poisoned. If the commissioning engineer tested against C01 and the register shows C02, the dispute has already been bought; signing simply moves it onto the owner's side of the table.

For the live package, each title must carry five facts:

identity — number plus revision
state — published for the stated use
suitability — what the recipient may do with it, on the agreed list
supersede — which previous identity is dead
date — when this identity became the one the owner may rely on

Then confirm three things. That there is exactly one current revision per title. That you can produce the set as it stood on a named date last month, not only as it stands this morning. And that the register, the O and M, the warranty row and the as-built all cite that current identity, or a dated older identity that has been archived, rather than a sheet number with no revision at all.

There is nearly always an unofficial set in the trailer as well, and everyone in the room knows it. If acceptance cannot trust the official one, operations will inherit both, and the two will disagree. Whoever signs has bought the disagreement.

Somebody's name, after the project leaves

An asset information model without an owner becomes a cupboard within a year. ISO 19650 and the project's own asset information requirements both assume that someone in the receiving organisation keeps the model current: tags, manuals, warranties, as-builts, and the issued set all of those cite. Acceptance that does not name that person is where the twelve-month reconstruction quietly begins.

Before you sign, write four facts on a single line:

the named AIM owner — a person, not a team name, not "FM," not the outgoing project manager
the organisation and role that person will hold after the contractor has left
the system of record they will keep — one, not a shared drive plus a spreadsheet plus a vendor portal
the first review date, inside ninety days, at which they will re-run this checklist on the same sample

If nobody in the room can name that person, and the client-side sponsor cannot either, then there is no AIM owner — only a hope that operations will produce one later. In my experience the register starts going the first time somebody exports it to "make it usable," and an unnamed owner is what makes that export nobody's problem.

Where the loss actually goes — export, rename, inbox, USB, and a missing AIM owner — is mapped in where the thirty per cent of lifecycle data lost at handover actually goes. The task on the day is narrower: get the name written down before the keys move.

The acceptance score sheet

Print it. One row per object. The client-side information manager and the incoming asset manager fill it in together, and the contractor does not get to edit it afterwards. Forty-five to ninety minutes, on the live system, on the day the pack is offered — not the week after the ceremony, when half the people who could answer have gone.

Object	This review's sample	Pass
Asset register	Every asset installed, spare, or reserved on the live system	Tag, location, system, nameplate data, matching drawing identity, open items on the tag
O and M	Each tagged asset that already has a manufacturer and model	A refuseable pack pointing at the same tag; gaps named against an order
Warranties	Each tagged asset that carries a manufacturer, contractor or design warranty	Warrantor, start and end dates, cover, spare-parts identity on the same row
As-builts	Every title the register claims describes what was built	Identity, departure, date, and the tags it now describes
Issued set	Every title the register, O and M, warranties and as-builts cite	One current revision; previous marked; set reconstructable on a named date last month
AIM owner	The receiving organisation	A named person, one system of record, a review date inside ninety days

A pass should be boring. A fail is a tag, a vendor title, a warranty identity, a sheet number or a missing name. Resist averaging the six rows into a percentage — that invents precision the hour does not have, and percentages are easier to argue away than tag numbers. Carry the fails forward until they close, or write them as conditions on the acceptance you are about to sign.

Waiting for a consultant, a tidy-up transmittal or the last vendor ZIP rarely improves the pack. Accept the keys against a promise and the reconstruction that follows is yours to fund.

Conditional acceptance is still acceptance

Owners sign against snagging lists all the time, with an understanding that the information will follow. That is still a decision about the information as it stands on the day. If you intend to accept conditionally, make the conditions identities: the tags, titles, warranty rows and the missing name that failed the score sheet, each with a date and a person who still has a live contract to close them under.

"O and M to be completed" is a courtesy wearing the clothes of a condition. "AHU-07, AHU-08: manufacturer manuals refused; purchase order 4412; close by 15 June; vendor still contracted" is a condition. Write the second kind, or drop the word conditional.

Residual risks belong on the same sheet — an open defect, an outstanding test, a missing serial, a warranty with no start date. Each of those is something operations inherits, and if it is not written against a tag, it will not be found on the day of the first claim or the first isolation.

The mid-project habit that shortens this meeting considerably is the handover readiness review run at sixty per cent complete. Where nobody ran that gate, the checklist is how you avoid paying for the surprise.

What a checklist cannot do

None of this certifies anything, and it should not be presented as though it does. ISO 19650, CDM, the Building Safety Act, NEC, FIDIC, JCT, COBie, MOMRA, and the project's own BEP and asset information requirements each have their own owners and their own teeth. What they have in common is an assumption of a contemporaneous record of what was installed, issued, warranted and handed over. None of them treats a late ZIP as proof that acceptance was earned, and none of them will accept a method as a stamp.

The score sheet does not buy certainty. What it buys is an hour in which refusing still costs less than accepting — and a single sheet of paper the incoming asset manager can point at on Tuesday, when somebody offers to tidy it all up after the keys have moved.