High-level design fails when a polished route map is mistaken for an approved network concept. HLD must reconcile service locations, architecture, capacity, route feasibility, third-party controls, conceptual quantities, and unresolved risk before detailed design inherits the work. The value is not prettier linework. It is a decision basis that another reviewer can reproduce.
We use the checklist as a release gate for our high-level design services, not as a box-ticking exercise. Every accepted item needs a source, status and owner, plus disposition. Every open item needs a planned validation stage. This guide shows what we require before the concept moves into survey or low-level design.
OSP Network High Level Design Checklist: Approval Test
An OSP network high level design checklist is the evidence-based test used to decide whether a fiber concept is stable enough for detailed design. Our 7 review gates cover scope, demand, topology, route feasibility, capacity, dependencies, and handoff so an HLD approval records both the selected concept and its unresolved conditions.
The first control is a written design basis. Write it down. We name the service-area boundary, source location file, customer or service classes, technical objectives, owner standards, required output formats and approval authority, plus source dates. A changed demand file cannot quietly replace the approved basis. Control the source. We retain the revision and record how its change affects serving areas, route geometry, capacity and quantities, plus risk.
HLD is not LLD with detail removed. Keep the boundary. HLD chooses and tests the network concept; LLD turns that accepted concept into structure-level routes, installation details, splice information and permit drawings, plus build quantities. Our explanation of the difference between HLD and LLD helps set that boundary with stakeholders before an approval meeting becomes a scope dispute.
We also identify standards by applicability rather than dropping acronyms onto a cover sheet. The Telecommunications Industry Association standards program is a named source for telecommunications standards work, but the owner, contract, facility type, authority, and adopted requirements determine what controls a project. The HLD basis should say which references apply and which decisions remain owner-specific.
Approval must have a defined consequence. State the release. It may release field survey, authorize permit outreach, establish a budget basis, select the preferred topology or permit LLD to begin. We write that consequence into the transmittal and list conditions separately. An item marked complete because someone supplied a plausible assumption is more dangerous than an open item because it hides the validation work from the next team.
Demand, Topology, Route, and Capacity Gates
Demand review begins with stable location identities, not dots on a map. We check duplicates, missing records, geocoding confidence, boundary relationships and service class, plus status. We preserve the input revision used for the concept and keep rejected or excluded records visible with reasons. That evidence lets a reviewer understand why a serving area, feeder path, or terminal count changed when the source data changes.
Topology review then traces demand through the proposed hierarchy. We name the architecture, serving-area logic, hub candidates, feeder and distribution relationships, protection approach where required and spare-capacity basis, plus growth assumption. The test is not whether the diagram looks balanced. Trace a location. The test is whether representative locations can be traced through the model and whether every capacity value has a defined source or calculation.
| HLD gate | Evidence required | Approval question | Handoff output |
|---|---|---|---|
| Scope | Boundary and objectives | Is the decision defined? | Approved basis |
| Demand | Controlled location records | Do counts reconcile? | Demand snapshot |
| Topology | Architecture and serving logic | Can paths be traced? | Network diagram |
| Route | Candidates and constraints | Is the preferred corridor feasible? | Route geometry |
| Capacity | Counts and reserve basis | Do layers reconcile? | Capacity model |
| Dependencies | Owners, permits, and crossings | Are controls mapped? | Dependency register |
| Handoff | Risks, tasks, and decisions | Can LLD act without guessing? | Release package |
These 7 gates are Draftech's recommended review framework, not a measured industry result. The rows are connected: changing demand can change topology, route, capacity and quantities, plus permits at once. We therefore use stable IDs across the location file, serving-area model, route geometry and quantity workbook, plus risk register. A reviewer should be able to follow one object through all of them without translating informal labels.
Route feasibility compares alternatives on a common basis. We document available corridor evidence, aerial and underground assumptions, pole or duct uncertainty, crossings, access, restoration exposure, environmental screening and private property, plus third-party ownership. Desktop data can identify candidates, but it cannot prove every field condition. We mark unverified geometry and preserve rejected alternatives with reasons so a later constraint does not force the team to restart from nothing.
The PON power budget calculator offers an early optical check, not an HLD approval. Capacity review reconciles architecture and geometry. Feeder, distribution, terminal, and drop or service layers must use consistent units and relationships, with used and reserved, plus spare states explained. We test concentration and edge conditions rather than relying only on an average across the service area. A capacity exception should name the affected serving area and the decision needed, not hide inside a network-wide percentage.
- Location evidence: Preserve source, revision, status and confidence, plus boundary result.
- Route alternatives: Retain the preferred corridor and rejected options, plus decision reasons.
- Capacity trace: Link demand through serving area, distribution and feeder, plus hub.
- Open assumptions: Assign every material uncertainty to survey, coordination or owner decision.
The recurring failure is disconnected models. A route map uses one location count and the capacity workbook uses another, plus the estimate uses a third length. Our discussion of common FTTH HLD mistakes focuses on that logic drift. We prevent it with controlled imports, cross-model identifiers, unit checks, and a reconciliation record before the package reaches an approval meeting.
Permit, Survey, Estimate, and Risk Controls
Dependency screening maps each authority, owner, crossing, permit family, easement, environmental review, and utility coordination need to the route segment it controls. The Federal Highway Administration Utilities Program is a named federal reference for utility accommodation and coordination context. Project requirements still come from the controlling authority, owner standards and contracts, plus current permit instructions.
We do not invent universal review durations at HLD. Instead, we record application prerequisites, design maturity needed for outreach, known sequence, responsible party, alternate route, and the project decision that depends on the response. A crossing that controls the preferred corridor belongs in the HLD decision log even when the detailed application will not be prepared until LLD. Hidden dependencies become schedule surprises. Name them early. Named dependencies become managed work.
Survey planning follows consequence. Survey the uncertainty. We convert every route-critical uncertainty into a collection or coordination requirement: pole ownership and attributes, attachment elevations, span relationships, underground structures, duct evidence, road-crossing geometry, access limits, field photographs or building entrance information as applicable. The HLD should state acceptable methods and identifiers so field data returns in a form that can update the model rather than creating another detached file.
Estimate quantities must derive from the same route and architecture being approved. We separate known geometry, conceptual quantities, allowances, exclusions, and source dates, then test sensitivities that could change the decision. We do not attach false precision to an unverified corridor. Show the limit. The estimate is an HLD decision tool and not a construction bid, plus its limits should be as visible as its totals.
Risk review names the assumption, affected assets, consequence, probability basis if the owner uses one, response and owner, plus closure event. We prefer a concise register tied to map and model objects over a long list of generic cautions. The useful question is not whether the project has risk. It is which unresolved fact could invalidate the preferred route, topology, capacity plan, permit approach or estimate.
Coordination meetings should be organized around decisions, not calendar habit. Decide something. Engineering, operations, permitting, survey, finance, and the network owner need a short pre-read that shows conflicts and requested approvals. We publish accepted decisions, rejected options, actions and owners, plus conditions after the review. Long minutes without a disposition do not protect the design basis from later drift.
Decision control: Record the approval consequence and every open condition before the review meeting closes.
QA/QC and the HLD to LLD Handoff
HLD QA/QC needs a completeness pass and an engineering-logic pass. The first checks files, units, coordinates, identifiers, references and calculations, plus required fields. The second asks whether the selected concept remains reasonable under route, operating, permit and capacity, plus maintenance conditions. A package can pass a form check while its preferred route depends on an unsupported crossing or its capacity model uses stale demand.
We require an independent trace test before release. A reviewer who was not marking their own work selects representative demand records and follows each one through serving area, distribution path, feeder, hub, route geometry and quantity basis, plus risk entries. The reviewer also selects a major crossing or constraint and confirms it appears in the route, dependency register and estimate assumptions, plus survey or coordination scope.
Coordinate reference systems and export behavior deserve explicit checks. Geometry that is correct in the source application can shift or lose attributes when transferred. We verify the declared CRS, units, transformation method where needed, geometry continuity, and stable IDs in the actual files the receiving team will use. Screenshots cannot prove a usable GIS or CAD handoff because they hide the data behavior. Test the file.
The release package should include the approved design basis, controlled demand snapshot, topology diagram, serving areas, route alternatives and selected geometry, capacity model, dependency register, conceptual quantities and estimate basis, risk register, decision log and survey scope, plus explicit LLD entry conditions. Our guide to HLD design services guide shows how later detail builds on this controlled foundation.
Changes after approval return through the same controls. We record the request, reason, affected objects, technical effect, permit or owner effect, quantity effect and approval, plus implementation evidence. Field preference does not automatically replace engineering intent. Draftech's in-house engineers review design changes, while full turnkey construction can be delivered through Draftech-managed subcontract crews under our QA/QC and safety oversight.
We close QA/QC with a receiving-team test rather than a production-team declaration. The LLD lead must locate the approved route, identify its source demand and capacity basis, find every route-critical condition, and understand which geometry may be refined without reopening HLD. Operations should be able to find the same assets and decisions in the delivered data. If either role needs an undocumented explanation from the preparer, we return the package for correction. Repair the chain.
File naming and transmittal controls matter at this gate. We name the current issue, superseded issue, purpose, native files, reviewable files, coordinate reference, model versions and known exclusions, plus acceptance roles. A complete file list cannot fix conflicting content, so we compare identifiers, revision labels and route status, plus capacity status across actual outputs. One approved instruction set must reach every receiving discipline.
HLD release: If your demand, route, capacity, permit, and handoff records do not reconcile, talk to our HLD team before detailed design starts.
OSP Network High Level Design Checklist: Release Decisions
Our limitation is candid: HLD cannot prove hidden duct condition or pole ownership from desktop records. We can isolate the uncertainty and design the survey response, but we will not label an inferred corridor as field-verified simply to keep LLD moving. That distinction protects the estimate and survey scope while keeping the permit strategy plus the receiving LLD team from treating one convenient desktop line as an approved physical route. Once an inferred route enters detailed production, corrections can propagate through structure assignments and capacity calculations, reaching quantity records plus application exhibits before anyone notices that the original constraint was never verified.
The closing verdict should be explicit: approved, approved with named conditions or held. We do not use nearly approved when a route-critical source is missing. Each condition needs an owner, affected model objects, validation task and due stage, plus closure evidence. The approval transmittal should also state what work may begin and what work remains prohibited until the condition closes.
Greenfield FTTH concept: Release only when the demand snapshot, serving logic, feeder and distribution relationships, route candidates, capacity basis and dependencies, plus survey scope agree. We recommend holding LLD for any serving area whose route or capacity cannot be traced. A broad project can still advance in controlled work areas while named exceptions remain isolated.
Existing-plant expansion: Make asset confidence and integration rules part of the approval. The concept should identify which existing records are accepted, which require field verification, and how new IDs or attributes will join the operating system. Our FTTH HLD design services guide explains why the network model must connect planning decisions to the owner's maintainable record.
Funding-controlled program: Add eligibility, evidence, procurement, environmental, reporting, and change-control obligations from the controlling award and program materials to the design basis. We hold any concept that cannot show how approved scope maps to service locations and route objects. Funding compliance is not a note added after architecture. It is a condition of the architecture decision.
Fast-track program: Divide the network into explicit release areas instead of lowering the gate. Each area still needs a controlled basis, demand, topology, route, capacity and dependencies, plus handoff status. Parallel work is acceptable when interfaces are defined. Define them first. Starting LLD everywhere from provisional geometry only spreads the same unresolved assumption into more files and makes correction harder.
Our HLD engineering workflow removes the exact friction described here: demand, architecture, route, capacity, dependency, and estimate models that otherwise reach detailed design as separate versions of the truth. If your team needs an in-house HLD review or a controlled LLD entry package, email our team. We will define the decision and expose the assumptions, plus preserve the record.
