Most BEAD subgrantees coming into their first high-level design process assume the HLD is roughly the same as the network planning work they've done for commercial builds — just with more paperwork stapled to the end. That assumption causes problems. Fiber network HLD for BEAD subgrantees operates under a compliance framework that's meaningfully different from commercial HLD, and the documentation requirements exist for reasons that will directly affect your milestone approvals and your letter of credit drawdown schedule.
I've worked through BEAD HLD submissions across multiple state programs — with state administrators who have different interpretations of the same NOFO language, different review timelines, and different levels of engineering expertise on their review teams. Here's what I've actually seen fail, what tends to work, and how to build a BEAD-compliant HLD package the first time rather than the third.
What NTIA Actually Requires in BEAD HLD Documentation
The BEAD NOFO — the Notice of Funding Opportunity issued by NTIA — doesn't prescribe a specific HLD format the way a private carrier might. What it does is establish performance and coverage obligations that your HLD must demonstrate you can meet. States then translate those obligations into their own subgrantee program requirements, which is why you'll see variation between states.
But the common baseline is this: your HLD must demonstrate that every Broadband Serviceable Location (BSL) within your proposed funded service territory will receive service meeting NTIA's speed thresholds — currently 100 Mbps download / 20 Mbps upload at minimum, with the expectation of scalability to 100/100 Mbps for end-state networks. That's not just a marketing claim. It has to be supported by engineering documentation.
The standard BEAD HLD package contains:
- Serving area maps — GIS-based maps showing the proposed service boundary, with BSL locations plotted and counted. These need to reconcile with the FCC Broadband Map fabric dataset. If your serving area boundary excludes any fabric BSLs that should be served, that needs explicit justification.
- Network architecture diagram — How the network is structured from backbone to distribution to drop. For FTTH/PON deployments: the hub or headend, the feeder fiber route, splitter location and cascade structure, distribution routes, and drop termination points.
- Splitter architecture — Split ratio, location of primary and secondary splits, and the mapping between each splitter serving area and the BSLs it covers. This has to be coherent — I've reviewed HLD packages where the splitter cascade implied serving 1,400 subscribers off a 1:32 configuration. That math doesn't work.
- Fiber count plan — Count and fiber assignment from hub outward. Feeder counts, distribution counts, and drop count methodology. This doesn't need to be strand-level detail at HLD — but the count plan has to be internally consistent with the architecture and BOM.
- Optical power budget table — For every PON design, you need to show the worst-case optical path from OLT to the farthest ONU/ONT and demonstrate that the total optical loss (feeder + splitter insertion loss + distribution + connectors + margin) falls within the class B+ or class C+ budget you're designing to. This is the piece that gets missed most often, and it's the piece state reviewers with engineering backgrounds will look at first.
- Route maps — GIS-ready format showing proposed fiber routes overlaid on aerial or road network base maps, aligned with the serving area boundaries and BSL locations.
- Preliminary BOM with cost estimates — Not a construction bid, but a material estimate that supports the project cost in your subgrant agreement. Fiber, conduit, poles, splitters, OLT/ONU equipment, enclosures, and drops.
Some state programs also require a technology selection narrative — a written justification for why you chose FTTH vs. fixed wireless vs. hybrid, how the proposed technology meets the NOFO performance requirements, and what your upgrade path looks like. Don't treat this as boilerplate. State reviewers can and do push back on technology choice justifications that look copy-pasted.
How BEAD HLD Differs from Standard Commercial HLD
On a commercial FTTH build — for an ISP or carrier doing a market-driven deployment — the HLD purpose is to support construction planning and equipment procurement. The audience is internal: your engineering team, your construction managers, your supply chain. If something is unclear, someone picks up the phone.
BEAD HLD has a second audience: a state grant administrator (and potentially a federal auditor). That audience is evaluating compliance, not directing construction. They need the document to be self-contained, traceable, and defensible — meaning every claim in the HLD should be supported by either a calculation, a map, or a reference to a standard.
The other big difference is BSL accounting. On commercial builds, you design for projected subscriber density and worry about individual addresses at the drop design stage. On BEAD, every BSL in your funded territory needs to be accounted for at HLD. If there are 847 BSLs in your proposed service area, your architecture needs to demonstrably cover all 847 — not "approximately" and not "most." States will check the BSL count against the fabric, and gaps create review flags that cost you weeks.
Cost justification per location is also a BEAD-specific constraint. Your subgrant agreement will tie funding to a cost-per-location number. The HLD BOM needs to support that number. If your HLD implies a $4,200-per-location construction cost but your subgrant application stated $3,800, someone is going to ask questions. Get the HLD and the financial model aligned before submission — not after review comments arrive.
For a baseline understanding of how BEAD engineering requirements feed the overall program, our guide to BEAD engineering requirements covers the program-level context in more detail.
Common Mistakes That Delay BEAD HLD Approval
After working through state review processes in eight BEAD state programs, the patterns of failure are pretty consistent.
Incomplete Serving Area Boundary Documentation
This is the most common. The subgrantee draws a service area polygon, submits maps, and the state reviewer flags that the polygon includes 23 BSLs that aren't addressed in the architecture — or that 11 BSLs outside the polygon appear to be adjacent to the proposed route. Every ambiguous BSL requires a written response. Sometimes a design change.
The fix is straightforward but takes discipline: before finalizing your HLD boundary, do a spatial join between your proposed service area polygon and the FCC fabric dataset. Audit every BSL within 500 feet of your boundary to make sure you've consciously included or excluded it. Document that audit. The five hours this takes upfront saves weeks of review correspondence.
Missing or Inadequate Optical Budget Validation
The optical power budget table is either missing entirely or includes assumptions that don't hold up. Common problems: using OLT transmit power specs without accounting for launch power penalty at patch connections, using nominal splitter insertion loss figures rather than worst-case from the component datasheet, or ignoring connector budgets entirely.
For a class B+ PON with a 1:32 split, a reasonable loss budget looks like this: OLT launch power -3 dBm to +2 dBm, feeder cable loss at 0.35 dB/km, 1:4 primary split insertion loss approximately 7.2 dB, 1:8 secondary split insertion loss approximately 10.7 dB, distribution cable loss, plus connector and splice budgets of 0.5 dB and 0.1 dB respectively, and a 3 dB engineering margin. If your worst-case path exceeds 28 dB total, you have a problem. Run the math. Put it in a table. Show your work.
Note on split ratios: A 1:32 PON split is attractive on paper because it spreads OLT port cost across more subscribers. But in rural BEAD deployments with long feeder runs and geographically dispersed BSLs, the optical loss budget can become constraining before you've hit 32 drops. Design the split ratio to the actual optical path, not the marketing spec.
Fiber Count Plan That Doesn't Reconcile With Architecture
The count plan says 48-count feeder. The architecture diagram shows three distribution routes off the hub, each with dual-path redundancy. The math implies a minimum 72-count feeder. Nobody caught it before submission. The reviewer caught it. Four weeks of back-and-forth.
Run a fiber count reconciliation before finalizing the HLD. Every fiber path in the architecture diagram needs a corresponding count assignment in the count plan. They need to add up. This sounds basic — and it is — but it's the kind of consistency check that falls through the cracks when a team is rushing to hit a submission deadline.
BOM That Doesn't Support the Architecture
A BOM that lists 1:32 splitters when the architecture shows 1:8 cascaded splits. Or conduit quantities that don't align with the route miles in the maps. Or drop counts that don't match the BSL totals. State reviewers with engineering backgrounds will catch these mismatches, and each one requires an explanation or a revision.
The BOM is a living document through HLD development. The mistake is treating it as something you fill in at the end, after the maps and diagrams are done. Build it in parallel and reconcile it against the architecture at least twice before submission.
For a broader look at the compliance framework that HLD feeds into, our BEAD compliance checklist covers the full documentation picture including HLD, LLD, and construction phase requirements.
How HLD Quality Affects Construction Bid Accuracy
This connection is underappreciated. A weak HLD doesn't just create grant compliance problems — it produces bad construction bids, which ultimately means cost overruns, change orders, and schedule delays that affect your milestone payments.
Construction contractors price bids off the information they're given. If the HLD doesn't include a route map with enough resolution to estimate make-ready scope, contractors will pad their bids for uncertainty. If the fiber count plan is vague, material suppliers can't give accurate quotes. If the splitter architecture isn't defined, OSP construction firms can't plan vault placement, conduit sizing, or aerial attachment work.
We've seen the downstream effect of weak HLDs: a project in central Arkansas where the HLD showed a 96-count backbone route but didn't specify conduit sizing, the construction contractor assumed 2" HDPE, and the HLD team actually needed 4" for the planned fiber bundle. Change order at construction. Not catastrophic, but a $47,000 cost variance that could have been avoided with one more iteration of the HLD.
A BEAD HLD that's accurate enough to generate a tight construction bid is the goal. That means route maps at sufficient detail to read aerial vs. underground segments, pole count estimates by segment, make-ready assumptions explicitly stated, and BOM quantities traceable to the design.
The relationship between HLD quality and downstream costs is also well-documented in our piece on GIS fiber network planning — the core principle is the same: better data and design quality at the planning stage reduces cost throughout execution.
HLD in the BEAD Milestone Schedule
NTIA's BEAD program structure ties funding disbursements to milestone completion. The HLD sits near the front of that milestone chain, and its approval is typically a prerequisite before LLD begins, construction procurement starts, or certain funding tranches are released.
Most state programs structure the pre-construction milestones roughly like this:
- Subgrant agreement execution
- Environmental and historic preservation review completion (NEPA/Section 106)
- HLD submission and approval
- LLD completion and construction-ready package
- Construction contracting
- Construction commencement
If HLD approval takes longer than planned — because of missing deliverables, revision cycles, or state reviewer capacity — everything downstream shifts right. And the BEAD program has fixed performance milestones tied to construction completion and subscriber activation. A two-month slip in HLD approval can put real pressure on your construction timeline, which in turn affects your letter of credit structure and your ability to draw against the grant.
This is the part of BEAD that doesn't get enough attention in early planning. Subgrantees budget the engineering cost but don't always budget the engineering timeline conservatively enough. For a serving area of 1,000–2,000 BSLs in mixed aerial/underground terrain, allow 8–12 weeks for HLD development after field data is available — and then allow 4–8 weeks for state review and revision cycles. Some state programs have committed to 30-day review windows. Several have not consistently hit that target.
BEAD-Specific Constraints the HLD Must Address
A few constraints show up in BEAD that don't appear in commercial HLD at all.
Letter of credit requirements. BEAD subgrantees are generally required to maintain a letter of credit equal to a percentage of the subgrant award as a performance backstop. The HLD cost estimates feed the project budget, which feeds the LoC calculation. If your HLD BOM substantially understates project cost, the LoC may be inadequate — and revising it mid-project creates financing complexity. Get the HLD cost estimates right the first time.
Performance milestones tied to HLD deliverables. Some state programs define milestone completions not just as "HLD approved" but with specific deliverable components — serving area maps submitted by date X, optical budget validated by date Y. Know your subgrant agreement milestone language before you structure the HLD development schedule.
Technology substitution restrictions. Once your HLD establishes the technology approach — say, GPON FTTH — switching technologies in LLD without an HLD amendment requires state approval. This matters if you discover mid-field-survey that your chosen distribution architecture won't work in a specific sub-area. Better to flag that in HLD and address it cleanly than to hide it and deal with a compliance question later.
The common FTTH HLD mistakes that apply on commercial builds — poor splice point placement, underdimensioned hub sites, inadequate fiber count margins — all still apply on BEAD, but with the added complexity that fixing them post-approval requires formal change management through the state program. Our article on common FTTH HLD mistakes covers the design-side errors that show up regardless of funding source.
