# Pole Attachment Structural Analysis: From Field Record to Defensible Decision

**Title tag:** Pole Attachment Structural Analysis Guide 2026  
**Meta description:** Pole attachment structural analysis guide covering field inputs, load cases, pole models, make-ready decisions, utility review, exceptions and QA.  
**Author:** Julio Martinez Sr.  
**Published:** August 17, 2026  
**Last updated:** August 17, 2026  
**Category:** Pole Loading & Make-Ready  
**URL:** https://draftech.com/blog/pole-attachment-structural-analysis  
**Primary keyword:** pole attachment structural analysis  
**Word count:** 2614  
**Read time:** 10 minutes

---

A proposed fiber cable can look modest on a plan sheet and still change the governing load case at a corner, dead end, long span or equipment pole. The difficult part is not drawing one more line in a model. It is proving that the model represents the actual structure, the receiving utility's criteria and the proposed construction without quietly converting unknowns into facts.

This guide follows the evidence from field collection through loading, capacity review and make-ready disposition. It does not replace a utility standard, a sealed engineering judgment or a pole owner's approval. It shows what a reviewable package should contain and where a responsible analyst should stop when the source record cannot support a conclusion.

## Pole Attachment Structural Analysis: The Core Decision

Pole attachment structural analysis evaluates an existing utility pole with proposed and existing facilities under the controlling design criteria. A defensible review uses at least 2 states, existing and proposed and reaches a traceable disposition: attach as designed, perform make-ready, replace the pole or hold for better evidence.

The decision starts with jurisdiction and owner criteria. The current 47 CFR 1.1403 permits a utility subject to the federal framework to deny access for insufficient capacity, safety, reliability or generally applicable engineering purposes, but the denial must be specific and supported. That rule is not a structural formula. It explains why the engineering record must show the evidence behind a capacity or safety conclusion rather than return a bare pass or fail label.

We therefore treat the pole model as a controlled argument. Pole identity connects the field record to the owner asset. Geometry establishes where loads act. Material and class attributes define the structure represented in the software, while environmental and construction criteria define the load cases. The proposed cable, messenger, equipment, riser, guys and anchors must enter that same evidence chain. If one material input is assumed, the output must say so.

A percentage on its own is not the decision. Utilization can help summarize a model, but reviewers also need the controlling component, load direction, support configuration and source of every consequential input. A pole can change from acceptable to unacceptable because an anchor is missing from the record, a span terminates instead of continuing or a proposed attachment was modeled at the wrong elevation. Read the structure, not only the result cell.

> **Analysis control:** Freeze an existing-condition model before adding proposed work. That baseline makes every later change attributable and reviewable.

## Evidence, Model and Decision Map

We organize the package by evidence state rather than by software screen. Each group below has a source record, a model translation and a release question. The sequence matters because a precise calculation cannot rescue the wrong pole ID. Nor can a complete photo set decide which owner standard applies. The table is a review map, not a substitute for the utility's current checklist.

| Evidence group | Model use | QA question | Possible disposition |
| --- | --- | --- | --- |
| Pole identity and condition | Structure record and material basis | Does the asset match the owner record? | Release or field hold |
| Attachment geometry | Load elevations and offsets | Can each modeled facility be located? | Accept or recollect |
| Span relationships | Tension direction and span loading | Do both ends describe the same span? | Accept or corridor exception |
| Guys and anchors | Support reactions and load transfer | Is support geometry evidenced? | Retain, modify or hold |
| Design criteria | Environmental and construction cases | Is the correct owner basis documented? | Analyze or standards hold |
| Proposed work | Incremental loads and configuration | Does the model match the issued design? | Attach, make-ready or redesign |

The first release gate is identity. Tags, coordinates, route sequence, pole material and visible condition should describe one structure. Replacement poles and duplicate tags deserve explicit handling because the mapped point may refer to a removed asset while field photographs show its successor. We preserve both identifiers and the relationship between them. Renaming a record to make the systems agree destroys the very discrepancy the analyst needs to resolve.

The second gate is geometry. Attachment heights need a stated datum, units and object identity. Span records need neighboring pole IDs and direction, with line angle and length derived by an accepted method. Equipment and risers remain separate objects. The analyst should be able to move from any modeled load to a photograph or approved owner record without guessing which cable, bracket or anchor the field note meant.

The third gate is the design basis. The 2023 National Electrical Safety Code is the current IEEE published edition at the time of this draft, but a project may also be governed by a utility construction standard, adopted edition, loading district, local rule or agreement requirement. The IEEE C2-2023 standard page describes the NESC as covering practical safeguarding for utility supply and communications systems. Our [NESC pole loading compliance guide](/blog/nesc-pole-loading-compliance-fiber-attachments) explains how that basis reaches attachment models. We record the actual basis selected by the receiving utility. Write it down.

