> ## Content Index
> Fetch the complete content index at: https://broadbandbreakfast.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Jonathan Romeiro: The FTTH Acceptance Checklist BEAD Projects Should Require
- URL: https://broadbandbreakfast.com/jonathan-romeiro-the-ftth-acceptance-checklist-bead-projects-should-require/
- Published: 2025-10-17T16:45:42.000Z
- Updated: 2025-10-17T16:45:42.000Z
- Description: Many fiber builds 'pass construction' but fail operations. A short, boring acceptance package keeps schedules and services intact.
- Author: Jonathan Romeiro
- Tags: Expert Opinion, #with-siderail, FTTH, BEAD, OTDR, GIS, NOC, SLA

In my view, the most expensive delays in BEAD won’t come from trenching. They’ll show up at handoff, when a project clears construction but stumbles in operations because no one can prove—quickly and objectively—that the plant meets the standard the grant paid for.

Across multi-municipality rollouts, the pattern is consistent: acceptance packages look complete yet miss three basics. The fix is not glamorous. Publish a three-item acceptance checklist and make it part of subgrant language. Awardees keep freedom on methods and vendors; deliverables must be measurable, traceable, and usable.

Most packages include Optical Time Domain Reflectometer (OTDR) traces. Too many are decorative. Effective acceptance defines limits up front—end-to-end attenuation by wavelength, ceilings for event loss and reflectance, connector policy—and enforces launch/receive fiber practices so loss isn’t hidden. The deliverable is raw trace files in a standard format plus a one-page summary of exceptions.

When thresholds are explicit, the “argue with JPEGs” ritual ends. Disputes shrink and future troubleshooting starts from a known baseline. Field inspections show failed acceptances are usually about inconsistent criteria, not bad fiber. Set measurable limits before testing to avoid costly retesting later.

### *Splice-map traceability*

A splice map only works if a new technician can follow it without local folklore. That means standard naming for closures, trays, and ports; version control; and cross-references to OTDR events and GIS features. If a storm or contractor cut takes out a span, restoration time depends on how fast a crew moves from the drawing to the dirt.

The opposite—hand-drawn edits with no revision history—turns every outage into archaeology. Even a simple digital log with timestamps can cut restoration time dramatically.

### *As-builts for operations*

Construction-centric as-builts die in a PDF folder. Operations-ready as-builts include layered GIS or structured CAD, optical budgets, device inventories with model/serial/firmware, and change history. They map to the NOC’s monitoring views and SLAs so on-call engineers can validate, escalate, and resolve without reverse-engineering the project.

When documentation mirrors how the NOC works, activations speed up and chronic tickets drop.

### *What the numbers looked like*

Where this acceptance workflow was applied, peak-hour latency fell from \~120–250 ms to \~10–30 ms, while rework and MTTR decreased. More important for grant administrators, disputes shrank because acceptance was objective and repeatable. Everyone knew what “done” meant.

| Metric            | Before           | After           | Notes                            |
| ----------------- | ---------------- | --------------- | -------------------------------- |
| Peak-hour latency | \~120–250 ms     | \~10–30 ms      | Corridor migrations (field data) |
| MTTR              | Higher/variable  | Lower/stable    | Post-acceptance governance       |
| Rework rate       | Frequent retests | Minimal retests | Thresholds + documentation       |

### *How states can bake it into BEAD subgrants*

OTDR Acceptance. “Awardee shall submit OTDR traces with defined pass/fail thresholds (end-to-end attenuation by wavelength, event loss, reflectance). Provide raw trace files and launch/receive documentation. Include a summary table of exceptions.”

Traceable Splice Maps. “As-built splice documentation shall use standardized naming, version control, and cross-references to OTDR events and GIS features sufficient for end-to-end tracing by field personnel.”

Operations-Ready As-Builts. “As-builts shall include GIS/CAD layers, optical budgets, device inventories (model/serial/firmware), and change history aligned to the awardee’s monitoring/SLA views. PDF is permitted, but source files shall be supplied upon request.”

Add one enforcement lever: retain a small percentage until the acceptance package is approved. Once expectations are explicit, most awardees meet the mark.

### *Common pitfalls to avoid*

Pretty traces, bad baselines. Screenshots without limits don’t prove performance. Require thresholds and raw files.

Mystery closures. Standardize names and versions; ban untracked edits.

Shelfware as-builts. Tie documentation to NOC tools and SLA views.

“Set and forget.” Acceptance is the first baseline; update when change windows alter the plant.

BEAD is a chance to fund infrastructure and discipline. A short, boring acceptance package won’t trend on social media, and that’s the point. It prevents do-overs and delivers what the public was promised: fiber that works on day one—and is maintainable on day one-thousand.

***Jonathan Romeiro is a network and security integration lead in the San Francisco Bay Area. He has delivered multi-municipality fiber corridors and operations governance in Brazil and the U.S., focusing on OTDR/splice/as-built acceptance, observability, and NOC-ready documentation. This Expert Opinion is exclusive to Broadband Breakfast.***

***Broadband Breakfast accepts commentary from informed observers of the broadband scene. Please send pieces to*** [***commentary@breakfast.media***](mailto:commentary@breakfast.media)***. The views expressed in Expert Opinion pieces do not necessarily reflect the views of Broadband Breakfast and Breakfast Media LLC.***