# CAD/GIS Documentation Standards That Hold Up at Every Project Phase

**Author:** Devin Martinez

**Published:** 2026-05-04

**Updated:** 2026-05-04

**Category:** CAD / GIS

**URL:** https://draftech.com/blog/cad-gis-documentation-standards-osp-fiber-networks

**Description:** CAD/GIS documentation standards that hold up at every project phase: layer naming, CRS discipline, file handoff, and version control for OSP fiber builds.

**Visible word count:** 2912

---

I've seen a $2.3 million fiber build come within 48 hours of a stop-work order, not because of bad engineering, but because the CAD deliverables didn't match the county's required coordinate system. Forty-seven poles worth of stake-out data. Wrong CRS. Field crew standing around. That's not a horror story. That's Tuesday in this industry.

CAD/GIS documentation standards don't get talked about the way they should. Everyone agrees they matter. Few teams actually enforce them. And when a project spans 14 months, three subcontractors, two GIS analysts, and a county permitting office that wants everything in NAD83/StatePlane, the gaps show fast. The rework isn't just expensive. It delays revenue. It kills contractor relationships. It creates liability exposure that follows the project into operations.

This isn't a tutorial on how to use ESRI ArcGIS. It's a breakdown of what works, what consistently fails, and what Draftech's documentation process looks like on real OSP fiber projects. If you've shipped a fiber construction package and then spent the next three weeks cleaning up layer conflicts or re-exporting because the municipality couldn't open the files, this is for you.

## Why Documentation Standards Break Down on Real Projects

Standards don't fail in planning. They fail in execution, usually around month four when a second drafter joins, or when someone decides "just this once" to use a shortcut layer name.

I've never understood why firms put so much energy into front-end standards documents and then provide zero enforcement mechanism downstream. A 40-page CAD standards guide is worthless if no one checks compliance before handoff. And most don't. What happens instead is a slow drift: layer names get abbreviated differently across files, coordinate systems get assumed rather than confirmed, file versions get named with initials and dates that mean nothing six months later.

The core failure is usually one of three things. First: no single source of truth. Multiple drafters working from local copies, saving to different folders, sending files over email instead of through a managed project directory. Second: coordinate system assumptions. Someone opens a shapefile in QGIS, doesn't verify the CRS, exports it, and now your design file is subtly offset from the real-world geometry. 0.3 meters might not sound like much. On an aerial strand with tight clearance specs, it's a re-survey. Third: no enforced naming convention. This sounds minor. It isn't. When [LLD quality control](https://draftech.com/blog/lld-quality-control-checklist-fiber-design-errors) reviews a package and finds 11 different layer naming conventions across 6 CAD sheets, every QC pass takes three times as long. That time adds up fast.

The real cost of poor standards isn't just the rework. It's the downstream trust problem: with clients, with permitting offices, with field crews who've been burned by bad data before. So why don't more firms enforce documentation standards consistently?

## Layer Naming Conventions That Actually Work in the Field

Bad layer names are organizational debt. You pay for them every time someone opens the file.

Here's a naming structure we've standardized on for OSP fiber projects. It follows a three-part format: [Discipline]-[Feature Type]-[Status]. So you'd see something like FIBER-CONDUIT-PROPOSED or FIBER-AERIAL-EXISTING or CIVIL-ROW-BOUNDARY. Simple. Consistent. Immediately legible to anyone who opens the file, including the county engineer who's reviewing your permit set at 4 PM on a Friday and doesn't have time to decode mystery layers.

The discipline prefix matters more than people think. On multi-utility builds (where you might have joint trench with electric, gas, and telecom), a flat layer structure is a disaster. Prefixing with FIBER vs. ELEC vs. GAS lets drafters and reviewers filter instantly. ESRI ArcGIS handles this fine. AutoCAD Civil 3D handles it fine. The problem isn't software capability. It's discipline.

