# Fiber Network Construction Record Accuracy: A QA Release Guide

**Title tag:** Fiber Network Construction Record Accuracy 2026  
**Meta description:** Fiber network construction record accuracy starts with source rules, positional checks, attribute tests, exception control, and a defensible 2026 release gate.  
**Author:** Devin Martinez  
**Published:** August 24, 2026  
**Last updated:** August 24, 2026  
**Category:** As-Built & Documentation  
**URL:** https://draftech.com/blog/fiber-network-construction-record-accuracy  
**Primary keyword:** fiber network construction record accuracy  
**Word count:** 2904  
**Read time:** 12 minutes

---

A route can look finished on a plan sheet while 1 handhole carries a different ID in the survey export; the splice record; and the GIS. Each source may be internally tidy. None alone proves what was installed. That conflict is where construction-record accuracy becomes a release decision instead of a drafting cleanup task.

We treat accuracy as claim-by-claim evidence control. This guide shows how our reviewers define acceptance requirements; test redlines and coordinates; validate attributes and connectivity; preserve source conflicts; and release a record without turning uncertainty into false fact. The [fiber construction closeout process](/blog/fiber-construction-closeout-process) covers the wider handoff sequence. Here we stay on record QA.

## What Fiber Network Construction Record Accuracy Means

Fiber network construction record accuracy is the degree to which an accepted record represents installed assets; attributes; relationships; and supporting evidence for its stated use. We assess it across **5 separate dimensions**, then compare each tested claim with the owner's project requirements rather than applying one universal score or coordinate tolerance.

The first dimension is **completeness**: every applicable feature; relationship; and required field must be present or carry a controlled exception. The second is **positional conformance**: tested locations must satisfy the project-defined method and tolerance for that asset class. A route overview may support planning while a depth-sensitive crossing record supports a different decision. We do not let one broad accuracy label conceal those different uses.

The remaining dimensions are **attribute validity**; **logical consistency**; and **source traceability**. A handhole can sit at the accepted coordinate while its status is wrong. A cable can carry valid attributes while its endpoints form an impossible path. A record can look internally consistent yet still lack the measurement or approval that explains why the accepted value replaced design. We report those defects separately because each one needs a different correction.

ISO 19157-1:2023, *Geographic information: Data quality, Part 1*, sets principles for describing; evaluating; and reporting geographic-data quality. It does not set minimum acceptable quality levels. That limitation matters. We define fitness through the owner's data specification; the controlling contract; and the intended operational use. Calling a coordinate "survey grade" does not answer which datum was used or whether the tested value passed the named requirement.

Our measurement report keeps the denominator visible. Required-field completeness means populated applicable fields divided by applicable required fields. Positional conformance means tested observations inside the project criterion divided by observations tested. Traceability coverage means accepted claims with a valid source reference divided by claims reviewed. These are proposed project controls, not industry thresholds. We never blend them into one percentage that lets a strong geometry result hide broken splice relationships. Before release, the reviewer should compare every changed asset against its supporting field evidence; verify the recorded disposition; preserve the original observation; and make unresolved differences visible to the owner instead of silently choosing a convenient value.

## Define the Acceptance Matrix and Source Rules

Accuracy starts before collection. We create one acceptance-matrix row for each asset class or material claim, then name its intended use; controlling requirement; preferred evidence; review method; and acceptance authority. FHWA-HIF-24-062, *Guide for Digital As-Builts Using Simplified Digital Workflows*, recommends defining users; collection responsibility; timing; verification; format; accuracy; and completeness before field work begins. FHWA presents guidance, not a universal fiber mandate. That discipline lets a later operator understand why the accepted record differs from the issued design; which source controlled the change; who approved the disposition; and where uncertainty still deserves targeted field confirmation.

A claim-specific rule is stronger than one universal source order. Project-compliant field measurement can control installed geometry. An accepted RFI or field-change record can control authorization. Reconciled splice documentation and test identifiers can support connectivity. Installation or inspection evidence can support material configuration. The issued design remains the comparison baseline. It is not proof of installed condition merely because no later file appears in the folder. A defensible package also keeps geometry review separate from attribute review because a feature may appear in the correct place while carrying the wrong identifier; status; ownership; material; or connection to adjacent network assets.

