As-built drawings at closeout: a collection and review checklist

Treat the final drawing set as a defined deliverable

A folder called As Builts can contain several different things: foreman markups, a scanned drawing set, a consultant's revised file, a model export and a transmittal. All can be useful records. They do not necessarily satisfy the same requirement. The closeout coordinator needs to know which deliverable the project actually calls for and who is responsible for preparing and accepting it.

Begin with the contract documents, owner instructions and agreed document-control process. Identify the required disciplines, file types, sheet structure, naming rules, review responsibilities and delivery location. If two instructions conflict, record the question and request clarification through the project's process. Do not silently select the easier format because a trade has already uploaded it.

Harvard's January 2026 closeout requirements distinguish contractor-revised as-built drawings from final record drawings prepared by the A/E consultant. That is one owner's terminology and process. Your project may allocate responsibilities differently. Use the example to ask a better scoping question: which party prepares each stage, and what record proves that the required stage has been delivered?

Sources: Harvard University: Capital Project Closeout Construction Documentation Requirements, January 2026

Create the receipt checklist before chasing files

Use a row for each deliverable that has a clear owner and review outcome. A small project might use one row per discipline set. A larger job may need rows by building, system, area or sheet group. Choose a level at which a missing file or unresolved correction can be assigned without reopening an unrelated package.

Record the requirement reference and its current revision. Add the responsible company, named coordinator, intended reviewer, requested submission date and any confirmed commitment. Keep a specific missing-item field. Requesting all as-builts again is less actionable than requesting the native file and change-source reconciliation for the utility package already received.

Include a field for applicability decisions. If a discipline is not part of the project, retain the basis for marking it not applicable and the person who confirmed that conclusion. A blank row can mean not yet reviewed, missing, or not required. Those meanings should remain distinguishable so a replacement coordinator does not mistake an unanswered question for a closed requirement.

Collect the sources behind the final revision

The final drawing issue should have a reviewable connection to the information used to prepare it. Collect the project-required field markups, change references, clarification responses and other supporting records through the responsible parties. Use source IDs and locations rather than relying on a personal recollection that somebody sent the redlines last month.

Record where the field information came from and which drawing issue it references. If one markup is on revision B and another is on revision C, the preparer needs that context. Do not merge marks into a fresh file and discard their origins. Preserve original submissions, then record any consolidation performed by the responsible preparer.

A photograph may support a record, but its existence does not independently establish an accurate dimension, alignment or concealed condition. If the project needs a measurement or professional verification, identify the appropriate responsible party and retain their record. This checklist is for collection and review coordination; it does not provide surveying, engineering or technical certification instructions.

Worked example: a final PDF with two open gaps

Consider a fictional utility package U-12. The owner's agreed delivery register requires a PDF set and a native drawing file, with a field-change source register supporting revision C. The contractor uploads U-12-C.pdf. The file opens and its title block says revision C. No native file or linked change-source register accompanies it.

The coordinator records the PDF as received on October 29. A completeness check identifies the two missing components and routes the package to the responsible preparer. The status is received, correction requested. It is not accepted, and the coordinator does not claim that the PDF is technically wrong. The available evidence supports a narrower conclusion: this submission is incomplete against the fictional delivery register.

The preparer later supplies the native file and source register. The designated reviewer then checks the submission under the project's process and records either comments or acceptance. Keep that later review as a separate event. If the reviewer accepts revision D after corrections, the accepted package should point to revision D while revision C remains available in the submission history.

Check usability without overstating technical review

A completeness pass can answer practical questions: do the files open, are expected sheets present, do names match the index, and are required supporting files included? Record who performed the check and what it covered. An administrative check is useful precisely because it finds avoidable gaps before the technical reviewer spends time on the package.

Required formats vary. Harvard's published instructions include specific electronic delivery requirements and file quality checks. They demonstrate why a universal rule such as one PDF is enough would be unreliable. Use your owner's current instructions for native formats, references, packaging and validation. Do not copy another owner's exact file standards into a subcontractor request without a project basis.

When software flags an issue, retain the result and assign it to someone who can interpret it. A missing reference warning may require a corrected file or an explanation through the review process. An automated file-open test cannot establish that every field change is accurately represented. Keep the scope of each check explicit in the record.

