Robust and Extensible Measurement of Broadband Plans

Independent, address-level broadband data is essential for evaluating whether major public investments such as the $42B Broadband Equity, Access, and Deployment (BEAD) program actually improve broadband availability, quality, and affordability over time.

Broadband plan data must often be collected from consumer-facing ISP websites, but those interfaces evolve frequently, differ substantially across providers, and are expensive to maintain with traditional scraping workflows. To this end, is it possible to build a system that is simultaneously robust to frequent ISP website changes, extensible across a large and heterogeneous ISP ecosystem, and usable with low technical overhead including by non-expert stakeholders?

We therefore propose BQT: a system that replaces brittle, monolithic workflows with a more modular and adaptive representation of broadband-querying tasks.

Why this matters

Broadband policy increasingly depends on longitudinal, address-level evidence rather than static or self-reported regulatory datasets.

Existing public datasets such as Form 477, the Broadband Data Collection, and the National Broadband Map are useful, but they rely heavily on provider self-reporting and provide limited visibility into pricing, eligibility constraints, and how plans change over time.

That is a major limitation for policy workloads such as evaluating whether BEAD-funded deployment improves real consumer outcomes, tracking whether broadband remains affordable for low-income households, monitoring evolving ISP plans across hundreds of providers, enabling timely intervention when public spending fails to produce equitable outcomes

Core idea: from workflows to interaction state spaces

Prior systems model each ISP website as a single deterministic workflow: a hard-coded sequence of steps from entering an address to viewing plans. This design becomes fragile when websites add popups, reorder steps, or introduce alternate paths. BQT instead models each ISP interaction as an interaction state space, formalized as an abstract nondeterministic finite automaton (NFA).

In this design:

• states represent observable interface conditions, such as address entry, plan view, or no-service outcomes
• actions represent admissible user interactions, such as clicking a button or entering text
• transitions allow multiple possible successor states, so the system can adapt to alternate interface paths at runtime

The figure above illustrates BQT’s workflow. Dotted/blue markings show where ISP interface evolution forces changes: BQT adds and updates individual state specifications, and traverses from the currently observed state. BQT separates intent (what the system is trying to observe and extract) from execution (how the system navigates the website at runtime). This design localizes maintenance when interfaces change and allows BQT to traverse different valid paths without rewriting an entire workflow.

System design

BQT has three main components.

1. Declarative intent specification

Instead of writing one large imperative script per ISP, users specify a finite set of:

• abstract interaction states
• detectors for recognizing those states from observable cues
• admissible actions for each state
• terminal outcome states, including extraction states when plan data is visible

This makes specifications modular and easier to update.

2. Abstract-to-concrete NFA instantiation

The abstract intent is compiled into a concrete executable representation.

• State detectors are bound to page-observable cues such as visible text or UI structure
• Actions are bound to reusable handlers from a fixed action API
• Both manual and agentic authoring compile into the same concrete NFA representation

3. Observe–match–act execution

At runtime, BQT repeatedly:

1. observes the rendered ISP page
2. matches the current interface against known states
3. selects an admissible action
4. re-observes the page and continues until a terminal outcome is reached

This lets the system adapt dynamically when websites introduce intermediate steps, alternate paths, or local interface changes.

Authoring model

The paper presents two ways to author BQT specifications.

Manual interface

A user explores an ISP site, records the interaction, and explicitly defines states, detectors, and actions.

Agentic interface

A user provides a high-level natural language description such as “enter the address and check availability,” and an LLM-powered web actor synthesizes the abstract intent specification. This design allows for usability by non-technical experts such as public advocates, government offices, and nonprofits who may not have engineering expertise.

Evaluation

We evaluate BQT using two operational datasets:

• a longitudinal dataset spanning 64 ISPs, queried repeatedly over weeks to months
• a coverage snapshot spanning 100 ISPs

The evaluation focuses on three system properties: extensibility, robustness, and technical debt. The table above highlights extensibility and robustness effort required to add and update ISP workflows.

1. Extensibility

To add a new ISP, BQT typically requires between 3 and 28 states, a median of 6 states, and a median of 19 logical lines of specification (LLoS). These results suggest that BQT keeps onboarding effort relatively modest even across structurally diverse ISP workflows.

2. Robustness under interface churn

Across 64 longitudinally monitored ISPs, we observed 56 interface-driven interventions, with 35 ISPs exhibiting at least one change. For each intervention, BQT requires only localized edits, with a median of 2 affected states and a median of 5 LLoS changed. BQT’s abstraction converts interface evolution into localized state updates rather than large workflow rewrites.

3. Lower technical debt

Figure (a) above plots the cumulative number of unique detector tokens as ISPs are added. The curve grows sublinearly with coverage, showing the new ISPs rarely introduce new detectors tokens and instead reuse existing ones. Figure (b) shows the distribution of pairwise Jaccard similiarity over tokenized detector strings, where most detectors show overlap with existing ones. BQT scales efficiently, with increasing coverage requiring relatively little additional specification effort.

Summary

BQT rethinks broadband data collection by shifting from rigid workflows to flexible interaction state spaces. This design improves robustness to interface changes, reduces maintenance overhead, enables extensibility across diverse ISPs, and lowers the barrier to entry for non-expert users.