NTD Program Support RFI SOW.docx

National Transit Database (NTD) Program Support Background/Purpose FTA’s National Transit Database (NTD) was created to help meet the needs of individual public transportation systems, all levels of government, and the public for information on which to base public transportation service planning. It is the primary repository of public transportation data in the United States. The NTD collects financial data, operating statistics, safety events, asset conditions, and more from American transit systems. FTA uses NTD data to apportion funding to urbanized and rural areas in the United States, to inform decision makers at all levels of government, and for research purposes.

FTA has an existing NTD Program Support contract furnishing services described herein and organized by Contract Line Item Number (CLIN). This acquisition seeks to find a firm (hereafter “Program Support” or “the Contractor”) to continue these support services in accordance with the Statement of Work described herein.

NTD Program The NTD production process begins when individual transit agencies begin assembling internal records on their transit operations according to FTA’s uniform system of accounts and the NTD Policy Manual. NTD Program Support provides assistance and training to transit agency staff to support this process. Transit agency staff then input data into the NTD reporting tool.[footnoteRef:2] This website uses the Appian cloud computing enterprise software for the reporting interface. The website prompts a transit agency user to complete and submit NTD forms. FTA publishes a user guide that describes the physical mechanisms how users can enter their data.[footnoteRef:3] Once submitted, the data is validated before being published in different data products, otherwise referred to as publications, files, flat files, or data files. [2: https://www.transit.dot.gov/ntd/national-transit-reporting-tool] [3: NTD User Guide, https://www.transit.dot.gov/ntd/ntd-annual-reporting-user-guide]

The Contractor manages data submitted to the NTD through the Appian web interface and ‘report packages.’ Report packages contain all required data points and different forms for a given reporting module. NTD reporting requirements are organized by reporting module, and as such, the associated collection and validation work are organized by CLIN for each. These data move through stages of validation before being closed out. For instance, the earliest stage of review is the original submission, and the last stage is ‘closeout.’ If the data is high-quality, meets reporting requirements, and there are no validation issues, then the data proceed quickly from original submission to closeout.

In most cases, submitted data requires revisions. FTA requires the incumbent to manage all aspects of processing the data. For instance, an agency might submit the data October 31, but validation checks have flagged 50 data points requiring validation. Over the next several weeks, the Contractor performs ‘validation’ with the NTD reporter. Validation refers to the staff follow-up and tracking to closeout all 50 issues. Each issue is resolved by the transit agency either revising the previously submitted data or else by providing a sufficient explanation for the data to the satisfaction of the validation analyst. The Contractor uses the Appian web interface to assign certain issues or tasks for the submitting agency to resolve.[footnoteRef:4] The Contractor is responsible for communicating with the agency and to ensure that the agency resolves the issues. When all 50 issues have been resolved, then FTA reviews and approves the final submitted package. [4: The Appian process, including examples of tasks and issues, is also described in the NTD User Guide.]

NTD Program Support consists of three primary functions: Data Collection, Validation, and Data Products.

Data Collection The NTD program collects transit data. The NTD program is a longitudinal survey of the transit industry—it collects data from the same organizations year after year. However, each agency may have different individual system users who physically report these data in the online system. This makes data collection and validation challenging since these users change often, and the NTD program is required by law to collect data according to uniform system of accounts. Therefore, the NTD program provides significant assistance and training to its client users each year to ensure that required data is reported to the NTD program consistently and according to the specific standards and definitions established by the program. Additionally, the NTD program conducts extensive follow-up to remind its client users to complete their reports on-time or to complete past due reports.

Validation The NTD program validates the data submitted. Validation is a critical program component to ensure that the data meets the standards, definitions, and requirements described in the NTD Policy Manual. Validation ensures that NTD data used by decision makers at all levels of government is reliable. Validation also ensures the proper distribution of billions of dollars of Federal funding that rely on NTD data each year. Data is validated using two different processes: (1) in real time when a user initially enters the data on the NTD website; and (2) using NTD’s Branch Environment database (described further below).

Data Products The NTD program uses validated data to produce apportionment and other data products. In total, there are approximately 60 annual data products, 20 monthly data products (including on safety and security), 15 apportionment data products, and 2,250 transit agency profiles, and one narrative summary of transit produced each year. The apportionment data products determine the distribution of billions of dollars in formula funding according to Federal law. There are also an estimated 20 special analysis data products produced at various times during the year.

Information Technology (IT) and Data-Related Processes The NTD program primarily relies on two databases: (1) Appian database (‘Appian’), and (2) Branch Environment database (‘Branch’)[footnoteRef:5]: [5: There are multiple databases in Appian. However, these related Appian servers contain largely the same data. Thus, this RFP refers to the Appian database as a single database.]

Appian Database The Appian Cloud is a platform-as-a-service (PaaS) solution that collects and houses NTD data. Appian houses NTD’s transactional database for data collection and serves as the NTD system of record. Appian serves as the ‘front end’ to the NTD. Each night, FTA moves the collected data through a pipeline of extract, transform, and load processes. These processes create copies of Appian database data in the Branch Environment database.

Branch Environment Database The Branch Environment (‘Branch’) is a cloud based, MariaDB database housed at the Department of Transportation (DOT). Its purpose is to support data validation activities and production of data products. It is a separate database from ‘Appian.’ Branch houses a copy of the Appian database. Branch also houses other industry-standard database objects, many derived from the copy of the Appian database (e.g., indexes). NTD Branch has approximately 50 million records spread across four transactional tables and approximately 300 referential tables.

Information Technology security (IT security) is managed by FTA’s Office of Administration (TAD) and the Contractor is not required to manage Branch’s IT Security. TAD owns Branch, is responsible for making it accessible, and will assist in meeting TBP’s business requirements. The copy of the Appian database is limited to ‘select’ privileges. The Contractor will have permission to manage the other aspects of Branch to perform data validation and production of static data products as needed. These permissions include:

· Creating, editing, and deleting database objects

· Creating, editing, deleting, and executing events, views, queries, stored procedures, and tables

· Creating, editing, deleting, and executing queries All data and database objects, such as events, views, queries, stored procedures, tables, and related documentation are owned by FTA.

IT Roles and Responsibilities Two FTA offices have IT support-related roles and responsibilities. First, TAD is primarily responsible for the day-to-day functionality of the Appian Database, the Appian online reporting interface, and the Branch system. TAD is responsible for the NTD front-end data portal where transit agencies enter their data, known as the Transit Integrated Appian Development (TrIAD) platform. Within the NTD data entry portal, TAD is responsible for all development and enhancements to the systems, and ensuring that they are live, active, and available. The Contractor is responsible for ensuring that the captured data is accurate.

The second FTA office is the Office of Budget and Policy (TBP). With respect to NTD services, TBP’s role is that of a client. TBP staff and its contractor oversee the programmatic aspects of the NTD, including all business requirements, data collection, validation, and data products. TBP staff and its contractors prioritize bug fixes and system enhancements and perform user acceptance testing before deployment. This includes disaster recovery testing involving the NTD Appian database. TAD and TBP hold regular coordination meetings to set these priorities and discuss emerging issues.

Many issues involve shared responsibility between TAD, TBP, and their contractors. For instance, if a user encounters an error, and the Contractor detects the error, the Contractor is responsible for creating a TAD support ticket. TAD is responsible for identifying a root cause and fixing the issue. The Contractor helps TAD prioritize all the detected errors for resolution.

TBP and the Contractor interact with the Branch database, and TAD provides software and support to connect to Branch at no cost to the Contractor. TBP and the Contractor execute all queries on the Branch Environment. TBP and TAD also provide access to Branch so that the Contractor can access draft data that supports validation, reports, and other functionality. Additional documentation about the roles and responsibilities of TAD, TBP, and its contractors is available upon request. The Contractor is also provided read-only access to the front-end user interface for purposes of being able to see the end-user experience in the system. The front-end user interface does not support any direct queries or scripting activities.

General Data Collection In total, approximately 3,000 transit agencies report to the NTD. Each organization that reports to the NTD is assigned an NTDID, each NTDID is assigned a reporter type, and each reporter type is required to fill out a series of reporting forms.

Reporter Type FTA uses reporter type to capture relevant levels of detail applicable to different types of transit operations. Different ‘reporter types’ submit different amounts of data. For example, full reporters fill in the most forms and fields, while reduced reporters fill out fewer forms and fields.

The existing reporter types include Full Reporter, Reduced Reporter, Separate Service Reporter, Build Reporter, Planning Reporter, State Reporter, Rural Reporter, Tribal Reporter, Reduced Asset Reporter, and Group Plan Sponsor. Detailed descriptions of each reporter type are described in NTD’s policy manual.[footnoteRef:6] [6: https://www.transit.dot.gov/ntd/2024-ntd-reporting-policy-manual ]

Reporting Forms FTA collects NTD data according to a series of forms.[footnoteRef:7] Forms vary in complexity as some require users to complete more data fields than others. Certain forms are only filled out once. For example, the “Profile” Forms and some of the “Basic” Forms are specific to a single NTDID or reporting agency. However, most forms must be filled out for each mode and type of service (TOS) operated by the reporting agency: [7: Screenshots of samples of reporting forms can be found here: https://www.transit.dot.gov/ntd/ntd-reporting-system-forms]

· Mode refers to the characteristics of a unit of transit service operation. The NTD has established 20 modes, including heavy rail, commuter rail, light rail, streetcar rail, ferryboat, motorbus, commuter bus, bus rapid transit, demand response, and more.

· Type of service refers to the organizational arrangement of the mode. The NTD has established 4 types of service, the most common of which are directly operated and purchased transportation (contracted out operations).

The average NTD form has 56 fields, with a range of 2 to 227 fields on the shortest and longest forms, respectively.[footnoteRef:8] The following table provides a brief narrative summary of each form category: [8: For more differences between different forms within the same category of form, see the user guide.]

P-20 P-30 P-40 P-50

B-15 B-30

F-10 F-20 F-30 F-40 F-60

A-15 A-20 A-30 A-35 A-90

R-20

WE-20

S&S-30 S&S-40 S&S-50 S&S-60

General Data Validation The Contractor performs validation across all CLINs. Validation consists of examining the completeness and accuracy of the data submitted to the NTD. The purpose of validation is to ensure that the data reported to the NTD is complete, accurate, and is consistent with the definitions and standards established in the NTD policy manuals and Uniform System of Accounts. Invalid data is regularly submitted to the NTD for a number of reasons including:

· Typographical / data entry errors

· Incorrect assembly of the data from the agency’s record keeping systems by the individual responsible for submitting the data to the NTD

· The agency’s underlying record keeping systems not keeping the data in accordance with NTD definitions and standards Many of the NTD’s validation checks rely upon checking that the submitted value falls within in an expected range. FTA has several ways of defining the expected range:

· Comparing the submitted data with data submitted for an earlier period. For example, it’s unusual for transit operations to change by more than 20% from one period to the next, outside of unusual circumstances, such as a global pandemic;

· Comparing the submitted data for one field with data submitted for another field in the same report. For example, if vehicle revenue miles increase by 10%, FTA would expect vehicle revenue hours to also increase by about 10%; and

· Comparing the data to industry benchmarks. For example, dividing vehicle revenue miles by vehicle revenue hours calculates average speed. It would be extremely unlikely for average speed to exceed a typical speed limit.

FTA’s validation checks can be thought of as producing two types of errors:

· Type 1 errors occur when the validation rule activates an alert. For example, a user submits data that activates an alert (or ‘check’). The reporting system then requires the user to confirm that the data has been entered correctly through a written explanation. There is a subset of Type 1 errors that occur because the data in the prior period was incorrect, thus producing an unusual percent change.

· Type 2 errors occur when a validation check does not fire even though the data was either entered incorrectly, or else does not meet NTD definitions and standards. Type 2 errors are hard to measure. However, Type 2 errors can be identified retrospectively, for example, when the subset Type 1 errors described above occur. One example of a Type 2 error would be where a transit agency reported 0 for February and March ridership even though service restarted in March. A validation check for March would not catch this as it was consistent with the prior month, but in reality, ridership should not have been 0.

FTA seeks continuous improvement in its validation procedures to minimize both Type 1 and Type 2 errors. In total across all CLINs, the Contractor indirectly or directly manages approximately 1,500 business validation rules:

· 1,200 of the 1,500 business rules are programmed into the Appian production environment and will fire automatically when the business logic requires. The Contractor is responsible for maintaining these indirectly through general documentation about the business logic and submitting requests to TAD to update, fix, or change these rules.

· 300 of 1500 validation rules are managed through SQL code and require the contractor to execute the code, maintain documentation, and upload any flagged items into the system. FTA intends to move these 300 validation rules into the Appian environment over time.

The NTD program also assures valid data submissions through audit requirements. Specifically, the NTD requires each agency to periodically submit sufficient documentation that their NTD data is reviewed by an independent auditor. A full description of audit-related documentation is listed in the NTD’s Annual Policy Manual. The Contractor reviews the submitted auditor’s statement for completeness and corrective actions related to negative findings.

ANTICIPATED BASE PERIOD: November 1, 2025 – October 31, 2026

1. CLIN 0001: NTD ASSISTANCE FOR 11/2025 – 10/2026

The tasks associated with this CLIN are: (i) operating the NTD Help Desk, (ii) managing requests for assistance efficiently and accurately, (iii) a weekly status report, and (iv) updating website resources.

i. Operating the NTD Help Desk FTA requires that the Contractor provide assistance directly to individuals or entities that submit a request (typically transit agency personnel), both to resolve inquiries and to improve the quality of reported data. Inquiries often come directly from transit agency personnel via email to NTDHelp@dot.gov or by phone. The Contractor must manage inbound and outbound email or phone calls to respond to requests. Most inquiries requiring programmatic assistance will be received via email or by the inquirer reaching out to their NTD Validation Analyst directly.

The Contractor will be required to host an inbound public facing phone line to provide business-knowledge assistance, ensuring users have direct access to skilled technicians for immediate assistance during and beyond business hours to accommodate time zones, potentially from 8:00 am to 7:00 pm ET. Calls will be logged and categorized, with a goal of all calls being a) resolved in real time by the phone technician, or b) resolved by putting the inquirer in direct contact with their NTD Validation Analyst.

Additionally, some requests originate through phone calls to FTA’s overarching IT Help Desk. The FTA IT Help Desk resolves technical questions requiring system knowledge and is led by a separate office at FTA. Any tickets that require NTD business knowledge will be routed from the FTA IT Help Desk to NTDHelp@dot.gov.

ii. Managing Requests Efficiently and Accurately FTA requires that the Contractor log, categorize, track, and resolve all requests for assistance that require NTD business knowledge using Jira (or whatever incident tracking tool FTA IT uses) to document, tag, prioritize, and appropriately route all tickets. FTA uses this software for assistance requests, software issue tracking, and project management. Jira licenses and access will be provided by FTA at no cost to the Contractor. The Contractor is required to resolve all tickets (answering the submitter’s question or ensuring their issue is addressed) in a reasonable amount of time.

FTA requires that the Contractor provide assistance from 8:00AM to 7:00PM Eastern Time and make initial response within two business hours.[footnoteRef:10] FTA expects all tickets be resolved by the following business day, except for those raising novel (previously unanswered) questions regarding interpretation of reporting requirements. Overall, FTA expects 33% of all tickets to be resolved within 1 business day and 90% within 4 business days. FTA tracks which questions have been answered through a JIRA project. [10: The FTA will provide the Contractor with access to manage the NTD’s incoming email address: NTDHelp@dot.gov at no cost. In addition, routine communications for validation (described in CLIN 0002 below) may require phone support to assist NTD reporters in meeting their deadlines.]

The Contractor is required to use DOT email addresses when engaged in government business with persons outside the agency. DOT email addresses are supplied by FTA. However, FTA requires that the Contractor use their own phone numbers to make outbound phone calls to handle tickets as needed for resolution.

Level of Effort The Contractor is required to manage and resolve approximately 1,000 NTD Jira tickets per year (which FTA estimates average around 2 hours of effort per ticket). This includes all aspects of work, from logging the initial inquiry in Jira through resolving the issue and sending the customer an acknowledgement that their question has been resolved. Requests range from simple to complex. Complex requests are typically referred to FTA staff for an official decision, and so may take longer to resolve. FTA requires that the Contractor is responsible for deleting duplicates and prioritizing tickets. [footnoteRef:11] [11: For instance, FTA requires that the Contractor prioritizing time-sensitive questions and questions with funding implications.]

Complex Requests Of the 1,000 Tickets, 200 are complex, which involve ‘policy issues’ and typically require resolution by FTA staff. Policy issues are those that affect multiple agencies at once rather than specific agency-issues, which are typically handled through the Appian process and validation (see e.g., CLIN 0002). Examples of complex policy issues are available upon request.

The issues above are policy issues rather than issues that apply to one particular agency. However, in some cases, an agency will email validation questions to NTDHelp@dot.gov, which are covered under this CLIN.

Simple Requests Of the 1,000 tickets, 800 are considered “simple requests”. Most of these tickets fall into one of the following categories:

· Data Collection Guidance: FTA receives approximately 100 requests per year for general data collection questions. These inquiries consist of questions regarding different types of forms and individual form fields. Some of these questions come in directly from the NTD reporters or FTA staff. For instance, an FTA regional staff member may ask that the Contractor help answer hypothetical questions, such as: “A current transit agency is considering acquiring a new bus that would be used for both Demand Response and Fixed-Route service. How should the agency report this to the NTD?” FTA requires that the Contractor is responsible for maintaining staff knowledgeable to answer similar questions.

· Data Product Guidance: FTA receives approximately 50 requests for data product guidance per year. These inquiries consist of answering questions regarding where to find various data points across the NTD’s data products.

· New User Management: FTA requires that the Contractor process requests from transit agencies that wish to newly begin reporting to the NTD (‘New ID’ requests). These requests typically begin with an email from the agency to NTDHelp@dot.gov with some limited information. The Contractor will be required to do applicable follow-up if information is missing or needed. The Contractor then creates a Jira ticket from that information for FTA approval.

· Automatic Passenger Counter (APC) Requests: FTA requires that the Contractor also answers requests for Automatic Passenger Counter (APC) certification. In the past, FTA has received 1 to 20 requests for new APC certification annually. Processing these applications involves reviewing the application for consistency with NTD reporting requirements. In particular, transit agencies planning to use APCs must document how they will validate the accuracy of the APCs, and how they will handle equipment errors and malfunctions. In most cases, approval requires requesting additional information from the transit agency on the exact nature of the service provided. The Contractor is responsible for responding to APC requests both for new APCs and for modifications given COVID-restrictions.

iii. Weekly Status Report FTA requires that the Contractor produce a weekly status report and deliver it to FTA as an appendix within the weekly Program Performance Report (CLIN 0008). Specifically, FTA requires that the Contractor keep written documentation summarizing data about the NTD Help Desk in a manner that answers changing business questions. This could include a table with the number of inquiries by subject area, their method of inquiry (email, phone, or FTA IT Help Desk), and/or how long the inquiries took to close. It could also include a high-level summary of observations or recommendations for improvements to reduce the number of incoming tickets.

2. CLIN 0002: ANNUAL MODULE AND VALIDATION FOR 11/2025 – 10/2026

The tasks associated with this CLIN are: (i) annual data collection, (ii) validation, (iii) failure to report escalation; and (iv) annual validation improvement summary report. It is anticipated that the tasks in CLIN 0002 will account for approximately half of the total effort required for the contract.

During the base period (November 1, 2025 – October 31, 2026), the Contractor must ensure that annual data is collected and validated so that the data is complete, complies with published reporting requirements, and finishes on-schedule. Data to fulfill reporting requirements for the annual module span a variety of subject areas, and the Contractor must staff accordingly for successful collection and validation of this data. These subject areas include but are not limited to public transportation, financial data, operating and service data, geospatial data, transit asset conditions, and safety and security event information.

i. Data Collection The Contractor is responsible for managing all aspects of collecting NTD’s annual data.[footnoteRef:12] NTD reporters use FTA’s Appian website to enter their annual data. The data are entered as annual reports and FTA is responsible for signing and closing the review of each report. The Contractor is responsible for distribution of report caseload to contracting staff. The reports are typically due four months from the end of the agency’s fiscal year. [12: Note, the exception is that FTA’s IT office is responsible for operation, maintenance, and enhancements of the NTD Production database (Appian), and FTA requires that the Contractor is not responsible for this work.]

As part of collection, the Contractor is required to track and resolve the 70,000 report-data quality issues, with appropriate communication inside and outside of Appian:

· Work inside Appian refers to Appian system tasks.[footnoteRef:13] Appian system task management is iteratively performed throughout the data collection process; reports may be revised but are ultimately routed to FTA for final approval (closeout). [13: Examples can be found here: https://cms7.fta.dot.gov/sites/fta.dot.gov/files/docs/RY%2016%20NTD%20Validation%20Module%20Guide.pdf ]

· Work outside of Appian means 1) performing and logging the actual email or telephonic communications, and 2) processing issues identified via the Validation Log (see Branch Supplement to Appian Validation Rules below). FTA requires that the Contractor’s staff process lists of validation checks in the validation log (described below). The validation checks are commonly flags asking transit agencies to explain each anomaly. The Contractor tracks the back-and-forth communications to identify whether the data point reported was erroneous or is in fact correct. The resolution of these communications is then added to the Validation Log.

