The As-Built Problem

Every infrastructure project is supposed to produce an as-built record — a document or drawing that shows what was actually constructed, as opposed 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 there was a gas main in the way. The as-built record is supposed to capture that reality.

In practice, as-built documentation is one of the most consistently unreliable deliverables in infrastructure work. Not because teams are careless, but because of when and how the record gets produced. The standard process looks like this: construction finishes, someone collects field notes and photos from the crew, a drafter opens the original design drawings, and the drafter modifies them to reflect what actually happened. This process often begins weeks after construction is complete. The crew has moved on. The field notes are incomplete. The photos do not always make clear what changed and what stayed the same. The drafter is reconstructing a story from fragments, and the result is an as-built record that is better than nothing but worse than what anyone would accept if they understood how it was produced.

The problem compounds over time. The next project inherits the as-built as its baseline, designs against it, and sends a crew to the field — where they discover that the previous as-built was wrong. Now they work around the discrepancy, and the new as-built inherits the inaccuracy of the old one, plus any new deviations. After three or four cycles of this, the record of what is actually in the ground bears only a passing resemblance to the drawings.

Why Assembly After the Fact Fails

The root issue is timing. When you separate the act of doing the work from the act of recording the work, you create a gap that only gets wider.

Delayed recording loses detail. A field worker who records what they did at the end of the day remembers the major decisions — rerouted the cable, added an extra junction box. They do not remember the exact coordinates, the precise distances, the small adjustments. A field worker recording as they go captures all of it, because the information is in front of them.

Separate systems lose context. When the work lives in one system and the as-built lives in another, the link between them is a person's memory. Which work order resulted in which as-built change? If you cannot answer that question by querying a database, you cannot answer it reliably at all.

Batch assembly loses provenance. When a drafter modifies drawings weeks after construction, there is no audit trail connecting a specific change in the drawing to a specific report from the field. The as-built is a single snapshot. Nobody can reconstruct how it got to that state, which changes are backed by evidence, and which are the drafter's best guess.

Handoff to operations inherits the debt. The as-built is typically the last deliverable before a project closes and the asset transfers to an operations team. If the as-built is wrong, operations discovers it in the worst possible way — during a repair, an expansion, or an emergency — when the cost of wrong information is highest.

The Map as a Living As-Built

Our approach does not produce an as-built record at the end of a project. The as-built record is the map your team has been working on throughout the project, and it builds itself as work happens.

Features on the map are the record. When a field worker edits a feature — moves a point, adjusts a cable route, adds a new splice location — that edit is the as-built update. It happens at the point of work, with GPS coordinates captured from the device, at the time the work is performed. There is no separate step.

Every edit is version-controlled. Each change creates a version entry: who made the change, when, and what the previous state was. The version history is compressed but never deleted. You can reconstruct the state of any feature at any point in time — not just the current state, but the full evolution from design through construction.

Field-submitted versions go through admin review. A field worker does not directly modify the shared map. They submit a version — a set of proposed changes — that an administrator reviews. The admin sees a diff: what changed, where, and how it compares to the current state. If the change makes sense, it is committed. If it does not, it is rejected with a note. This means the as-built record has a quality gate built into every update, not bolted on at the end.

Conflict detection prevents silent overwrites. If two field workers edit the same area, the system detects the overlap and flags it for resolution. One crew's update does not quietly overwrite another's. In traditional as-built assembly, conflicting field notes from different crews are often reconciled by the drafter's best judgment. In a versioned system, the conflict is surfaced and resolved explicitly.

Design to As-Built in One System

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

Import the design. Load the original design drawings — Shapefile, GDB, GeoPackage, DXF — into the map as draft features. These features land in a staging area where they can be reviewed, filtered by area, checked for collisions with existing data, and committed to the appropriate layers. The import is the design baseline.

Plan work against the design. Tasks are created on the map with geometry showing where work should happen and resource requirements showing what materials and labour are needed. The task geometry is the plan.

Execute and record. Field workers perform the work, then submit reports with GPS geometry showing where the work actually happened. The report geometry is the reality. If the cable ran along the south side instead of the north, the report geometry reflects that — at the time it happened, from the device that was there.

Update the map. Field workers edit the map features to reflect what was built. Move the cable line to its actual route. Add the extra junction box that was not in the design. Delete the planned feature that was not constructed. Submit the version for admin review.

Review and commit. An administrator reviews the field-submitted version, compares it against the design baseline and the reports, and commits it to the shared map. The committed map is now the as-built — not a separate document, but the same map the operations team will use going forward.

Handoff is automatic. When the project closes, the operations team inherits the current state of the map. There is no separate as-built deliverable to produce, review, and hand over. The map they see is the map the construction team maintained throughout the project. Every feature has a version history. Every change is traceable to a field submission and an admin approval.

The Audit Trail That Matters

The value of this approach is not just convenience. It is provenance.

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

The feature on the map has a version history showing every change from design through construction.
Each version entry records the submitter, the timestamp, and the admin who approved it.
The field reports that prompted each change are linked — with GPS geometry, photos, and material consumption records.
The import record shows the original design baseline that was loaded at the start.
Everything is exportable — GeoJSON, CSV, audit log — from the same system that produced it.

Compare this to the traditional answer: "here is a PDF that a drafter produced six weeks after construction finished." One of these answers invites trust. The other invites questions.

Summary

As-built records are one of the most consistently unreliable deliverables in infrastructure work, because they are assembled after construction from scattered field notes and fading memory.
The core problem is timing: separating the act of doing the work from the act of recording it creates a gap that widens with every project cycle.
Batch assembly after the fact loses detail, loses context, loses provenance, and passes inaccurate records to operations teams who discover the errors at the worst possible moment.
When the map is the as-built record and field workers update it as they work, the record builds itself — with GPS coordinates, version history, and admin review at every step.
Design drawings are imported as the baseline. Tasks represent the plan. Reports capture reality. Feature edits reflect what was built. The version history connects all of them.
Field-submitted versions go through admin review with a visual diff, so the as-built has a quality gate at every update — not a single review at the end of the project.
Conflict detection ensures that overlapping edits from different crews are surfaced and resolved, rather than silently reconciled by a drafter's judgment.
Handoff to operations is automatic: the map the construction team maintained is the map the operations team inherits, with full provenance for every feature.