The matrix also assigns a record revision and archive destination before review begins. That control prevents an accepted PDF from drifting away from the GIS dataset that produced it. We require the matrix row to state whether the reviewer tests every record or a project-approved sample. Sampling is a project choice, not an implied shortcut. Full-population checks suit duplicate IDs and missing parent keys because software can evaluate them deterministically. Field remeasurement may use a separate project-defined population because access; cost; and risk differ by asset class. The acceptance authority sees that distinction before signing. When the final gate is explicit, construction teams know what evidence to submit; CAD and GIS reviewers know what to test; owners know which exceptions remain open; and operations receives a record whose limitations are documented rather than hidden.

| Record claim | Preferred evidence | QA test | Disposition path |
| --- | --- | --- | --- |
| Installed geometry | Project-compliant field measurement | CRS; method; tolerance; and check observation | Accept; remeasure; or log variance |
| Change authorization | Accepted RFI or project change record | Asset; revision; approval; and installed status | Accept; clarify; or reject change |
| Cable identity | Installation and inspection evidence | Unique ID; count; type; and endpoint match | Correct record or open exception |
| Fiber connectivity | Splice record tied to test identifiers | Continuous path with no competing assignment | Reconcile; retest; or reject path |
| Record acceptance | Named owner or engineer decision | Requirement; evidence; result; and authority | Release or retain on hold |

Use the table as a control map. It is not a nationwide specification. ASCE/UESI/CI 75-22, *Standard Guideline for Recording and Exchanging Utility Infrastructure Data*, addresses location; geometry; and feature attributes for utility records. Its use still depends on adoption by an owner; contract; regulation; or other controlling instrument. We cite the instrument that governs the project rather than turning a voluntary standard into law through confident wording.

- **Requirement source:** name the contract clause; owner standard; permit term; or approved data specification.
- **Evidence source:** identify the observation; record revision; test file; or approval that supports the claim.
- **Review control:** state the method; tested population; reviewer; and acceptance authority.
- **Exception path:** define who resolves a conflict and which dispositions the project permits.

NYSDOT Item 634.10010008, *As-Built Plans for ITS Projects*, offers a contract-specific example. Its package can include as-let plans and amendments; shop drawings; field change sheets; implemented revisions; equipment details; fiber connections; and test data. We use that document to illustrate how one owner can define evidence. We do not present its contents as required for every network.

## Test Redlines and Coordinates Without False Certainty

Redline completeness is a coverage test, not a visual impression. We divide the work into expected segments or asset groups. Each applicable unit receives a documented change or an explicit no-change declaration. A missing redline does not prove construction followed design. Our [redline versus as-built drawing comparison](/blog/redline-vs-as-built-drawing-comparison) explains the record roles. This QA step asks whether the submitted evidence accounts for every expected unit.

Each change should identify the controlling issued revision; asset or segment ID; observed installed condition; location reference; recorder; date; evidence; and approval state. Controlled status values keep observed separate from directed; approved; installed; verified; and accepted. We scan for orphan marks and unreferenced photographs. We also find revision clouds with no description; asset IDs that change between sheets; and field notes that never reached the structured record.

Coordinate review begins with the declared coordinate reference system; datum; projection; units; collection method; and equipment. Next we apply the asset-specific project criterion to separately controlled check observations. We inspect outliers and systematic shifts. We also test for duplicate structures; implausible coincidences; broken route continuity; and disagreement with stationing or field imagery. Device precision alone is not positional conformance. More digits can describe the wrong place with greater apparent certainty.

Our upstream [field survey data accuracy guide](/blog/field-survey-data-accuracy-fiber-construction) addresses collection quality. We do not restate it here. Construction-record QA begins when that field evidence must reconcile with design; redlines; approvals; and the record proposed for release. A reviewer should preserve the original observation and transformation history, then record the check result. Snapping a surveyed handhole to a basemap because the screen looks cleaner destroys evidence rather than improving accuracy.

