Aerial Fiber Permit Submission Checklist: A 2026 Package Release Guide

An aerial fiber package can be detailed and still fail a completeness screen. The route plan may use one pole sequence while the application uses another. A traffic sheet can cover a work area that the route map never identifies. Missing owner authorization can leave a finished set without a valid applicant. The useful question is whether every authority can connect the request to a defined route and the evidence it expects.

This guide treats submission as a controlled release rather than a file upload. We show how to map authority boundaries; freeze route evidence; build a pole schedule; coordinate attachment and right-of-way records; assemble plans; and prove what was transmitted. For the engineering that feeds the application, our utility pole attachment engineering guide covers fielding through construction release. Here we stay focused on the applicant's package and its preflight check.

What the Aerial Fiber Permit Submission Checklist Controls

An aerial fiber permit submission checklist is a 1-package release control that proves the applicant; authority; route limits; pole records; design revision; support documents; and transmittal agree. It checks completeness against written owner and agency instructions. It neither grants access nor replaces engineering review. No checklist predicts when an authority will decide.

We start with a defined submission object; a route-wide design can produce several applications because a pole owner controls attachment access while a road agency controls occupancy or work inside its right-of-way. A railroad; municipality; county; state DOT; or private property owner can add another record. We do not merge those decisions into one permit. We link each package to the same route index and identify the limits that each authority governs.

The Federal Highway Administration Utilities Program explains that states decide whether utilities may occupy highway right-of-way and under what conditions, then document those choices in utility accommodation policies. Its 2017 memorandum Utility Accommodation and Other Uses of Highway Right-of-Way also discusses how above-ground facilities affect highway safety and maintenance. We use those sources to justify authority-specific screening. We do not turn one state policy into a national aerial placement rule.

Package control begins with written requirements; we capture the current application form; owner guide; utility accommodation policy; drawing standard; portal instructions; and required certifications for the named authority. We record the edition or access date in the checklist. If instructions conflict, we ask the authority which record controls and retain the answer. An internal template can organize the work, but it cannot silently override the receiving organization's published process.

We distinguish a pole attachment application from an encroachment or occupancy permit; the first asks a pole owner for attachment access under the applicable agreement and rules. The second addresses work or utility occupancy within controlled property. A project can need both. The checklist carries separate package IDs and recipients, plus a route cross-reference. Approval from one authority never stands in for approval from another.

Freeze the Route, Authority Matrix and Package Basis

Before we fill forms, we freeze the submission basis. The route register lists the beginning and ending limits; pole-owner changes; road jurisdictions; crossings; planned access points; and design revision. Each application row names the governed segment and the planned activity. That structure exposes gaps between adjacent packages. It also prevents a later alignment change from passing unnoticed into one drawing set while another form retains the old limits.

We then compare the route register with survey evidence. The strand mapping and aerial plant assessment guide explains the field collection context. For submission QA, we confirm that pole identifiers match photographs and mapping; span direction is traceable; visible attachment conditions are recorded; road names agree; and exceptions are assigned. We label proposed information as proposed. We do not present unverified field assumptions as existing conditions.

This table is a Draftech release model, not an agency checklist. The receiving authority decides what applies. We compare its instructions with the package and document why an item is present; not applicable; pending; or on hold. A blank is not a decision. When a requirement does not apply, the reviewer records the basis.

• Package identity: assign one stable ID that appears in the cover sheet; file index; transmittal; and internal tracker.
• Revision basis: name the drawing issue and the date that every schedule or form was checked against.
• Authority boundary: identify the pole owner and property controller without assuming they share one review.
• Open exception: name one owner for each unresolved field fact or application requirement.

A route change triggers a focused recheck. We compare changed poles and spans against every open package. We also check whether access; traffic handling; property limits; or environmental screening changed. The permitting lead decides what requires clarification or resubmission under the authority's process. We never assume that a design revision is immaterial merely because cable count stayed the same.

Build the Pole Schedule and Attachment Record

The pole schedule bridges field evidence and the application. We give every row a stable route key plus the owner pole number when available. We include coordinates in the required reference system; structure type; proposed attachment; span relationship; make-ready disposition; and linked photo identifiers. The authority's form controls submitted fields. Our wider schedule remains the reconciliation source when the portal accepts only a subset.

Pole identifiers need a conflict rule. If a field label differs from the owner's record, we preserve both and flag the mismatch. We do not invent a corrected number. The plan symbol; schedule row; photograph; analysis file; and application line must point to the same physical structure. Where one source lacks an identifier, we use the route key to maintain continuity and ask the owner how the application should represent that pole.

Current 47 CFR 1.1411 defines a complete pole attachment application by reference to the information the utility needs under its procedures to begin surveying affected poles. Those procedures can be specified in an agreement or in written requirements available at submission. That definition supports our owner-specific check. It does not create one universal field list for every utility; nor does it replace state regulation where the federal pole attachment framework does not govern.

Engineering records must match the requested attachment. We reconcile cable and strand descriptions; proposed attachment location; risers; slack or equipment where shown; guying or anchoring where applicable; crossing information; and pole analysis references required by the owner. We do not copy results between poles. If analysis depends on missing owner data or an unresolved field condition, the affected row stays on hold and the package release record states why.

• Field match: verify the pole key and photograph before accepting any schedule row.
• Plan match: compare each pole callout with its schedule values and proposed span direction.
• Application match: confirm that portal entries or forms reproduce the released schedule without retyping drift.
• Analysis match: link only the calculation or make-ready record that belongs to that structure.