Public utility manuals show why generic defaults are dangerous. CenterPoint Energy's 2025 Pole Attachment Guidelines contain separate sections for application, make-ready, post-installation inspection and attachment design requirements. That arrangement is specific to CenterPoint's system, not a national template. We use the public CenterPoint guidelines as an example of owner-specific criteria that must be checked before model setup, never as a rule for another utility.

### Facts, Assumptions and Blocked Inputs

We assign every consequential input one of those states. A fact points to accepted evidence. An assumption states its basis, approver and affected output. A blocked input identifies what evidence would close it. This is stricter than coloring uncertain cells because color disappears in exports and means different things to different reviewers. The status must survive into the native model, calculation report and exception register.

Some uncertainty can be bounded through sensitivity cases, but that is not permission to invent an input. If the utility authorizes a conservative case, we keep it outside the accepted baseline and label the decision it tests. If pole condition, anchor geometry or asset identity remains unresolved, we hold the affected structure. Hold the pole. A model that produces a number is not automatically a model that supports construction.

## Build and Check the Structural Model

Model construction begins with the existing pole. We enter the accepted structure properties and verify orientation before adding facilities. Existing conductors, communications cables, equipment, guys and anchors are modeled as separate objects when the platform and utility method require them. Span direction is checked at corridor level because a locally plausible bearing can still point to the wrong adjacent pole. This baseline should reproduce the field arrangement before proposed loads appear.

The proposed state must match the issued design revision. Cable and messenger properties come from approved product data or the project basis, not from a familiar catalog item chosen because its name looks close. Attachment elevation, offset, span association, dead-end condition and equipment mounting belong to the design record. We preserve the source revision beside the model so a later route change cannot be mistaken for an analyst correction.

Load cases follow the receiving utility's criteria. We do not mix weather assumptions from one owner with construction grades or strength treatment from another. The analyst records the code edition, utility supplement, software version, catalog version and any approved overrides. Those details are mundane until a resubmission produces a different result. Then they are the only practical way to explain whether the pole changed, the design changed or the calculation environment changed.

### Independent Model Review

Our QA separates source review from result review. The source reviewer traces high-consequence inputs to evidence and checks the corridor relationship. The result reviewer examines controlling cases, reactions and make-ready logic without relying on the preparer's private notes. We also compare the existing and proposed states object by object. An unexplained change in an existing facility is a defect even when the proposed model passes.

Software checks are useful but limited. Required fields, duplicate pole IDs, missing units, catalog mismatches and broken span relationships can be flagged automatically. A script cannot establish that a photograph shows the claimed anchor or that a field note belongs to the replacement pole rather than the retired one. Qualified review stays in the workflow. No shortcuts. Automation should expose where judgment is needed, not pretend judgment has disappeared.

For a deeper explanation of how pole loading differs from a visual clearance review, our [pole loading analysis guide](/blog/what-is-a-pole-loading-analysis) covers the governing forces and typical dispositions. When the receiving utility uses O-Calc Pro, the [O-Calc Pro pole analysis workflow](/blog/pole-loading-analysis-o-calc-pro) explains catalog control and model handoff. These are companion references. The utility's accepted method still governs the actual submission.

> **QA checkpoint:** Ask a reviewer to reconstruct one controlling load from the field record and design source without speaking to the modeler. If the trail breaks, the package is not ready.

## Turn Structural Results Into Make-Ready

A structural result becomes useful only when it produces a constructible disposition. An acceptable proposed state should identify the accepted attachment configuration and any conditions that remain outside scope. A make-ready disposition should name the facility or support change, responsible owner, sequence dependency and drawing reference. A replacement recommendation should explain the controlling issue and the proposed replacement basis supplied or approved by the pole owner.

We keep structural make-ready separate from clearance work even when one pole needs both. Moving an attachment may improve separation yet change loading. Adding a guy may resolve one force direction while introducing constructability or property constraints that require owner review. Pole replacement affects transfers, risers, equipment and adjacent design sheets. A single note reading replace pole hides too much coordination to be safe or schedulable.

The disposition register connects each pole to the model revision and owner comment. It records whether the structure can attach as designed, needs communications work, needs electric-space work, requires replacement or remains blocked. We do not collapse unresolved poles into a route-level approval percentage. Construction needs a pole-specific status and project controls need to distinguish engineering complete from owner accepted. Those are different events.

Change control continues after review. A shifted route, revised cable, altered slack location, changed equipment pole or owner-directed attachment height can invalidate the proposed state. We screen every design revision against model inputs and reopen only the affected structures. That is faster than rebuilding blindly and safer than assuming a change is immaterial because the line moved only a small distance on the plan.

### The Submission Package

