Build as-built records from reviewed changes

A field markup may show what someone observed, what someone intended to change, or what was actually installed. Those are different statements. Capture the author's role, observation date, location, source drawing revision and the meaning of the markup before relying on it.

Next establish whether the change followed the required approval process. Evidence of installation does not establish design acceptance. If work differs from an approved design, route that fact through the appropriate technical and quality process; do not use an as-built exercise to conceal the discrepancy.

Finally, determine how the accepted configuration must be represented in the handover documents. Drawings, models, schedules and asset lists may use different identifiers or levels of detail. A final PDF alone may not satisfy the agreed deliverable requirements.

In this fictional example, a supervisor's markup shows the valve moved east, while a later survey record identifies a different location. The document controller links both records to the same valve and source drawing. The responsible engineer receives a conflict record with the evidence and the unresolved question.

The engineer arranges the appropriate verification and reviews the change history. The resulting decision states which configuration is established, which approvals or corrective actions are required, and which documents must change. The earlier evidence remains available, with its disposition, instead of being deleted as a duplicate.

After the technical process resolves the conflict, the drafting team updates the relevant drawing and associated records. A reviewer checks the changes against the decision and the agreed deliverable standard. The final issue records its revision, status and release authority. No automated comparison tool should decide the actual geometry or approve the engineering change.

Connect the project, system or area, document number, revision, asset tag and change reference. Record the source version used for each markup. Without that link, a correct redline can be applied to the wrong base drawing and introduce a new error.

Oracle Aconex's document metadata reference distinguishes revision, system version and review status. That distinction is useful: a file uploaded later is not necessarily a later approved design revision. Configure the register so users can see both the business revision and the system history.

For assets renamed during the project, maintain an approved identity cross-reference. Do not silently replace the old tag in historical evidence. The receiving team may still need to trace a test record or purchase document that used the earlier identity.

Collect markups during execution using an agreed process, with responsibility assigned by package or discipline. Waiting until handover increases the chance that the people who understood a change have moved on and the supporting evidence is dispersed.

A periodic reconciliation can compare open changes, installed configuration records and documents awaiting update. It should identify missing evidence and unresolved technical decisions, not merely count files uploaded. Show which changes have been incorporated and which remain pending, with owners and the next required action.

Where a change affects several disciplines, assign the interfaces explicitly. A relocated item may affect layout, cable information, an asset schedule or maintenance access records. The engineering owner determines the necessary review; the register ensures that the resulting document tasks are not lost.

Choose a representative asset and follow it from the final drawing to its asset record, approved change, relevant inspection or test evidence and maintenance documentation. Check that identifiers, revision references and accepted configuration agree. This is more revealing than checking whether every folder contains a file.

The Works Manual's closeout provisions, section 7.6, include as-built and related handover records in their public-works context. Use your actual contract to define the required formats, acceptance process and ownership of editable source files. Do not assume that a scanned redline is an acceptable final deliverable.

Also test retrieval after export. Links that work only inside the contractor's live platform may fail when operations receives an offline archive. Agree a package index and durable references so the receiving team can find records without access to a departing subcontractor's account.

Document comparison can highlight changed text, tags or drawing regions. Extraction can suggest metadata and identify missing fields. A rules-based check can flag conflicting revision references. These tools are useful for triage, especially across a large package, but their output needs review against the actual evidence.

For a small project, a controlled change register and disciplined document issue process may be enough. A document management platform becomes more valuable when concurrent disciplines, transmittals and review cycles are difficult to coordinate. Evaluate the ability to preserve the technical decision chain, not just display two PDFs side by side.

Test a conflicting markup, an unapproved installed change, a renamed asset and a late revision. The acceptance condition is that each reaches a traceable technical disposition and that the issued package contains the agreed result without erasing earlier records.

The as-built package should explain the accepted installed configuration and how unresolved differences were handled. Its value comes from reconciled evidence and review, not from a filename or upload date.

1. Select one system and map field changes to source drawings and asset identities.
2. Route conflicting or unapproved changes to the responsible engineering owner.
3. Verify that each resolved decision is incorporated in all affected deliverables.
4. Test a complete exported package with a receiving user before final issue.