Status suffixes (PROPOSED, EXISTING, ABANDONED, FUTURE) eliminate the most common review error I see: someone drafting over existing infrastructure because the layers looked similar. That distinction should be visible immediately. Not buried in properties.

One more thing. Document your layer colors by status, not by feature. Proposed = blue. Existing = gray. Conflict = red. I've seen firms do it the other way (color by feature type) and it looks fine until you have 40 layers in a single file and no one can quickly distinguish what's new construction from what's existing. Don't do that.

## Coordinate System Discipline: Why CRS Errors Cost Real Money

This is where I'll get slightly ranty, because I've watched too many projects absorb unnecessary costs from CRS errors that were entirely preventable.

NAD83. That's the baseline. Virtually every state DOT, VDOT included, requires it. Most county GIS portals deliver data in it. Your field survey data should come in with it explicitly stated. Not implied. Not assumed. Stated in the metadata, confirmed in the file, verified before you start drafting.

The problem is that data often enters projects from multiple sources (county parcel data, Google Earth exports, utility atlas shapefiles, field GPS units), and each has its own CRS. Sometimes WGS84. Sometimes NAD83. Sometimes a local projection. Treating those as equivalent is how you end up with design geometry that's off by 1.1 meters from the physical world. In a conduit bore under a state highway, 1.1 meters is the difference between your bore path and someone else's infrastructure.

The discipline required is simple but non-negotiable: define your project CRS at kickoff, document it in every file header, and enforce a reprojection checklist before any external data gets incorporated. Every. Single. Time.

We've seen [field survey data accuracy](https://draftech.com/blog/field-survey-data-accuracy-fiber-construction) errors that traced directly back to undocumented CRS mismatches between the survey crew's GPS output and the design CAD file. The field crew hit a storm drain they shouldn't have. Nobody expected it. The survey was actually right. It just got reprojected wrong on import. That mistake cost the client roughly $34,000 in additional bore scope and delay.

Not a hypothetical. That happened on a 2021 project in a mid-Atlantic county I won't name.

Set your CRS at kickoff. Document it explicitly. Verify every imported dataset before it touches your design. This works in theory. In practice, it's skipped constantly, until it isn't, and someone pays for it. How many resubmittals could have been avoided with a five-minute CRS check? Most of them.

## File Handoff Standards and What Gets Lost Without Them

A fiber construction package that can't be opened, imported, or referenced by the next person in the chain is not a deliverable. It's a problem deferred.

File handoff standards need to address four things: format, version, naming structure, and metadata. Format is obvious: know what your client, subcontractor, or permitting agency can actually receive and open. DWG version matters. Some municipalities are still running AutoCAD 2018 or earlier. Sending a 2024 DWG to a county office that can't open it isn't their problem to solve. It's yours. Check before you deliver.

Naming structure at the file level should mirror your internal project structure. A file named "Rev_FINAL_v3_ACTUALFINAL_DM.dwg" is a documentation failure. Use a format like [ProjectCode]-[Sheet]-[Rev]-[Date]. Something like DT2291-OSP-SH04-R2-20260412. That file name tells you everything (project, content, revision, date) without opening it. And when you're managing 37 separate sheet files across a multi-county build, that matters enormously.

