As-built documentation
Capturing what was actually built — the record that supports operations, faults, and future expansion.
As-built documentation captures what was actually built, as opposed to what was originally designed. Routes get adjusted in the field, splice points move, equipment changes — without an accurate as-built, future operations work is guesswork and faults take longer to find.
We produce as-built documentation for fibre builds and EV infrastructure deployments, working from field markups, photos, GPS-logged data, and any field reports the construction team supplies.
Why as-built work is its own discipline
It would be neat if construction crews delivered as-builts as a by-product. They don’t, in practice — for understandable reasons:
- Field crews aren’t draughtsmen. They mark up paper drawings, photograph deviations, and capture data — but turning that into structured records is a different skillset.
- Construction priorities run through completion. Build, test, hand over the active network. As-built documentation lags.
- Data quality varies wildly across crews. Some splicers document meticulously, some don’t. The asbuilt has to make sense regardless.
The result: as-built work is the engineering layer that turns field artefacts into operational records.
What’s in an as-built deliverable
A complete as-built package contains:
- Route records — actual fibre, conduit, or cable routes as built, against accurate base mapping
- Splice records (fibre) — confirmed splice points, fibre allocations, splice loss results
- Asset records — locations, types, serial numbers, and condition for cabinets, closures, chambers, splitters, chargers, equipment
- Drop records (fibre) — every premise served, with attachment method and fibre assignment
- Test results — OTDR traces, splice loss measurements, pressure tests, integrated into the records
- Deviation log — where the build deviated from design, why, and the operational implication
- Photographic record — keyed to asset records, supporting future fault response
Format options — markup vs redraw
Two common approaches, picked per project:
Markup approach — the design drawings are edited with red-line revisions reflecting actual build. Faster, fine when deviations are minor. Output is the original design + structured red-line layer.
Full redraw — all records are rebuilt against actual-build data. Slower, the right choice when significant deviation occurred or when the design was lower-fidelity than the asbuilt needs.
We assess at start which approach fits the project’s deviation profile.
Output formats
As-builts deliver into whatever format the network owner’s asset records require:
- GIS-native (QGIS, ArcGIS, PostGIS, Esri Utility Network) — most common for ongoing operations
- CAD output (DWG) — where the asset team standardises on CAD
- Operator-specific platforms — VETRO, IQGeo, OSPInsight, custom systems
- Hybrid — where the data lives in GIS but specific drawings are needed in CAD for fault response or expansion planning
Inputs we need
An as-built engagement runs on:
- Original design package (LLD, construction pack)
- Field markups and field reports from the construction crew
- Photos and GPS-logged data where the crew captured it
- Test results — OTDR files, splice loss reports, pressure test logs
- Asset metadata — serial numbers, equipment install dates, manufacturer info
Where field data is patchy, we either escalate for survey re-walk or flag the gaps in the deliverable rather than papering over them.
Standards we work to
Per project, as-built records align with:
- Operator standards — BT, Openreach, Virgin Media, ILEC, altnet asset record formats
- Funder requirements — RUS as-built submission, BEAD reporting
- Operations system schema — whatever the asset record system requires
Common pitfalls in outsourced as-built work
Records that don’t reflect actual build. As-builts that match the design rather than reality are worse than no as-built — they actively mislead. We treat field data as authoritative even where it deviates from the design.
Test results disconnected from records. OTDR traces and splice loss reports stored separately from the asset record force fault responders to chase data across systems. We integrate test results into the asset record at the splice or asset level.
Generic data quality with no flagging. As-builts that paper over field data gaps with assumptions create operational debt. We flag where data was incomplete, what was assumed, and what should be confirmed during the next maintenance window.
Lost institutional knowledge. When the construction team has built thousands of metres and the as-built team starts cold, context gets lost. We brief on the project before starting, and where possible we maintain continuity from LLD or construction pack work into asbuilt.
Typical timelines
- Small project (single site or under ~500 premises) — 2-3 weeks from field data delivery
- Mid-sized rollout — 4-8 weeks
- Large programme — rolling delivery, typically batched per construction phase
How we deliver
As-built work runs through our integrated UK-and-offshore model. Production happens in the offshore team — high-volume work that benefits from efficient capacity. Onshore reviewers handle data quality assessment, deviation log review, and standards compliance before records are released to the operations team.
Talk to us about an as-built project
Tell us the network shape, the construction status, and what asset record system the records need to feed. We’ll scope and price within two business days for typical projects.
Typical deliverables
- Updated route and asset records reflecting actual build
- Splice schedules with confirmed fibre allocations (fibre projects)
- GIS-native asset records (QGIS / ArcGIS / PostGIS)
- Field-captured deviations from design
- Marked-up drawings or full redraws as needed
- Test result integration (OTDR, splice loss, pressure tests)
Who buys this
Network owners after construction — to support operations, fault response, regulatory reporting, and future expansion planning.
Talk to us about delivery options
Tell us what you need delivered, what your timeline is, and what format the downstream team needs the output in. We'll come back with scope, price range, and proposed approach.