FHWA-HIF-24-062 assigns GIS staff a role in defining location-accuracy requirements and describes field verification of contractor-collected data. That workflow supports a practical rule: the person who collected a coordinate should not be the only person deciding whether it passes. Independence can come from a separate check observation or a controlled review source. The project defines the method. We document which population was tested and which failures were remeasured. A reviewer should therefore trace each released value back to field evidence; compare it with the issued design; record the disposition; and keep the exception visible until an authorized owner representative accepts the result.

## Validate Attributes, Identifiers, and Connectivity

Geometry can pass while the network record fails. We run full-population checks for required fields; data types; value domains; duplicate identifiers; unsupported defaults; and invalid lifecycle states. Proposed features marked installed receive their own failure class. Lengths and quantities are checked against the permitted schema and evidence source. An empty field is not always a defect, but an unexplained null in a required claim cannot quietly pass because the map draws correctly.

The Federal Geographic Data Committee's Content Standard for Digital Geospatial Metadata separates attribute accuracy; logical consistency; completeness; positional accuracy; and lineage. Esri's ArcGIS Pro guidance likewise describes completeness through the presence or absence of features; attributes; and relationships. Those distinctions fit fiber records well. We keep validation reports by defect type so a loader can correct a domain value without masking a missing cable or a broken parent relationship.

- **Identity check:** find duplicate structure; cable; conduit; closure; and splice-record IDs.
- **Parent check:** confirm every cable and fiber record points to an existing governed object.
- **Path check:** trace each tested endpoint through structures and splice events without inference.
- **Evidence check:** reconcile each required test artifact to the cable; fiber; direction; and endpoints it governs.

Connectivity needs deterministic queries plus focused visual review. Queries can find orphan cables or competing assignments across the complete dataset. A reviewer still judges whether a route transition is plausible and whether a field change explains it. We retain query output by exception ID. A total such as 40 failed relationships is weak unless the report shows whether 1 bad parent caused them or whether 40 independent paths failed. Root-object classification keeps corrective work honest.

Test files require the same identity discipline. An OTDR directory is not connected evidence until each artifact resolves to the governed cable or fiber path and records its direction; wavelength; date; status; and revision. We do not infer a match from a similar filename. For [multi-market engineering programs](/states/), our schema rules stay consistent while project tolerances and owner requirements remain market-specific. That separation lets us compare process quality without inventing one national acceptance threshold.

## Reconcile Conflicts Through a Controlled Exception Log

Consider 1 handhole shown at the design coordinate; shifted on a redline; measured at a third position in survey data; and labeled with a different ID in the splice record. Choosing the newest file is not reconciliation. We split the conflict into claims. Survey evidence may control location. The accepted change record may control authorization. The splice record may support connectivity after its identifier is reconciled. Each decision receives its own source reference.

An exception entry needs a unique ID; affected asset or claim; conflicting source revisions; exact values in conflict; governing requirement; consequence; resolver; required action; reviewer; disposition; acceptance date; and final source reference. Semicolon-delimited controls are deliberate here because each field answers a different audit question. We preserve the rejected value and the reason for rejection. Silent overwrites make the final file cleaner while making the decision impossible to reproduce.

Useful dispositions include correct from verified evidence; supersede an obsolete source; request clarification; remeasure the condition; accept a documented variance; defer as an approved open exception; or reject the segment. The permitted set belongs in the acceptance matrix. An open issue can remain only when the controlling procedure allows it and the acceptance authority names the limitation. An unresolved value must not appear as verified fact merely to improve a completion metric.

> **Self-critical note:** our claim-by-claim exception process creates more review work than flattening every source into one final drawing. It can slow a rushed closeout. We accept that trade-off because a fast overwrite transfers hidden uncertainty to locating; restoration; and later network changes. We would not recommend the method if the record could not preserve source history.

FHWA-HIF-24-062 directs reviewers to reconcile construction changes and review tolerance deviations before acceptance. Its post-processing workflow includes reconciliation; quality checks; attribution; and system-of-record integration. We translate that guidance into a reproducible log. After correction, we rerun the same validation set against the same release candidate. The report compares exception IDs and tested populations with the prior run so the reviewer can see what changed instead of trusting a fresh green dashboard.

