Skip to main content
DoneThat

AI Adoption GuideConstructionHandover

Handover Package Completeness Check

LLM compares the assembled handover package against the contractual close-out schedule and flags missing documents.

Construction processBidAwardPlanMobilizeBuildInspectHandoverClose

By Don, DoneThat’s AI coach · updated

Use the contractual close-out schedule as the only checklist

A completeness check reports which close-out schedule rows have no matching document in the assembled handover package. Each report is a missing-document flag with two cites: the schedule line, and the pack location that was searched. If the schedule has no row for a topic, the result for that topic stays empty. The check does not invent a missing O&M, and it does not declare practical completion.

Start from the contract, not from a contents template. The close-out schedule (sometimes an information-delivery schedule, an employer's information requirements close-out appendix, or a similar table) is the list the package must satisfy. Rows usually give a document title, a responsible party, and the status required at handover (as-built, certified, red-line, original). That table is the checklist. A generic O&M contents list, last project's pack index, or the default folder tree in Autodesk or Procore is not a substitute. Those platforms store the files. They do not rewrite the contract.

Landlord-supplied plant, tenant IT, and items under a separate maintenance agreement often have no row. That is deliberate. If there is no row, do not raise a gap because every asset "needs a manual." That is the first failure mode: inventing a missing manual from industry habit rather than from the schedule.

Work that assembles the pack is upstream of this check. O and M manual auto-assembly and warranty register extraction produce files that then sit in the package. Completeness asks whether the schedule's rows are covered by what was assembled, not whether the assembly process felt thorough.

Compare the assembled pack row by row

Work the schedule from top to bottom. For each row, search the assembled package for a document that corresponds to that row, then stop. Do not add rows. Do not merge two schedule lines into one "mechanical pack" tick.

Fix the package boundary first. The assembled pack is the set issued for handover: the bound volumes, the common data environment (CDE) transmittal, or the zip plus contents list that the commercial lead will send. Files that still sit in working folders, in an open RFI, or in a consultant's inbox are outside the pack. Searching the whole project CDE will create false hits. Search the issued pack.

For each row, record:

  • the schedule identifier and the quoted document title and required status
  • the pack locations searched (volume, folder, register filter)
  • the candidates found, if any, with title-block title, revision, and stated status
  • match, no match, or needs handover review

Match means the candidate's title block and status correspond to the row, and the asset or location coverage matches if the row is specific. No match means those locations contain nothing that corresponds. Needs review means a candidate exists but the title block, status, or coverage does not clearly satisfy the row. Needs-review items are not missing-document flags. They are a queue.

If the pack is indexed, use the index as a map, then open the file. If the pack lives only as folders in Autodesk or Procore, use the same folder names and register columns the handover lead already uses in the cite. Do not invent a parallel taxonomy.

Open defects belong on open defect aging monitor. Expected asset records for a CAFM or twin load belong with digital twin asset data population. Mixing those into this check either invents documents the contract never listed or hides a real schedule gap inside a different register.

Write every gap with two cites

A missing-document flag is usable only when a commercial lead can open the schedule and the pack and agree in a few minutes.

Schedule cite: document name, clause or item number, and the words of the row that state what is required (title and status). Quote the row. Do not paraphrase "O&M for the air handling" if the row says "AHU-04 operation and maintenance manual, as-built, including recommended spares."

Pack cite: the issued-pack location searched. Name the volume and section, or the CDE folder and the register filter (document type, asset tag, revision status). If a contents list exists, cite the line that should have held the document. If nothing is there, say so. "Not in the pack" without a location is not a cite.

Do not raise a flag that cannot point to a real schedule row. Do not raise a flag whose pack cite is "full project search." If the file might still be on a transmittal not yet filed into the issued pack, that is a filing problem for handover to confirm, not a model conclusion that the document does not exist.

When you do raise a flag, keep the quality outcome as the flag itself. No traffic-light score. A count of unmatched rows can sit beside the list as a tally. It is not a completeness percentage and it is not a pass.

Do not invent manuals or trust filenames

Two failure modes sit next to this check.

Inventing a missing manual: the model has seen many handovers that include a particular O&M, so it flags its absence even when the schedule is silent. A landlord lift with no contractor O&M row is the usual case. The correct result is empty. Raising "missing lift O&M" creates a chase the contract never required and trains the team to ignore flags.

Treating a filename as the document: packs are full of files named after the deliverable they are not. Fire_Strategy_AsBuilt_RevC.pdf can be the planning fire strategy. A PDF called Commissioning_Complete can be a programme, not certificates. The filename is a hint for where to look. The title block, revision, stated status, and coverage are the evidence.

One worked example. A commercial office fit-out close-out schedule lists item 6.08: "As-built fire strategy, including compartmentation markup, for the demise." The issued pack includes 6.08_Fire_Strategy_AsBuilt.pdf in the statutory folder. Page 1 title block reads "Fire strategy, planning issue, Rev B." The compartmentation markup matches the planning drawings, not the constructed partitions. The check must not tick 6.08 because the filename matches the row. It should leave 6.08 unmatched: schedule item 6.08 requires an as-built fire strategy with compartmentation markup; pack location statutory/6.08 holds a planning-issue fire strategy (title block Rev B); no other issued-pack location matched an as-built fire strategy for the demise. Handover then confirms: the as-built is in another volume, it exists outside this transmittal, or it is outstanding.

The same rule applies after auto-assembly. If an O&M PDF was bound from whatever sat in the folder, presence of a file named O&M does not satisfy a schedule row that asks for as-built manuals with named assets. Open the binder against the row.

Warranties follow the schedule, or a warranty schedule the close-out table incorporates. Extracting what is already in the pack is the job of warranty register extraction. Completeness only flags a missing warranty file when a cited schedule row requires it in the pack.

Completeness does not grant practical completion

Do not declare practical completion, or substantial completion, from a green score.

A set of matched rows means the issued pack has a candidate for each tested schedule line. It does not mean the works are complete, the certificates are valid, defects are closed, or the employer should take possession. Practical completion is a decision by the person named in the contract, usually after inspection and with any agreed outstanding items listed. A pack can be complete while the building is not. The building can reach PC with agreed outstanding documents. Treating a completeness score as PC is the third failure mode. It is a commercial error, not a wording slip.

Keep the output as flags plus cites. If a dashboard is tempting, do not label it complete, ready, or PC. Handover confirms every flag before the pack is issued or re-issued: open the cited schedule line, open the cited pack location, accept the gap, point to a file the search missed, or reject a false gap (out-of-scope plant, wrong row, file on a transmittal not yet filed). Until that confirmation, do not move the pack and do not treat the check as a PC recommendation.

The check stays silent where the schedule is silent. It stays a quality flag, not a completion certificate.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first