Every capital project ends with a handover. The contractor demobilizes, the owner's operations team takes the keys, and in between a turnover package changes hands: the record of what was built, how it was tested and what it needs to keep running. On a process unit or a large mechanical installation, that package is one of the most valuable things the project produces. It usually arrives as a few thousand PDFs in a folder tree.
This field note covers how turnover packages are assembled today, why they take that form, and what changes when the package is a register the owner can query rather than a library the owner has to read.
What goes into a turnover package
Contents vary with the contract, the industry and the owner's handover specification, but the core is consistent.
- As-built drawings. P&IDs, isometrics, plot plans, mechanical and HVAC plans, electrical one-lines and loop diagrams, updated from field redlines to show what was actually installed.
- Registers and lists. The line list, equipment list, instrument index, valve list and tie-in list, and the tag register that should tie them together.
- Vendor data. Datasheets, general arrangement drawings, installation, operation and maintenance manuals, recommended spares and certificates for each purchased item, delivered against the vendor document requirements in each purchase order.
- Quality and test records. Material certificates, weld and NDE records, pressure test packages, calibration certificates, inspection and test records by tag, and the signed checksheets behind mechanical completion.
- Completion and commissioning. Punch lists and their closure, completion certificates by system, commissioning and performance test records, and on buildings the test and balance report.
- Warranties, permits and training records.
On commercial buildings, these requirements usually live in the closeout sections of Division 01: record documents, operation and maintenance data, warranties, and demonstration and training. On process and energy projects, the package is organized by system and subsystem, because that is how the plant is completed and commissioned. Some owners write their requirements against industry handover specifications, such as CFIHOS for capital facilities or COBie for buildings. Many write their own.
Why it arrives as thousands of PDFs
Nobody sets out to hand over a pile. It happens because of how the package is built.
- It is assembled at the end. Most of the content exists months before close-out, spread across document control, the completions system, procurement, quality control and the field. The turnover team gathers it in the final weeks, as the people who produced it move to the next job.
- Every source has its own format. Vendors send scanned manuals. The completions system exports signed checksheets. Quality control scans test packs with wet signatures. Document control issues drawings as PDFs, because PDFs are what the contract names as the deliverable.
- The index is a transmittal. What links the documents to the plant is a spreadsheet index, a folder convention and the turnover coordinator's memory. The tag that connects a pump's datasheet to its P&ID, its test record and its spares is written inside each document, not across them.
- The contract asks for documents, not data. Most handover requirements define deliverables as files in folders, so files in folders are what get delivered.
The result is complete in the sense that the files exist. It is rarely complete in the sense the owner cares about: every tag in the plant has every record it needs, and the drawings match what was built.
A turnover package can contain every document the contract asked for and still not answer the first question operations asks: what do we know about this tag?
What tag-to-drawing traceability means
The tag is the unit of a plant. A pump, a control valve, a transmitter, a line, a fire damper: each carries a tag, and every record about it should be findable from that tag. Traceability means the link holds in both directions.
- From tag to documents. For any tag, you can list every drawing it appears on, with sheet, revision and region, and every datasheet, certificate, test record and manual that refers to it.
- From documents to tags. Every tag shown on an as-built drawing exists in the register, and every vendor document names tags that exist. Nothing points at a tag that is not there.
Most handover defects are a failure in one direction or the other.
| Check | What it usually catches |
|---|---|
| Tag in the register, on no as-built drawing | Deleted equipment still listed, or a drawing that was never updated |
| Tag on a drawing, missing from the register | Field additions, renumbered instruments, vendor skid tags never mapped |
| Tag with no datasheet or manual | Missing vendor data, often from late or substituted purchases |
| Tag with no signed test or inspection record | Completion gaps hidden under a system-level certificate |
| Line on the P&ID that disagrees with the line list | Size, class or insulation changed in one place only |
| As-built revision older than the last field change | Redlines that never reached the drawing |
In a folder of PDFs, each check means a person reading documents side by side. In a register built from the documents, each check is a query. The drawings are read into a typed graph, tags are extracted from every drawing and vendor document, and each record keeps the sheet and region it came from. Engineers verify the reading tag by tag, for the reasons we set out in Why we verify every tag, so the register can be trusted where it matters.
How a structured register shortens owner review
Owner review of a turnover package is usually a sampling exercise, because nobody can read everything. The operations readiness or document control team opens a few systems, checks a set of tags against their records and sends comments back. The contractor fixes what was found and resubmits. Each round takes time, and whatever the sample missed turns up later, in operations.
With a structured register, the review runs in a different order.
- Completeness first, by query. The register lists, system by system, every tag missing a required record and every mismatch between drawings and register. The contractor runs the same list before submitting.
- Evidence on demand. For any finding, the reviewer opens the exact region of the sheet or page behind it instead of searching a folder.
- Judgment where it counts. Reviewers spend their time on whether a record is right, such as whether a test record covers the right test at the right pressure, not on whether a record exists.
- Comments tied to tags. Each comment attaches to the tag and document it concerns, so a resubmittal is checked against the open list rather than reread from the start.
This matters commercially. On many contracts, part of the retention or the final payment is tied to acceptance of the handover documentation. When acceptance depends on a long review cycle, the contractor waits on money it has earned and the owner carries an open item it would rather close. A package that answers its own completeness questions before submission gives both sides a shorter and more predictable path to acceptance. We would rather owners and contractors measure that on their own projects than quote a number.
Build the register as the project runs
The register is easiest to build during the project, not after it. A few habits make the difference.
- Agree the handover requirements early, including the owner's tag format, the records required for each class of tag and the delivery format.
- Read drawings into the register at each issue, so the as-built comparison starts from a known IFC baseline. The revision history belongs in the package too, as we argue in Revision control from IFD to as-built.
- Index vendor data on receipt, against the purchase order and its tags, instead of at close-out.
- Capture redlines as they happen, so the as-builts reflect the field before the field crews leave.
- Run the completeness queries every month, and treat the open list as a progress measure rather than a close-out surprise.
What operations does with it afterward
Handover is the start of an asset's working life, which may run for decades. A register that arrives as data goes straight to work.
- Maintenance system setup. The asset hierarchy, tag list, spares and vendor maintenance recommendations load into the owner's maintenance management system from the register, instead of being keyed in from manuals.
- Inspection programs. Line classes, materials and design conditions seed the piping and pressure vessel inspection plans, and the valves and connections on the as-builts give an LDAR component inventory a starting point.
- Process safety information. On facilities covered by OSHA's PSM standard, the P&IDs and equipment data are part of the process safety information. A verified, traceable set is a far better starting point than a stack of scans.
- The first change. The first management of change on the new unit starts from a graph that matches the plant, as described in Management of change starts with a diff.
- Service and the next project. For a mechanical contractor, the record set and equipment data become the base for the service agreement and for the next renovation bid on the same building.
Hand over the answers
A turnover package is the project's last word on the asset. Delivered as files, it holds the answers somewhere inside thousands of pages. Delivered as a verified register, linked to every drawing and document it came from, it gives the owner the answers directly, and lets the contractor show the package is complete before anyone has to ask. For how we read and connect project documents, see the platform and our construction and energy pages.