The exception owner should distinguish record correction from field correction. Fixing a transposed cable ID may require no site visit. Resolving a disputed underground structure location may require remeasurement. We record both the proposed action and the evidence needed for closure. That distinction protects schedule discussions from false equivalence. It also lets our [integrated CAD and GIS delivery model](/about) route a defect to the discipline that can actually resolve it.

## Choose a Release Gate the Owner Can Defend

Release is a controlled state change. We record whether evidence was received; completeness passed; positional checks passed; attributes and schema passed; connectivity reconciled; exceptions were dispositioned; owner review finished; and the system-of-record load was validated. A failed gate keeps the affected record on hold. A permitted exception travels with the record and its limitation. The release package includes the accepted revision; QA results by check type; source index; exception register; known limitations; approval record; and archive destination.

Poor records create operational consequences without needing a dramatic statistic. Crews repeat field investigation. Locators search for the wrong structure. Planners assign capacity against retired plant. GIS and inventory systems disagree about the same cable. We connect these pains to our [fiber as-built documentation service](/services/as-built-documentation) by keeping field evidence; drawing revisions; structured attributes; and acceptance decisions in one reviewed control path.

**Construction manager:** choose a segment-based release when contractor evidence arrives by work area. Hold only the affected segment when the contract permits partial acceptance, but keep shared cable and connectivity dependencies visible. The gate should name the reviewer and the exact dataset version that passed.

**CAD or GIS manager:** recommend release only after repeatable queries pass against the load candidate. Preserve the schema version and validation output. A clean drawing export is not enough when duplicate IDs or orphan relationships remain in the system that operations will edit.

**Network owner:** release the accepted baseline with every approved exception and known limitation attached. Require a named return path for post-closeout corrections. The owner should be able to reproduce why 1 disputed claim was accepted without calling the person who happened to attend the final meeting.

If your record package is nearing acceptance and its survey; redline; splice; or GIS sources still conflict, email [info@draftech.com](mailto:info@draftech.com). We can review the acceptance matrix and exception path before unresolved construction evidence becomes the operating baseline.

> **[Talk with Draftech about a defensible fiber record release.](/#dt-contact)** Bring the controlling requirements; one source index; the latest validation results; and the open-exception register so the review starts with evidence rather than presentation.


## Frequently Asked Questions

### What does fiber network construction record accuracy include?

Fiber network construction record accuracy includes at least 5 separate dimensions: completeness; positional conformance; attribute validity; logical consistency; and source traceability. A record can pass one dimension and fail another. The owner should define the intended use and project requirement for each claim, then directly preserve the evidence and disposition that support the accepted value.

### Which source controls when fiber construction records disagree?

No 1 source controls every claim. Project-compliant measurement can support installed location; an accepted change record can support authorization; and reconciled splice evidence can support connectivity. Apply the source rule written for the specific claim. Record every conflict in the exception log, then preserve the review decision instead of selecting whichever file carries the newest timestamp.

### Is there one coordinate tolerance for every fiber as-built?

No 1 coordinate tolerance applies to every fiber record. The owner or controlling project document should set the method and criterion by asset class; intended use; coordinate reference system; and collection condition. ISO 19157-1:2023 does not set a minimum acceptable geographic-data quality level. A planning route and an excavation-sensitive structure record can therefore need different controls.

### How do we measure whether contractor redlines are complete?

Divide the project into expected segments or asset groups, then require 1 documented redline or an explicit no-change declaration for every applicable unit. Check the controlling revision; asset ID; observed condition; location reference; date; evidence; and status. Missing documentation remains an exception. It cannot be treated as proof that the segment was installed exactly as designed.

### Can a fiber record be released with open exceptions?

A fiber record can carry open exceptions only when the controlling procedure permits them and the named acceptance authority approves each disposition. The release should identify the affected asset; conflicting evidence; known limitation; responsible owner; and follow-up action. Keep the exception attached to the accepted revision. Even 1 unresolved condition must not be displayed as verified fact.

---

**About Devin Martinez:** Leads field operations, OSP field survey, wireless engineering, and delivery technology for Draftech International. [info@draftech.com](mailto:info@draftech.com)