The As-Built Is the Network Model

The as-built is not the last drawing

The phrase as-built sounds like a closing ceremony. The design is finished, the crews have built something, someone has redlined what changed, and a final package goes into a folder so the project can be paid, audited, or archived. That framing is understandable. It is also the reason many networks enter operations with a memory problem.

Fiber infrastructure is not a document-delivery business. The durable asset is a physical graph: routes, ducts, poles, handholes, vaults, splice closures, cables, tubes, fibers, ports, splitters, terminals, customers, and serviceable locations. The thing people need after construction is not merely proof that a contractor did work. They need a usable model of what now exists.

That model has to support several jobs at once. A NOC needs to understand which customers or circuits may be affected by a cut. A field supervisor needs to dispatch crews to the right span or closure. A designer needs to know whether capacity remains for an expansion. A finance or grant team needs evidence that funded facilities were deployed where promised. A support engineer needs to explain why a service claim is credible. A future contractor needs to know what they are about to touch.

If the as-built is just a final drawing, those jobs get solved socially. Someone asks around. Someone remembers a field change. Someone opens a PDF, compares it to a GIS layer, checks a spreadsheet, messages the contractor, and hopes the splice sheet is the latest one. That can work for a while. It does not scale into an operating discipline.

This cairn is the companion to The Trace Is the Baseline. That article argued that optical test evidence should become operational memory. This one widens the frame: test evidence is one part of a larger as-built model. The network needs to remember where it is, how it connects, what changed from design, who reviewed the change, and which evidence supports the record.

Construction creates facts that operations inherit

Design is a plan; construction is a negotiation with the world. Soil, poles, permits, make-ready, blocked conduit, missing address points, customer changes, weather, easements, and field judgment all modify the plan. Some changes are small. Some are the difference between a route that can be restored quickly and one that becomes a mystery during an outage.

The important point is that field changes are facts. They are not paperwork deviations unless the only customer for the record is the closeout reviewer. Once the network is live, those facts become operating constraints.

Consider a few ordinary examples:

None of these are exotic. They are exactly the sort of details that make outside plant work outside plant work. The problem starts when the details are captured as marginalia instead of model updates.

Osprey Strike’s ECO workflow already hints at the downstream handoff. After an emergency callout is complete, downstream activities include circuit testing, invoice generation, billing, and as-built documentation. That is a correct scope boundary for the current Strike product, but it is also a useful warning: the end of one workflow is the beginning of another. If the completed field task produces only photos and forms, someone still has to convert evidence into the network’s operating memory.

This is the same boundary-object problem described in the ECO trail. The construction team, NOC, GIS editor, and grant reviewer can all point at “the as-built” while meaning different slices of it. The system has to preserve the shared handle without flattening every audience into one view.

Geometry alone is too thin

GIS is the obvious home for as-built data because fiber networks are spatial. A route needs geometry. Handholes, cabinets, poles, terminals, splice closures, and serviceable locations need coordinates. Public broadband programs, including the FCC’s Broadband Data Collection ecosystem, have pushed the whole industry toward addressable, location-based records rather than vague service-area claims.

But a line on a map is not a network model. It is a start.

The operational network is not just where the cable runs. It is how the route contains physical assets, how cables contain fibers, how fibers connect through splice trays and ports, how terminals relate to serviceable locations, how customers depend on paths, and how evidence proves those relationships. A spatial layer that cannot answer connectivity questions is a map of construction, not yet a model of operations.

That distinction matters because different failure modes hide behind the same geometry. Two route segments can share a corridor but terminate in different closures. Two fibers can run through the same cable but serve different customer groups. A splice closure can be correctly placed on the map while the internal splice table is wrong. A serviceable location can sit near a terminal but still lack a valid drop path. A future ECO may need to know which strand is dark, not merely which street the cable follows.

flowchart TD
  G[Geometry] --> A[Assets]
  A --> C[Connectivity]
  C --> S[Services and Locations]
  T[Test Evidence] --> M[Operating Network Model]
  P[Photos and Redlines] --> M
  R[Review Decisions] --> M
  G --> M
  A --> M
  C --> M
  S --> M