Validation Log An NTD ‘Validation Log’ is Microsoft Excel spreadsheet and a core component of the Annual Module (CLIN 0002). While the logs are consolidated documents, one per NTDID, they are generated via two processes: (1) Appian; and (2) Branch.

Appian and Appian Validation Rules First, Appian is the system of record for the logs. Appian has Microsoft Excel export functionality, and FTA requires that the Contractor use this functionality to build, export, and reupload completed copies of the Validation Log for processing and recordkeeping. The Appian system automatically populates most records requiring agency follow-up in the Validation Log. Specifically, Appian records which of the 1,200 of its in-system validation business rules an agency triggered when they submitted their annual report. In the vast majority of annual reports, data submissions only trigger a small fraction of rules. A typical annual report triggers 50 validation checks, but that can range from 0 to 200.

Branch Supplement to Appian Validation Rules The Contractor supplements the Validation Log with the results from the additional 300 Branch environment validation checks. These are rules that are not all in Appian due to one of several reasons, e.g., performance impacts. The automated portion of this process is first. FTA requires that the Contractor uses nightly database stored procedures to produce results in a similar file format to the Validation Log.

FTA requires that the Contractor’s staff use these files to transcribe the results into Appian so that Appian contains a full record of validation rule results. For instance, if a given agency had 50 of the 1,200 validation ‘in-system’ rules trigger, 18 of the 300 Branch validation rules might have also triggered, for a total of 68 records in the final Validation Log. After the extra 18 validation rules have been entered into Appian, FTA requires that the Contractor then exports the Validation Log for its staff to complete.