Make-ready stays separate from permit completeness. A package can accurately disclose that make-ready is pending if the owner's process allows that state. Another owner may require completed engineering before accepting an application. We follow the written sequence for that owner. We also keep proposed work distinct from work directed by the owner after review. The application asks for access; it does not pre-authorize the applicant to choose another attacher's work.

Assemble Drawings, Traffic Control and Support Files

The plan set must let a reviewer locate the request without reconstructing the design database. We include the location basis required by the authority; route limits; north arrow and scale where required; property or right-of-way context; pole sequence; proposed attachments; crossings; access points; work areas; and detail references. Sheet titles and revision identifiers must agree with the index. The package should make existing and proposed features visibly distinct without relying on color alone.

Caltrans provides a useful scoped example. Its Utility Encroachments Permit Application Guide, Including Broadband identifies application forms; location maps; plan content; traffic control; authorization; and supporting records that can apply to a utility submittal. Its utility checklist calls for complete plans and lists supporting documentation as applicable. We use that example to show why a package needs a document index. We do not represent California's requirements as rules for another state or a local pole owner.

Traffic control belongs to the work activity and site. The Federal Highway Administration's current Manual on Uniform Traffic Control Devices for Streets and Highways is the national traffic control device reference, while states can maintain their adopted standard and agency procedures. Our work zone traffic control plan guide covers the field-facing design. In this preflight, we verify that the traffic sheet describes the same access points; lane or shoulder effects; pedestrian conditions; work method; and route revision shown elsewhere.

Supporting records are conditional, not decorative. The authority may call for applicant authorization; owner consent; proof of insurance; bonds; environmental documentation; stormwater controls; structural calculations; accessibility records; or another permit. We check only the requirements that apply to this package and preserve the source instruction. We do not insert generic limits or certifications. A missing applicable record creates a hold. A nonapplicable record receives a written disposition.

File preparation is technical control. We confirm readable scale; correct orientation; permitted file types; naming rules; and portal size constraints published by the recipient. We open every final file from the release folder. We also remove superseded drafts so an upload cannot select the wrong revision.

Run the Submission Preflight and Preserve Evidence

The preflight reviewer starts from the recipient's checklist and the package manifest. We compare each listed file with its released source. We test authorization; revision dates; sheet counts; form fields; pole counts; and route limits. We then perform a reverse check: each plan callout must lead to a schedule or detail, while each application row must lead back to the plan.

We use a second-person check for the final release. The preparer can resolve routine comments, but the release reviewer independently confirms the authority; applicant; governed limits; revision; applicable attachments; and unresolved holds. If the same person must perform both roles, we separate the checks in time and preserve both attestations. This is a project control. It is not an agency certification or a promise that the package will be accepted.

The transmittal names the package ID and every file with its revision. We record the recipient; delivery channel; submission timestamp; and applicant contact. After upload, we preserve the portal receipt or delivery evidence and compare the displayed file list with the manifest. If a portal renames a file or rejects one attachment, we record the event. We do not mark the package submitted until the evidence supports what the recipient actually received.

Comments return to the same control chain. We retain the original message; assign each issue; identify affected drawings or forms; and build a response record. A revised package receives a new manifest and transmittal while the prior package remains retrievable. Our permitting and utility coordination services connect package preparation with comment control, but agencies and owners remain the decision makers. We coordinate evidence and responses without representing that Draftech grants access or issues a permit.

Management reporting should separate completeness from outcome. We can report that the internal checklist passed; that a receipt exists; that comments are open; or that an issued document is on file. We cannot convert those facts into a predicted decision date. Our engineering delivery approach favors traceable handoffs because permit coordination depends on design context. The tracker should always preserve the authority's own status wording beside the internal package state.

Before any downstream release, we read the issued record against the current route. We check limits; conditions; approved drawings; notice or inspection instructions stated by the authority; and dependencies under other permissions. The submission checklist closes at receipt, but its manifest becomes the baseline for that later comparison. A permit document governs only the scope it actually addresses. Unrelated segments stay on hold.

Choose the Aerial Fiber Permit Submission Checklist Release Gate We Recommend by Reader

The right release gate depends on your role, yet every reader needs the same evidence chain: written requirements; defined route limits; reconciled pole records; a controlled plan revision; applicable support files; and a reproducible transmittal. We recommend a short gate that points to detailed records rather than a giant form that repeats them. The gate should stop an upload when authority scope or package identity remains unresolved.

For an ISP program manager: choose a route-to-authority matrix that shows every required package and its governed limits. Require one package owner and one release reviewer. Review exceptions by route segment instead of treating the entire program as one permit color. We recommend keeping internal target dates separate from agency events so planning pressure cannot rewrite the external record.

For an OSP engineer: choose a pole-centered reconciliation report that compares the map; photographs; schedule; analysis references; plan callouts; and application entries. Hold the exact pole or span that fails. We recommend preserving both owner IDs and route keys because either source can contain a mismatch that needs resolution before submission.

For a permit coordinator: choose a manifest-led package that begins with the recipient's current instructions and ends with receipt evidence. Record every not-applicable decision and every exception owner. We recommend reopening the released files from the upload folder before transmission, then comparing the portal's final list against the manifest after transmission.

No checklist can make one package valid for every owner or jurisdiction. Its value is disciplined comparison. If your route register; pole schedule; application forms; and plan set no longer agree, email info@draftech.com. We can review the control chain and identify which package needs evidence or reconciliation before the submission release.

We recommend releasing only when a second reviewer can answer 3 questions from the record: who controls this request; what exact route and poles it covers; and what files the recipient will receive. If any answer depends on memory, stop the upload. We would rather document one honest hold than create a clean receipt for a package whose internal records disagree.