Comment from Swiftly, Inc

These comments respond to FTA's fourth service quality area "Real-time Service Data Availability" and the related questions on metrics (Q3), success thresholds (Q4), new data FTA should consider (Q7), third-party data sources (Q8), and open data standards (Q12). FTA frames this area from the perspective of a transit rider: "When is the next bus or train, and will I know about delays?" Most existing performance data in use at transit agencies today answer slightly different, operations-facing questions. On-time performance or mechanical failure rates, for example, describe how an agency ran its service. However, none of them describe whether the rider standing at a transit stop actually received usable information about it. A bus can run perfectly on time while the family waiting in the rain sees only a static schedule guess, because the agency's real-time prediction for that trip was missing. That gap between "the service ran well" and "could the rider see it coming" is currently unmeasured, and is the experience this RFI is trying to improve. We would encourage FTA to consider a real-time availability metric that captures this directly. The concept is straightforward: of all scheduled vehicle stops in a given time period, at what percentage of stops would a rider checking a trip-planning app shortly before arrival have seen a live prediction, or a clearly communicated disruption (a cancellation or skipped stop), rather than schedule-only information? A practical advantage here is that this metric can be computed today from data agencies already generate and publish. The inputs are service delivery / schedule adherence datasets (such as stop-level OTP reports) and the public real-time predictions feed (GTFS-realtime Trip Updates), making this metric is vendor-neutral and independently verifiable by FTA, transit agencies, or third parties. This speaks directly to Q8 and Q12: standardizing on existing open feeds is what makes a low-cost, comparable national metric feasible. This is also not a hypothetical or proprietary approach. A common, open methodology for exactly this measure already exists and is published as a public repository on GitHub, the ETA Completeness Benchmark (https://github.com/SwiftlyInc/ETA-Completeness-Benchmark). It defines a trip-stop as "complete" when the vehicle was assigned and had a prediction within the 0 to 15 minute window before its arrival, or when the trip carried a cancellation or skipped-stop designation in the GTFS-realtime feed, and it scores an agency as the percentage of scheduled trip-stops that meet that bar over a period. It is the companion to the separately published ETA Accuracy Benchmark (https://github.com/TransitApp/ETA-Accuracy-Benchmark) which asks how good the predictions are, completeness asks whether they reach the rider at all. The completeness methodology is already being explored and supported by a cross-section of the industry, including transit agencies (Denton County Transportation Authority, TX, METRO Akron, OH, and WeGo Public Transit, TN), the California Integrated Travel Project (Cal-ITP), and multiple private-sector firms (Blinktag, Jarrett Walker + Associates, Jarvus Innovations, Left Turn Right Turn, Transit, and Swiftly). FTA would not be inventing a metric from scratch so much as recognizing and helping to standardize an approach the industry is already actively building and adopting. For families specifically, transit ETA availability is not a nice-to-have. A parent traveling with young children, a stroller, or a tight pickup window has the least slack to absorb uncertainty, and benefits the most from simply knowing if their ride is coming. Measuring whether real-time information is actually available to the rider is one of the more direct levers FTA has on the family-friendly experience this RFI describes.