Esri’s telecom materials frame GIS as a way to plan, construct, manage, and optimize fiber networks. That is the right ambition, but the operative word is manage. Management requires more than drawing features. It requires a model that can support workflow: acceptance, provisioning, maintenance, outage restoration, capacity planning, and reporting.

The simplest test is whether the system can answer questions during a real event. “Where is the closure?” is necessary. “Which fibers pass through it, which services depend on them, when was that record last verified, and what field evidence supports it?” is the operating bar.

A live model needs provenance

The model should remember not only its current answer, but why it believes that answer. This is where Osprey Vantage’s lakehouse framing is surprisingly useful for outside plant records. Vantage describes a landing zone for raw API responses, bronze validation, silver deduplication and merge, and future gold views for business-ready answers. That pattern is usually discussed as analytics architecture. It also describes a healthy posture toward network truth.

Raw source capture matters because field data is messy. A contractor form may be incomplete. A CAD export may carry stale design assumptions. A GIS edit may fix geometry while leaving splice metadata behind. An OTDR report may be valid but tied to the wrong strand. A photo may prove the closure location but not the internal fiber assignment. If the system keeps only the final edited answer, it loses the ability to explain or correct itself.

A provenance-aware as-built workflow keeps layers of belief:

That layering protects the team from two opposite failures. The first failure is blind trust: treating every field submission as true because it came from the field. The second is invisible cleanup: letting an office editor repair the data without preserving the evidence and decision trail. Both create brittle confidence.

This is not a demand for heavyweight bureaucracy. A small team can start with source file hashes, submitter identity, timestamps, review state, and a changelog. The point is that the current model should have a route back to the facts that created it.

NTIA’s BEAD guidance is a useful external pressure here. Funded networks are not just built; they carry obligations, reporting, and evidence requirements. The exact grant schema varies by program and state, but the architectural lesson is stable: if a network claim matters financially or operationally, the supporting record needs provenance.

Field change is a workflow, not a correction

The worst version of as-built handling is a late cleanup ritual. The design says one thing, construction returns a package of changes, and someone quietly edits the drawing until it resembles reality. By the time operations sees the result, the change has no life of its own. It is just the current shape.

That loses important information. Was the deviation approved before construction or discovered after the fact? Did it affect permitting? Did it consume spare capacity? Did it change a customer commitment? Did the contractor provide enough evidence? Did a reviewer reject part of it? Should future designs avoid the same assumption?

A better product shape treats as-built changes as a workflow:

stateDiagram-v2
  [*] --> Proposed
  Proposed --> EvidenceAttached
  EvidenceAttached --> InReview
  InReview --> Accepted
  InReview --> NeedsCorrection
  NeedsCorrection --> EvidenceAttached
  Accepted --> ModelUpdated
  ModelUpdated --> ViewsRefreshed

The workflow can be lightweight. It does not need to turn field reality into a committee meeting. It needs to make state explicit: proposed, evidence attached, reviewed, accepted, rejected, superseded. Those states help both people and software. People can see what is waiting on whom. Software can decide whether a fiber path is trusted enough for provisioning, whether a closeout package is complete enough for payment, and whether a grant milestone has evidence behind it.

Caltrans construction guidance for electrical systems gives a public-sector version of this discipline: verify fiber-optic tests, check measured values against requirements, and make sure work is performed by qualified technicians. The exact construction manual is not our product spec. The useful pattern is that acceptance is an observed, recorded event, not a vague feeling that installation is probably fine.

This is especially important for emergency repair. An ECO may create new facts under pressure: a damaged span, a temporary restoration, a replaced closure, a changed splice, a new baseline trace. The repair workflow can close before every downstream model update is complete. That is fine if the handoff is explicit. It is dangerous if “complete” means nobody knows which records still need to be reconciled.

Software shape: events into current network projection