A reviewable package contains the application reference, pole list, field evidence index, criteria memo, native models, calculation reports, proposed drawings, exception register and QA record. Owner portals may prescribe different file names or schemas. We follow those requirements exactly while retaining an internal crosswalk, since a successful upload does not prove that a calculation report still maps to the correct pole and design revision.

The criteria memo is intentionally short. It identifies the owner standard and code edition, structure basis, environmental cases, material sources, software environment, accepted assumptions and exclusions. It does not restate every calculation. Its job is to let a reviewer see which rules were applied and where an exception changes the normal method. The model and evidence remain the source for the technical details.

## Pole Attachment Structural Analysis Release Decision

Our candid limitation is simple: a structural model cannot determine hidden decay, prove an obstructed anchor or decide an owner criterion that has not been supplied. Field observation also does not replace any inspection or test required by the pole owner. The [pole loading calculator](/tools/pole-loading-calculator) can support an early planning check, but it cannot replace a structure-specific model. When a consequential fact is unavailable, we document the gap and hold the affected conclusion. That restraint protects the owner review because every released conclusion still points to evidence that another qualified person can examine without relying on the modeler's memory. A neat report is not evidence.

### Release by Stakeholder

**For a pole owner or utility reviewer:** require the model basis, evidence links and pole-specific disposition before accepting a route package. Return unsupported inputs directly and identify the required closure evidence. Do not ask the final utilization value to carry the entire engineering record or conceal an unresolved standards decision.

**For an ISP or program manager:** connect fielding, design revision control and owner criteria before analysis starts. Fund targeted recollection where it closes a controlling gap, then plan from contiguous accepted structures. Do not push blocked poles into construction simply to preserve a route-level milestone or a dashboard percentage.

Draftech's in-house [pole attachment structural analysis workflow](/services/pole-loading-analysis) carries pole evidence, native models, QA and make-ready dispositions as one controlled workstream. That removes the handoff gaps described above without implying that our model replaces utility approval. Construction, when included, is delivered full turnkey through managed subcontract crews under Draftech QA/QC and safety oversight.

If you need a route screened before application or a returned model package rebuilt around the receiving utility's comments, [email our pole engineering team](mailto:info@draftech.com). We will identify which structures are ready, which need better evidence and which criteria questions belong with the pole owner before another calculation is issued for review.

> **[Talk to our pole loading team about your route.](/#dt-contact)** We can align field evidence, structural models and make-ready dispositions before a preventable exception reaches utility review.


## Frequently Asked Questions

### What does pole attachment structural analysis determine?

Pole attachment structural analysis compares an evidenced existing pole with the proposed attachment under the receiving utility's criteria. At minimum, the record should preserve 2 states: existing and proposed. The result supports a pole-specific disposition such as attach as designed, perform make-ready, replace the structure or hold the decision until a consequential field or standards input is resolved.

### Does an acceptable utilization value guarantee attachment approval?

No. One utilization value cannot prove pole identity, clearances, condition, guying, constructability or compliance with the pole owner's application rules. 47 CFR 1.1403 also recognizes safety, reliability, capacity and generally applicable engineering purposes as distinct access considerations under the federal framework. The utility still reviews the full submission and may require corrections or separate make-ready before granting attachment approval.

### Which NESC edition should a pole model use?

IEEE C2-2023 is the current published NESC edition as of this draft, but that does not mean every utility has adopted it for every project. The analyst must record the edition and any utility supplement actually required by the pole owner. One criteria memo should also identify the loading basis, construction grade, strength treatment and approved exceptions used in the submitted models.

### What field data is most important for pole loading?

The model needs a connected structure record, not a loose collection of heights. We treat 6 groups as consequential: pole identity, condition basis, attachment geometry, span relationships, guys or anchors and mounted equipment. Each material value should retain its unit, method and evidence reference. If an anchor or neighboring span cannot be verified, the affected structural conclusion should remain visibly blocked.

### When should a pole be held instead of modeled with assumptions?

Hold the pole when an unknown can change the structure represented, the governing criteria or a controlling load path. Common examples include uncertain pole identity, unsupported class or material, an obstructed anchor and a span tied to the wrong neighbor. A sensitivity case may test 1 approved conservative assumption, but it should not be presented as the accepted baseline without the required authority.

### What belongs in a structural analysis submission package?

A complete package usually connects at least 8 artifacts: application reference, pole list, field evidence index, criteria memo, native model, calculation report, proposed drawing and QA or exception record. The receiving utility may require a different portal schema or additional forms. Every output should still map to the same pole ID, design revision, criteria basis and pole-specific make-ready disposition.

---

**About Julio Martinez Sr.:** 30 years of OSP engineering experience, with deep expertise in pole loading, make-ready, permitting, and field delivery. [info@draftech.com](mailto:info@draftech.com)