The As-Built Problem

Every infrastructure project produces an as-built record: a document or drawing of what was constructed, next to what was designed. The design says the cable runs along the north side of the road. The crew ran it along the south side because a gas main was in the way. The as-built captures that.

How accurate an as-built is depends on when and how it is written. Assembled weeks after construction, from field notes and photos, it asks a drafter to reconstruct changes from fragments after the crew has moved on. Written as the work happens, it records each change from the device that was there.

Accuracy compounds across projects. The next project designs against the as-built and sends a crew to the field. An accurate record sends them to what is in the ground. An inaccurate one sends them to work around it, and the next record inherits the gap.

What an Accurate As-Built Needs

The deciding factor is timing. Recording the work as it is done keeps the record and the ground in step.

Detail captured at the point of work. A field worker recording as they go captures exact coordinates, distances and small adjustments, because the information is in front of them.

The work and the record in one place. Each change links to the work order and the field report behind it, and a query answers which work produced which change.

Provenance for every change. Each change carries who made it, when and on what evidence. The record shows what a field report backs.

A handoff that carries the history. The as-built is the last deliverable before an asset moves to operations, and operations relies on it in a repair, an expansion or an emergency.

The Map as a Living As-Built

In Aptli, the as-built is the map the team works on throughout the project, and it grows as the work happens.

Features on the map are the record. When a field worker moves a point, adjusts a cable route or adds a splice location, that edit is the as-built update. It happens at the point of work, with coordinates from the device, at the time of the work.

Every change goes into a version. Each version records who made the change, when and what the previous state was. A committed version can be restored, and the history runs from design through construction.

Field changes go to an approver. A field worker saves changes into a working version and submits it. The approver sees what changed and where, and commits it or sends it back with a note. Every update to the as-built passes that check.

Overlapping edits are flagged. When two field workers edit the same area, Aptli flags the overlap before either lands, and the team resolves it explicitly.

Design to As-Built in One System

The lifecycle that produces an accurate as-built looks like this:

Import the design. Load the design drawings (Shapefile, File Geodatabase, GeoPackage, DXF) onto the map. The import preview flags overlaps with existing data before anything is saved, and the features land in their layers through a version. The import is the design baseline.

Plan the work. Projects, jobs and work orders carry where the work happens and the materials and labour it needs. The plan sits on the same map as the design.

Do the work and report it. Field workers submit reports with the location of the work, photos and the materials used. If the cable ran along the south side, the report records that, at the time, from the device that was there.

Update the map. Field workers edit the features to match what was built: move the cable line to its actual route, add the extra junction box, remove the planned feature that was left out. They submit the version for approval.

Review and commit. The approver compares the version with the design and the reports and commits it. The committed map is the as-built, and it is the same map operations will use.

The handoff carries the history. When the project closes, operations inherits the current map, and every feature carries its version history back to a field submission and an approval.

The Audit Trail

The deepest value is provenance.

When a regulator, a client or an operations engineer asks "what is in the ground here, and how do you know?", the answer comes from the record:

The feature has a version history from design through construction.
Each version records who submitted it, when, and who approved it.
The field reports behind each change are linked, with location, photos and materials used.
The import shows the design baseline loaded at the start.
Everything exports as GeoJSON, CSV or the audit log from the same system.

The record shows who surveyed each segment, when, and what changed since the last submission.

Summary

An as-built is most accurate when it is written as the work happens, at the point of work.
Accuracy compounds: each project designs against the last as-built.
An accurate as-built needs detail at the point of work, the work and the record in one place, provenance for every change and a handoff that carries the history.
In Aptli the map is the as-built. Field edits save into versions, an approver commits them, and overlapping edits are flagged.
The design imports as the baseline, work orders carry the plan, reports record what happened and feature edits record what was built.
Operations inherits the map with a version history for every feature.