Final Completed Validation Log To complete the Validation Log, FTA requires that the Contractor communicates with each agency to make corrections or document explanations. Corrections account for errors while explanations occur when the agency’s submitted data was anomalous but correct.

Annual Module Schedule FTA has established the targets shown in the table below for completing the validation process each year. The Contractor must develop and execute a written work plan, so that these reporters are fully validated (‘closed out’) according to the table below. The Contractor must complete validation of all annual reports by July 7 of each year including processing all data submitted into Appian. FTA will receive the data no later than July 7 and complete its approval by July 15 even if the interim targets were not met. Currently, FTA relies on the Contractor to recommend and implement escalating consequences for non-responsive agencies (described further below in CLIN 0015). As part of meeting the schedule below, FTA requires that the Contractor deactivate non-responsive agencies from the NTD after FTA approval. The annual reporting cycle is described further in the NTD Policy Manual.

Fiscal Year End Date Report Due Contractor Work Complete - Final Closeout Date FTA Final Closeout Date # of Reporters June 30 or October 31 March 15 March 22 60% earlier

(1,800 of 3,000) July 1 to January 30 May 15th May 22 20% September 30

(600 of 3,000) October 1 to April 30 July 7 July 15 20% December 31

(600 of 3,000)

ii. Validation FTA uses validation processes for each NTD reporter to ensure data submissions are complete, timely, and accurate. The Contractor will perform validation checks using the Appian Platform and Branch. Over the course of the year, the Contractor is required to use their staff to process approximately 90,000 ‘issues’, such as validation anomalies or inconsistencies that are tracked in Appian (70,000 checks via the 1,200 validation rules) and in Branch (20,000 checks via its 300 validation rules). The Contractor will produce several different deliverables as validation progresses and before the end of the report year. These deliverables are as follows:

· Manuals and Guidance to NTD Reporters: There are several different documents that FTA requires that the Contractor use, share with FTA, and disseminate to its staff to ‘close out’ agencies. The most important items are the Validation Manual (or Annual Standard Operating Procedures Manual). The Validation manual contains letter templates, example emails to send, hold harmless procedures, sampling, and other procedures. FTA does not publish the full Validation Manual, but an example excerpt was most recently published in 2016.[footnoteRef:14] Other related validation documents are: (1) Safety and Security Validation Manual and (2) Validation Checklists (Full Reporters, Group Plan Sponsors, Reduced Reporters, or Tribal Reporters). Copies of these documents are available upon request. [14: https://www.transit.dot.gov/ntd/report-year-2016-validation-module-guide]

· Exceptions: FTA requires that the Contractor process approximately 1,000 requests for variances or exceptions from NTD reporting standards and requirements per year (FTA refers to these data points as ‘questionable’ or ‘waived’ data points). For instance, one transit agency may request reporting relief if their ridership counter equipment broke.

· Policy Question Summaries: As part of the annual module, transit agencies may raise novel policy questions as the Contractor is validating submitted data. As novel policy questions emerge, the Contractor creates narrative descriptions, analysis, and recommendations for FTA to review and resolve policy issues for relevant questions from reporting agencies. These may be similar to questions raised in CLIN 0001.

· The difference is that these questions and summaries are raised in the course of validation. For instance, an agency may report a new demand response service when it submits its annual report under CLIN 0002, but this demand response service offers rides that are not clearly shared rides, which is a requirement to report data to the NTD. As a new mode/type of service, the Contractor would gather information from the agency and perform its own internet research. However, if the analyst was unable to determine whether the service offered shared rides, they could escalate the issue to FTA. The same issue might have escalated to FTA under CLIN 0001 if the NTD reporter had emailed NTDHelp@dot.gov to ask if the service was reportable. However, in this example, the issue arose during validation instead.

· In total, the Contractor will log approximately 50 complex policy questions (JIRA tickets) per year through CLIN 0002 that require FTA decisions or input.

· Perform Validation Work to Progress NTD Reporter Data Report Packages from Submitted to Close-Out: FTA requires that the Contractor’s staff process approximately 1,200 closeout report ‘packages’ for the 3,000 annual NTD reports.[footnoteRef:15] FTA requires that the Contractor use validation checklists for different reporter types.[footnoteRef:16] This includes urban, rural, and tribal-specific validation checklist items, including specific validation review tasks specific to each form type. Other correspondences include the approval or denial of new NTDIDs, reporting deadline extension requests, passenger mile sampling waivers, other data waivers, full reporting waivers, natural disaster adjustments, or strike adjustments. [15: There are only 1,200 ‘closeout reports’ in Appian for the 3,000 transit agency annual reports because many annual reports may be aggregated or nested within a closeout report. The largest group of these nested reports are rural reporters, where 1,250 rural reports are nested within the 54 state reporters (including Puerto Rico, American Samoa, Guam, and the Northern Mariana Islands).] [16: These are checklists for (1) Full Reporters; (2) Group Plan Sponsors; (3) Reduced Reporters; (4) State Reporters; and (5) Tribal Reporters. These checklists are each one-to-ten-page word documents with a list of manual and automated validation checks that the analyst should perform.]

· Closeout Letters. For each report package, the Contractor must draft a closeout letter and route for signature by an FTA official. There are currently approximately 1,200 report packages each year covering 3,000 annual NTD reports. Closeout refers to the final review and acceptance of a reporter’s NTD data by FTA. For FTA grantees that are required to report to the NTD, the closeout letter acts as their “receipt” to document compliance with the reporting requirements. It contains some general language as well as specific provisions related to the individual report. For data questions that were not able to be resolved during the validation process, the close-out letter provides official documentation of what deficiencies must be corrected for the next report year. Agency-specific provisions vary.[footnoteRef:17] The Appian system automates the template but requires the Contractor to complete the appropriate text fields specific to each NTDID. The Contractor also sends the letters via Appian. Although there are approximately 1,200 closeout letters, half or less require customization. [17: Examples include data questions that were not able to be resolved during the validation process, the close-out letter provides official documentation of what deficiencies must be corrected for the next report year. The close-out letter also contains official program announcements and reporting reminders. FTA reviews each close-out letter for grammatical correctness and use of plain language.]

iii. Failure to Report Escalation The Contractor is required to draft, route, and track formal warning letters to transit agencies for late submission of reports or for failure to make a timely response to validation questions. These letters are issue-specific, including documenting the explanation an agency gives as to why it’s late, whether that complies with precedent or other reporting exceptions, and what will happen after additional warning letters. The communications associated with failure to report are described further in CLIN 0015.

3. CLIN 0003: MONTHLY MODULE COLLECTION AND VALIDATION FOR 11/2025 – 10/2026

The tasks associated with this CLIN are: (i) data collection, (ii) validation, and (iii) Weekly Reference Data Collection.

The NTD program collects monthly module data from the approximately 500 Full Reporters through the Ridership Activity (MR-20) form. In addition, the NTD program collects three data points on transit service, including vehicle revenue miles (VRM), unlinked passenger trips (UPT), and vehicles operated in maximum service (VOMS), from approximately 400 reporters under the WE-20 form. However, because these reporters have on average four modes/types of service, there are a total of approximately 1,200 modes/types of service to process under this CLIN.[footnoteRef:18] [18: Note these are separate from the safety module reports (Form S&S-50). The safety module is also submitted monthly but is independent of the monthly module for reporting purposes.]

i. Data Collection The Contractor is required to ensure that NTD reporters submit their monthly module data correctly by FTA’s deadlines. The monthly module consists of the MR-20 Form with five fields per mode/type of service. Monthly modules reports are due by the end of the following month. For instance, data for March 1 through March 30 is due by April 30. At least eighty-five percent (85%) of the previous year’s data must be reported on-time each month.

The incumbent contractor met this performance standard using a combination of the following communications tools:[footnoteRef:19] [19: FTA will consider comparable substitute processes if proposed, tested, and approved in writing by FTA.]

· Late Notices – Notices sent after the due date has passed via email, using template text, and SQL scripts and the Branch database to identify who receives these notices; and

· Likely-to-be-Late Notices – Case-by case reminders sent to those likely to be late on an ad hoc basis based on professional judgment. Factors into that judgement include previously receiving repeat late notices, no recent login activity, etc.

ii. Validation Validation activities include the following:

· ‘Real-time’ checks – Before final submission, the transit agency encounters real-time checks coded in Appian SQL syntax and managed by TAD’s IT contractor.

· Ad Hoc Validation – Ad hoc validation occurs after an agency submits their monthly report through Appian. Ad hoc validation involves approximately 20 SQL queries to flag issues. A common ad hoc validation issue is “Explain why your vehicle revenue miles decreased 20% this month?”

· Matching Annual Data – At the end of each agency’s fiscal year, the agency is required to ensure that their annual data totals match their monthly module totals.

iii. Weekly Reference Data Collection The Weekly Reference (WE-20) form collects service data for a single week each month, due three business days later. A stratified random sample of agencies, approximately 400 NTD reporters of various reporter types, will be required to submit their data. These data points would not need to be reconciled against the MR-20, but would require some validation against the prior week of WE-20 data for obvious mistakes (e.g., more than 50% variance from the prior week). The usual validation procedures for the data will apply. These data points for each mode and TOS would be, as an example:

Illustrative Example (July 8 - July 14 Totals) for WE-20 Data Collection:

· Weekday 5-day unlinked passenger trip (UPT) total;

· Weekday 5-day vehicle revenue miles (VRM) total;

· Weekend 2-day unlinked passenger trip (UPT) total;

· Weekend 2-day vehicle revenue miles (VRM) total; and

· Vehicles Operating at Maximum Service (VOMS) total.

4. CLIN 0004: SAFETY AND SECURITY MODULE DATA COLLECTION AND VALIDATION FOR 11/2025 – 10/2026 The tasks associated with this CLIN are: (i) data collection and (ii) validation. The Contractor is responsible for managing all aspects of the NTD’s safety and security (S&S) module. FTA’s S&S module collects data on three different forms: (1) S&S-40; (2) S&S-50; and (3) S&S-60.[footnoteRef:20] [20: There are actually four S&S forms (S&S-20, S&S-30, S&S-40, S&S-50); however, substantive data is collected on the S&S-40 and S&S-50. The S&S-20 and 30 only collection certifications and configurations that support data collection. The S&S-60 collects safety data for reduced reporters.]

i. Data Collection The S&S-40 and S&S-50 Forms are completed by approximately 500 Full Reporters and are not completed by other reporter types.

The S&S-40 Form, or the major event report, is due within 30 days from the date of a reportable event. A reporting agency must submit an S&S-40 form for each qualifying event. The S&S Policy Manual defines several event types that are considered reportable ‘Major Events’ for NTD purposes. Because the S&S-40 is an ad hoc, event-by-event report, the number of monthly reports varies. In a given year, the NTD receives approximately 10,000 S&S-40 reports, covering approximately 50 fields per form or 300,000 total fields of data submitted across all reporters.

The S&S-50 Form, or the non-major event report, is due by the last day of the following month. Non-major events are defined in the S&S Policy Manual. An example of a non-major event is a small fire where no one is hurt severely enough to require medical transport. Two other examples are a slip, trip, or fall, and transit worker assaults where no one is transported to the hospital. Because each Full Reporter submits only one S&S-50 report each month, there are 500 reporters, covering approximately 1,400 modes/types-of-service to collect each month. The S&S-50 form has 76 fields, for approximately 103,000 data fields each month – although many of them will be blank (no data to report) in any given month.

The S&S-60 Form, or safety data form, collects a minimal amount of safety data once per year from a subset of reporting agencies. These agencies fall under the following reporting types: Reduced Reporter, Rural General Public Transit subrecipient, Asset subrecipient, and Reduced Asset. The form captures data on counts of Physical Assaults on Transit Workers, Non-Physical Assaults on Transit Workers, and Other Reportable Safety and Security Events. This form has 76 fields and is collected from 3,000 modes and types of service, resulting in approximately 228,000 S&S fields.

ii. Data Validation FTA requires that the Contractor is responsible for validating all S&S forms. Validation involves performing general validation (similar to other modules) as the specific validation for each form described below.

For the S&S-40, FTA requires that the Contractor manage the logic of real-time (in-system) validation and ad hoc validation. Specifically, the in-system scripts themselves are controlled by TAD, but business requirements are provided by the Contractor. In total, there are approximately 50 fields with validation logic. An example of the logical validation performed is if an incident referred to a total of 10 fatalities, and the breakout categories of different fatalities tallied 7 fatalities, the system would result in an error, as 3 fatalities would be missing. Similar completeness checks occur depending on categorical data selections. For example, reporting a security event will ask a reporter if the event type is a robbery as opposed to a rail collision. FTA requires that the Contractor also performs ad hoc (non-real time) validation using a combination of staff time (internet research) and SQL scripts in the Branch Environment.

For the S&S-50, validation mirrors the S&S-40 with some minor differences. One critical difference is the extent of real-time and ad hoc validation. The S&S-50 has fewer fields, however, validation occurs monthly.

For the S&S-60, like the S&S-50, there are fewer safety and security fields that need to be validated. However, validation for the S&S-60 only occurs once per year—S&S-50 validation occurs once per month.

5. CLIN 0005: DATA PRODUCTS FOR 11/2025 – 10/2026

FTA requires that the Contractor produce and deliver several different data products under this CLIN: (i) Annual Data Products, (ii) Monthly Data Products, (iii) Safety and Security Data Products, (iv) Apportionment files; (v) the National Transit Summaries and Trends; (vi) Transit Agency Profiles, and (vii) Scripts and Documentation.

i. Annual Data Products The Contractor will produce and publish approximately 60 annual data products. Annual data products are produced once per year in the September – October timeframe. Under this statement of work, the first drafts of the annual data products will be due beginning September 2026.

There are five categories of annual data products: (1.1) database files; (1.2) time-series; (1.3) data publications guide; (1.4) internal-only annual data products; and (1.5) Socrata annual files. Descriptions and links to example annual data product are shown below.

1.1 Database Files (30 Files, 1 Time Per Year)

The Contractor is required to produce and publish database files annually in the Fall. Database files are Microsoft Excel files consisting of a single worksheet. They are the least processed data products.