A drawing set can be visually complete and still leave construction teams guessing. Route lines do not explain the survey basis, network logic, splice assignments, calculations, permit conditions, quantity revision, unresolved access or the evidence expected at handoff. Those omissions are where field redesign and review disputes begin.
We define an OSP design package as a coordinated decision record, not a stack of PDFs. This guide separates its record families, shows how they connect, and gives flat release decisions for planning, permit and construction, plus closeout use. The controlling owner and authority requirements still decide the final file list.
What Is Included in an OSP Design Package: The Control Test
What is included in an OSP design package depends on its issue purpose, but our 7-family framework covers design basis, field evidence, route sheets, network logic, quantities and calculations and approvals, plus release records. Together, they let a reviewer trace each proposed asset from source condition through engineering decision, authorization and construction instruction, plus final handoff.
The 7 families are Draftech's delivery framework, not a claim that every owner uses the same index. Contract requirements, owner standards, utility rules, authorities and facility conditions, plus the named design stage control the package. The Telecommunications Industry Association standards program is one named source for telecommunications standards work, while the project basis must identify the specific applicable references and revisions.
Start with an issue statement. Name the purpose. We write whether the package supports concept approval, field survey, permit review, utility coordination, procurement, construction release, change direction, closeout or operations. One package may support several purposes, but each purpose needs an acceptance role and known limits. A permit issue is not automatically a construction issue, and a construction issue is not automatically an accepted as-built. Keep the states distinct.
The basis of design names route and service limits, source records, network objectives, owner standards, architecture, aerial and underground assumptions, coordinate reference, units, drawing and data formats, exclusions and dependencies, plus approval authority. We keep accepted assumptions distinct from field-verified conditions. A sentence marked typical should never acquire the status of a measured asset because it was copied onto several sheets.
Our fiber network design workflow keeps this basis connected to the route model, serving logic, quantities, details, permit exhibits and comments, plus issue history. That connection is the practical definition of a package. Without it, every file can be individually correct while the delivered set still contains several versions of the route.
Survey, Route, and Network Records
Existing-condition records should show what was observed, measured, owner-supplied, derived, assumed or left unresolved. Scope-specific records can include route control, structures, poles, spans, attachments, conduit, handholes, utilities, surface features, access, right-of-way, parcels, crossings and photographs, plus source confidence. We tie evidence to stable asset or segment identifiers instead of leaving field files in a detached folder.
Route sheets translate that evidence into proposed work at the scale required for review. Plans, profiles or crossing sections where needed, details, match lines, dimensions, offsets, stationing, symbols, notes and restoration, plus material callouts should agree. We do not add detail simply to make sheets dense. Every callout should resolve a field decision or support a named approval. Earn the ink.
| Record family | Core content | Acceptance test | Primary user |
|---|---|---|---|
| Design basis | Scope, sources, criteria, status | Issue purpose is explicit | Owner and reviewers |
| Field evidence | Conditions, measurements, photos | Source and confidence are traceable | Engineering and field teams |
| Route sheets | Plans, profiles, details, notes | Geometry and callouts agree | Authorities and crews |
| Network logic | Cables, devices, splices, capacity | Connectivity traces end to end | Design and operations |
| Support records | Quantities, calculations, permits | Inputs map to current revision | Procurement and reviewers |
| Release records | QA comments, decisions, transmittal | Open items have dispositions | All receiving roles |
| Handoff records | Redlines, tests, as-builts, index | Installed state reconciles | Closeout and operations |
The table shows why a package is more than plan sheets. Each row answers a different question, and the rows depend on one another. A changed route can alter survey gaps, network length, cable assignment, quantities, pole analysis, permit coverage and detail references, plus closeout identifiers. We require change review across every affected family instead of correcting only the visible linework.
Network logic connects the physical route to the intended fiber system. The package should identify cable segments, sizes, endpoints, cabinets, hubs, closures, terminals, splitters where applicable, fiber allocation, splice relationships, slack and storage, labeling, testing and reserve basis, plus status. Our HLD and LLD scope guide explains the concept decisions that must remain stable before detailed sheets inherit them.
A PON power budget planning check can expose an early optical assumption. Connectivity review then follows representative service or capacity paths through HLD and LLD outputs. We compare serving areas, route segments, cable schedules, splice records and device relationships, plus quantities. A buildable trench alignment can still be an unusable network if the fiber model cannot serve the intended locations or if two files assign the same fiber differently.
The actual recipient files also need inspection. GIS and CAD exports can change field names, geometry, coordinate behavior, fonts, references or relationships. PDF conversion can hide broken links or unreadable detail. Test the export. We compare the issued files against source records, then confirm the receiving role can open and interpret, plus use them under the stated issue purpose.
Quantities, Calculations, Permits, and Approvals
Quantities need a named basis and revision. We connect takeoffs to route objects, construction type, material rules and details, plus exclusions. Known geometry, calculated quantity, allowance, owner-furnished material, and unresolved scope should not collapse into one total. When design changes, the review identifies every affected quantity rather than assuming a later export corrected all downstream workbooks.
Calculations should identify the asset, input source, method, units, criteria, result, reviewer and revision, plus dependent drawing or schedule. Pole loading, clearances, conduit fill, optical budgets, hydraulic considerations, or other project-specific calculations belong only where applicable. We do not add a calculation type because it appears on a generic checklist, and we do not omit its linkage when it supports a released decision.
Permit and utility records map to route limits. Each application, exhibit, owner comment, response, approval, condition, and closeout requirement should identify the submitted design issue and covered assets. A permit status on a spreadsheet is insufficient when no one can tell which revision the authority reviewed. The package should also state work that remains outside the approval or subject to a hold.
Utility coordination decisions belong in the same issue history. We record ownership questions, make-ready references, crossing requirements, access decisions, design comments and accepted responses, plus responsible parties. Our fiber construction package deliverables guide shows how those design decisions must arrive in a format the receiving construction team can execute without rebuilding the review trail.
Procurement support should preserve approved manufacturer-neutral requirements where the owner uses them, material descriptions, quantities, alternates and long-lead decisions, plus substitution review. A substitution that changes dimensions, capacity, loading, bend behavior, installation detail or test expectation returns to engineering. Purchasing should not become an untracked path for changing the design basis. Return it to engineering.
We maintain an exception register beside approvals. An exception names the affected route or asset, source evidence, technical or schedule consequence, responsible role and required decision, plus closure record. That structure lets unaffected areas move when permitted while preventing an open crossing, access point, structure, or calculation from being buried inside a general note.
Source-to-output reconciliation closes this group. We select approved route objects and compare their geometry, identifiers, construction type, materials, quantities, calculations and permit coverage, plus issue status across the actual delivery set. We also select supporting records and trace backward to the assets they govern. This two-direction test finds orphan calculations, stale takeoffs, and approval files that no longer match the proposed work.
QA/QC, Issue Control, and Construction Handoff
QA/QC needs a completeness pass and an engineering-logic pass. Completeness checks sheets, references, identifiers, coordinates, units, calculations, schedules, required fields and comments, plus transmittal contents. Logic review asks whether the proposed route, network, materials, details, quantities and approvals, plus open conditions can coexist in the field. A complete form cannot rescue a package built on contradictory source assumptions.
Independent trace testing is our strongest release check. A reviewer outside the production chain selects a representative route segment and follows its survey evidence, plan geometry, details, cable and splice records, quantity, calculation, permit status and comments, plus handoff requirement. The reviewer also starts from a quantity or permit condition and traces backward to the assets it controls. Broken links return to correction. Fix the chain.
Release trace: Test 1 ordinary segment and 1 high-consequence exception from source evidence through the exact files being issued. A perfect title block does not prove a connected package.
Comment control distinguishes an answered comment from an accepted change. We retain reviewer, date, source issue, response, affected outputs and approval, plus implementation evidence. Closed means the accepted response reached every dependent drawing, schedule, calculation and quantity, plus permit record. A response marked done while the old value remains in a splice schedule is still open work.
Construction release includes limits and escalation paths. Draftech engineering is performed in-house. When construction is included, we provide full turnkey delivery through Draftech-managed subcontract crews under our QA/QC and safety oversight. Crews work from the current issue, document redlines and RFIs, and route changes to our engineers when field conditions affect engineering intent, permits, quantities, acceptance or owner requirements.
The handoff should define hold points, required submittals, evidence naming, redline method, inspection or test records, nonconformance handling, material substitution review and change authority, plus the expected closeout index. We want field records to return with the same identifiers used in design. Otherwise as-built teams have to infer which photograph, test or redline belongs to which installed asset.
Our low-level design services focus on this construction interface: structure-level geometry, details, splice information and quantities, plus issue controls tied to the accepted basis. The objective is not to remove every uncertainty. It is to expose each material uncertainty, assign its resolution path, and stop unapproved assumptions from passing silently into field execution.
The transmittal is part of QA/QC, not an administrative cover. It should name purpose, released limits, source issue, included native and review files, coordinate and unit information where relevant, known exclusions, open conditions and acceptance role, plus superseded package. We compare those statements against the contents. A complete file list has little value when it labels conflicting revisions as one current package.
What Is Included in an OSP Design Package at Release
Our limitation is worth stating: a connected package cannot replace missing field evidence or an authority decision. We mark those gaps and assign validation work rather than decorating them with extra detail. More sheets are not more certainty.
Planning issue: Release when sources, scope, candidate routes, network concept, assumptions and exclusions, plus validation tasks are explicit. Do not present desktop geometry as field-verified or planning quantities as build quantities. A planning package can be valid for the named decision while remaining prohibited for permits, procurement or construction.
Permit issue: Release when authority limits, current route, profiles or details where required, crossings, ownership, supporting calculations and application fields, plus responsible applicant agree. State which construction decisions remain outside the permit review. Hold an affected segment when the route or supporting evidence could change the authority, application or requested approval.
Construction issue: Release when all 7 record families reconcile for the work area and every condition has an owner and escalation path. Route, network logic, details, quantities, calculations, approvals, and issue records must point to one instruction set. Our LLD quality control checklist identifies the structure-level conflicts that should be caught before a crew inherits them.
Closeout issue: Release when accepted field changes, installed geometry, cable and splice records, quantities, permits, tests, photographs, nonconformances, and asset status reconcile to the controlling closeout requirements. Keep known exceptions visible. An operating network does not prove that every permit, record, test or owner acceptance obligation is complete.
Before final issue, the receiving role should perform a retrieval test. Locate a route segment, identify its accepted design and permit status, find the supporting quantity and calculation, review any condition, and identify the handoff evidence expected from construction. If the answer depends on the preparer's memory or a private message, the package needs correction before it becomes the field baseline.
The pain this framework removes is a fragmented handoff: route sheets without source evidence, quantities on a stale alignment, permits tied to an unknown revision, and field records that cannot join the asset model. Our fiber network design team carries the basis, route, network, support records, and release controls through one in-house engineering workflow.
If your package looks complete but reviewers cannot trace the route, network logic, permit basis, quantity, or open condition, email our OSP engineering team. We can define the missing record family, identify affected outputs, and build a release test that fits the actual owner and authority, plus construction purpose.