Metadata is the most consistently skipped part of [fiber construction package deliverables](https://draftech.com/blog/fiber-construction-package-deliverables-guide). Every CAD and GIS file should carry a metadata header: project name, CRS, units, datum, originating drafter, last revision date. Not in a separate Word doc. In the file itself. This sounds like extra work. It takes about four minutes per file. And it's the difference between a clean handoff and a 3-hour phone call six months into operations when someone's trying to trace a splice location.

For GIS deliverables specifically, we push for GeoPackage (.gpkg) format over shapefile wherever possible. Shapefiles truncate field names at 10 characters, split associated files across multiple components, and don't handle complex geometry types well. GeoPackage is a single file, handles everything better, and is readable by every modern GIS platform. The industry is slow to shift. But we've standardized on it internally and we push clients to accept it. It's a baseline part of our [GIS mapping services](https://draftech.com/services/gis-mapping-services/) delivery standard, not a client-by-client negotiation.

## Version Control for CAD/GIS: It's Not Optional Anymore

Let me be direct: if your version control process is "we email files and add initials to the file name," you're going to have a bad time.

Version control for CAD/GIS is genuinely hard. Git works for code because code is text. DWG and SHP files are binary. You can't diff them meaningfully in a standard version control system. That reality has led a lot of firms to just... not solve the problem. They use shared drives and naming conventions and hope for the best. It mostly works until it doesn't.

What actually works in practice is a structured project directory combined with a check-in/check-out discipline, clear revision labeling, and a "current" folder that always contains only the latest approved version of each file. No exceptions. The archive folder holds everything else: dated, named, intact. When a VDOT reviewer asks for the version of the design you sent for permit review 11 weeks ago, you pull it in under two minutes.

Tools like Autodesk Vault handle this for AutoCAD environments. ESRI's enterprise geodatabase has versioning built in. For smaller firms that aren't running enterprise platforms, a disciplined shared directory structure with a locked "ISSUED" folder and a controlled naming convention gets 80% of the way there.

The critical habit is this: no one updates the "current" folder without incrementing the revision number and updating the internal file metadata. One person owns that process per project. Not two. One. Shared ownership of version control is no ownership.

Good [telecom CAD drafting services](https://draftech.com/blog/telecom-cad-drafting-services-isps-fiber) build version control into the project workflow from day one, not as an afterthought during closeout. If version control is being implemented at construction completion, you've already lost data integrity somewhere.

## What Draftech's Documentation Standards Look Like in Practice

We've been refining our documentation process across active projects in 22 states. Here's what it actually looks like.

Every project opens with a documentation brief: a one-page document that defines the project CRS, the layer naming schema, the file naming convention, the target deliverable formats, and the revision control protocol. That document gets signed off by the lead drafter and the project manager before anyone opens a CAD file. It takes 25 minutes to write. It saves days of cleanup.

Our layer schema is stored as a template file (a CAD template and a GIS template) that every drafter loads at project start. Layers are pre-built with correct names, colors, and linetypes. Nobody invents a new layer without going through the project manager. That sounds controlling. It is. And it's why our permit sets don't come back with layer conflicts.

For [as-built GIS documentation](https://draftech.com/blog/fiber-network-as-built-gis-documentation-standards), we maintain a parallel GIS dataset throughout the project, updated as construction progresses, not assembled at closeout. By the time we're finalizing as-builts, 80% of the data entry is already done. The closeout becomes verification and QC rather than reconstruction from field markups.

Our [GIS fiber network planning](https://draftech.com/blog/gis-fiber-network-planning-cost-reduction) workflow feeds directly into the design CAD environment, so the spatial data used for route planning is the same data that gets refined into the permit design. No re-entry. No transcription errors. That continuity is something we've invested significant time building, and it shows up in both speed and accuracy on permit submissions.

On projects with multiple subs, we run a file handoff checklist at every major milestone: 30%, 60%, 90%, IFC. Every file gets verified for CRS, layer compliance, naming convention, and metadata completeness before it leaves our hands. It's not glamorous work. But it's what separates a clean project from one that generates 14 weeks of RFIs.

We also run a final documentation audit before every permit submission: not a casual review, a structured checklist. Layer compliance. CRS verification. File naming. Metadata completeness. Revision number accuracy. It takes roughly 2.5 hours on a typical 18-sheet permit package. It's also the single step that's prevented the most last-minute scrambles. Permitting agencies, especially DOTs and counties running tight review windows, don't give you a second chance when documentation errors trigger a resubmittal. A 72-hour notice requirement in one Virginia county we work with means a resubmittal error costs you three days minimum. That's three days of contractor schedule float gone. Standards prevent that. Audits catch what standards miss.

If you want to talk through what our documentation process looks like for a specific project type, reach out at [info@draftech.com](mailto:info@draftech.com). We're available to deploy across all 50 U.S. states, and we've seen enough edge cases to know that standards only work when they're built for the actual constraints of a project, not a textbook.

**The single biggest driver of rework on CAD/GIS deliverables isn't bad data. It's documentation drift, the slow accumulation of inconsistencies across a project's life. Enforcing standards at kickoff doesn't eliminate the problem, but it reduces it to something manageable. The firms that ship clean permit packages consistently aren't more talented than the ones that don't. They're just more disciplined about governance. That discipline is learnable, and it's not expensive to implement if you start before the first file gets created.**

## Frequently Asked Questions

### What's the most common CAD/GIS documentation error on OSP fiber projects?

Layer naming inconsistency, without question. It's the most frequent issue we see in files coming from other firms or from internal teams that let standards slip over a long project. The problem compounds: one drafter abbreviates a layer name slightly differently, another follows suit, and by the time the project reaches IFC you've got 9 variations of what should be a single layer type. This creates problems in QC, in permit review, and in downstream GIS integration. The fix isn't complicated. It's a locked layer template loaded at project start and an enforced approval step before any new layer gets added. The hard part is consistency, not complexity.

### How does a CRS mismatch actually cause rework in the field?

The most common scenario: design data and field survey data arrive from different sources, both appear to be in NAD83, but one is NAD83 and the other is WGS84 with no explicit declaration. The offset between those two systems is small, typically under 1 meter, but it's not zero. On an aerial design, that offset might be invisible. On a directional bore under a highway where you're threading between gas and electric utilities with documented clearances, that offset puts your bore path in a different location than your design shows. We've traced field errors, change orders, and utility conflicts back to this exact issue on multiple projects. Explicit CRS documentation and a verified reprojection step for every imported dataset eliminates this. No exceptions.

### What file formats should fiber design CAD/GIS deliverables use?

For CAD, DWG is still the standard, but specify the version. AutoCAD 2018 DWG is widely compatible. AutoCAD 2024 DWG is not universally readable. If you're delivering to a county or DOT office, ask what version they can open before you submit. For GIS vector data, GeoPackage (.gpkg) is significantly better than shapefile for any project beyond basic point data. It handles long field names, complex geometry, and multiple layers in a single file. PDF exports for permit sets should be vector-based, not raster. Resolution issues with raster PDFs cause rejections at some permitting offices. Metadata matters for all formats: CRS, datum, units, and revision date should be embedded in every file before it leaves your hands.

### How should version control work on a fiber project with multiple drafters?

Define one person as the version control owner per project, not shared, not a team responsibility. That person owns the "ISSUED" and "CURRENT" directories and is the only one who promotes files into them. All drafters work in a "WORKING" directory structure, check work in and out explicitly, and use the agreed naming convention with revision numbers incremented on every change. At each project milestone (30%, 60%, 90%, IFC), the current approved set gets archived to a dated folder. That archive is never modified. If you're in an AutoCAD environment with an Autodesk Vault license, use it. If you're working in a GIS-heavy environment, ESRI's geodatabase versioning handles this well. For smaller projects without enterprise tooling, a disciplined shared drive structure with clear written protocols achieves the same outcome, but only if everyone actually follows the protocol.

### What should a complete CAD/GIS documentation brief include at project kickoff?

At minimum: project CRS and datum, layer naming schema with examples, file naming convention, target deliverable formats and version specifications, revision control protocol and folder structure, and identification of who owns version control. Some projects also need a coordinate system transformation protocol if you're expecting data from multiple sources in different projections. The brief should be a single page, not a 40-page standards manual that nobody reads. It gets signed off by the lead drafter and project manager before any production work starts. On longer projects, a brief check-in at the 30% milestone to confirm standards compliance has been maintained is worth 30 minutes of someone's time. This is the unglamorous side of CAD/GIS services , but it's where project quality is actually determined. The firms that do this consistently deliver cleaner packages with fewer review cycles and less rework exposure.