Sources: Harvard University: Capital Project Closeout Construction Documentation Requirements, January 2026

Match submission, comments and corrected issue

Each submission needs a stable reference, date, preparer and revision. Comments should identify the affected package or sheet and the action required. When a corrected issue arrives, connect it to those comments. A fresh email subject or a new folder should not break the relationship between the original submission and the correction that closes it.

Avoid treating the newest timestamp as the accepted version. Files may be copied, downloaded or regenerated without a substantive change. Record the declared revision and the actual acceptance reference. If the team cannot tell which version a review addressed, keep the item open for clarification instead of assigning the review to whichever file appears last in the folder.

Maintain a current-deliverable view alongside the history. The owner should be able to find the accepted package without sorting every intermediate issue, while the project team can still reconstruct how that package was produced. Use access controls appropriate to the documents and preserve records according to the project's retention and information-security requirements.

Make the acceptance path visible

Identify the reviewer before the due date. Confirm who receives the package, how comments return, who coordinates corrections and what evidence records acceptance. If several parties review different aspects, keep their scopes visible. Receipt by the document controller, technical review by a consultant and delivery to an owner repository can represent separate steps.

Request a response to a defined item. For the U-12 example, a useful message identifies the received PDF, the missing native file and the missing source register, then asks the preparer for a committed correction date. Attach the requirement reference. Avoid a generic reminder that makes the recipient rediscover the reason the package is still open.

Where an acceptance decision is disputed or delayed, retain the current state and responsible decision maker. Do not manufacture an acceptance date to improve a completion dashboard. The tracker should help the PM see the actual unresolved decision and its relationship to turnover, rather than replace the authority established by the project documents.

Use the free as-built receipt checklist

The blank CSV above provides starting columns for the project, discipline or package, requirement source, required formats, preparer, submitted revision, received files, missing sources, completeness review, technical reviewer, comments, accepted issue and next action. Adapt the field names to the actual project. Leave unknown values visible until somebody supplies the evidence.

Start with one near-term package and populate it from the existing folder and correspondence. Record only what you can support. If an acceptance email is missing, use acceptance not recorded rather than guessing that the absence of comments means approval. If a reviewer later provides the evidence, add the reference and update the state while retaining the earlier gap in the history.

Use the register during a short working review with the preparer and closeout lead. The useful output is a named person, a defined missing item and a confirmed next step. Measure whether corrections are actually being resolved, not just whether the number of uploaded files grows. More files can make a package harder to use if their roles and versions remain unclear.

Test the final package from the recipient’s side

Before final transmission, ask a person who did not assemble the folder to follow the index and open a sample of the required deliverables. Check that the accepted issue can be identified, the references resolve and the intended recipient can access the files. This usability pass complements the designated reviews; it does not repeat or replace technical acceptance.

Record the final transmittal, contents, destination and recipient response. If the recipient reports a broken link or omitted file, reopen that specific delivery exception. Keep it separate from a change to the technical content unless the issue requires a revised package. That distinction helps the team route a repository problem to the right person.

When the record is complete, preserve the accepted set and its acceptance evidence together. Connect it to the broader closeout index, manuals and related system records where the project requires those links. A well-organized drawing package should make the next facilities question easier to answer without forcing someone to reconstruct the closeout team's inbox.

Coordinate collection with Buildalytic workflows

Buildalytic advertises custom follow-up workflows with calls, texts, email, waits and named approval steps. An as-built collection demo can begin with the U-12 scenario: a received PDF, two missing components and a designated reviewer. Review how the workflow requests the missing items, records responses and stops reminders when the defined collection task is complete.

Ask the team to demonstrate supported document-system connections, permissions, file references and the route for unresolved responses. Keep controlled drawings and professional reviews in their authorized systems. A follow-up workflow should not be described as an automatic certification of installed conditions or a substitute for the owner's acceptance process.

Bring a redacted package and delivery requirement to a demo. The useful result is a clear map from requirement to submitted file, correction request and recorded review. That gives your team a concrete way to evaluate whether the workflow removes chasing while preserving the decisions that belong to the preparer and reviewer.

Sources: Buildalytic custom construction workflows