For Osprey-shaped systems, the natural architecture is an event history plus projections. That is already the posture in Strike: events preserve what happened, and projections turn those facts into useful views for NOC operators, support, and integration workers. The same pattern fits as-built network data.

The event stream should preserve observed and reviewed changes:

The projections should serve readers:

This avoids the trap of one universal “network” table that tries to satisfy every context. The current connectivity graph can be optimized for impact analysis. The map can be optimized for field navigation. The closeout queue can be optimized for missing evidence. The grant view can be optimized for eligible locations and milestone reporting. They should agree where they overlap, but they do not need the same shape.

The important move in that scenario is separation. The ECO can be complete. Service can be restored. The network model can still have a pending update. Those are not contradictions. They are different projections over a shared operational history.

What to capture first

A first useful system should not try to become a full fiber management suite in one pass. That way lies either paralysis or a brittle model nobody trusts. The first milestone should be the minimum record that converts closeout evidence into operational memory.

Start with the fields that future workflows will be angry about if they are missing:

This is enough to do real work. It lets a system answer whether a closeout is complete, whether a fiber path is trusted, which evidence supports a model change, and which assets or services may be impacted by a future event. It also gives later automation a place to attach: vendor-format parsers, mobile capture, QA rules, design-vs-built comparison, network graph analysis, and agent-assisted review.

The hard part is not inventing fields. The hard part is deciding which claims are allowed to become operational truth. A redline can propose geometry. A photo can support location. A splice sheet can claim connectivity. A test record can prove optical performance. A reviewer or rule can accept the claim. Keeping those roles distinct is what lets the model improve without becoming a rumor database.

What the team should take away

The practical lesson is that closeout is not the end of construction data. It is the beginning of operations data.

1. The as-built is an operating model - It should represent the network people will provision, repair, expand, audit, and explain, not just the project someone finished.
2. Geometry is necessary but insufficient - A useful fiber record joins spatial location with assets, connectivity, evidence, status, ownership, and provenance.
3. Changes need workflow - Field deviations should move through submission, evidence, review, acceptance, and projection rather than disappearing into quiet edits.
4. Provenance is a product feature - The model should answer why it believes a route, splice, capacity, or serviceability claim.
5. Projection design matters - The NOC, GIS editor, grant reviewer, provisioning workflow, and capacity planner need different views over the same source-backed truth.

This is the same larger argument the Osprey trail keeps circling: operational software becomes trustworthy when it preserves meaning across boundaries. The as-built is one of the most important boundary objects in a fiber business. Treat it as paperwork and the network forgets itself. Treat it as a model and every future workflow starts from a better place.

Discussion prompts

• What is the smallest as-built record we would trust for ECO restoration: route geometry, splice relationship, test baseline, photos, reviewer, or something else?
• Which team should be allowed to turn a submitted field deviation into accepted operational truth, and what evidence should be required before that happens?
• If we built only one projection first, which would create the most leverage: closeout evidence queue, NOC impact view, serviceability view, or connectivity graph?

References

1. FCC Broadband Data Collection - Public program context for location-based broadband availability data and the industry's movement away from informal coverage claims.
2. NTIA BEAD Frequently Asked Questions v19 - Federal guidance showing that funded broadband facilities carry ongoing requirements, reporting, and evidence concerns beyond initial construction.
3. Caltrans Construction Manual, Section 4-87: Electrical Systems - Practical public construction guidance that treats fiber testing, measured values, and technician qualification as verifiable acceptance activities.
4. Esri: GIS Software for Fiber Networks - Telecom GIS framing for planning, constructing, managing, and optimizing fiber broadband infrastructure.
5. Fiber Broadband Association: Building Fiber Networks Through Software - Industry discussion of software's role between planning, construction management, and the move into operations.
6. VETRO: Fiber Optic Design, Cloud GIS vs Desktop - Vendor perspective on keeping splice documentation, field evidence, redlines, and operations tied to a live network model.
7. South Carolina ORS Broadband GIS Data Dictionary - Example of a grant-oriented GIS schema where structured location and project attributes become part of broadband investment tracking and verification.