RAG Transit Planning Report

AI-synthesized note. This report is the reconciled output of a multi-agent analysis of the source PDF (see the Subagent Reconciliation section below), not a hand-authored note — treat the quantitative claims as source-dependent.

Source: IFP, "Use AI to Improve Transit Planning," June 17, 2026. Page references use the PDF's own 1/9 through 9/9 numbering.

Concept focus: using retrieval-augmented generation (RAG) to turn scattered transit planning and construction documents into agency institutional knowledge.

Source note: the PDF has an attribution inconsistency. Page 1 lists Santi Ruiz under the title, while the page 5 title graphic and page 9 bios identify Elizabeth/Lizzie Speed and Bennett Capozzi. This report treats the PDF as the source and flags the inconsistency rather than resolving it.

Executive Summary

The paper argues that the Federal Transit Administration (FTA) should create a centralized repository of past transit planning and construction documents, then provide an LLM-backed interface that transit agency staff can query. The core idea is not "AI for everything." It is narrower and more useful: use RAG to retrieve, summarize, and cite lessons from PMOC reports, risk analyses, environmental documents, Full Funding Grant Agreements, utility coordination records, zoning materials, and other planning data (pp. 1, 4, 6-8).

The problem diagnosis has three parts. First, many US transit agencies rely heavily on consultants, which the paper argues raises costs and prevents agency staff from building durable expertise (p. 2). Second, transit construction is delayed by data limitations, especially inaccurate or fragmented utility and subsurface documentation (p. 3). Third, federally funded projects already produce many reports, but those reports are dispersed, often PDF-formatted, and hard to mine for lessons across projects (p. 3).

The proposed solution has two parts: a standardized federal report repository, and a queryable AI platform grounded in that repository (p. 4). The key learning concept is RAG as an institutional-memory system: retrieve from authoritative documents, generate a usable answer, cite the source passages, and let staff verify the output (p. 6).

The evidence is mostly illustrative and policy-argument evidence, not experimental evidence. The paper gives cost examples, precedent platforms, and plausible use cases, but it does not provide a pilot evaluation, cost-benefit model, implementation timeline, procurement estimate, security model, or formal AI reliability metrics.

Subagent Reconciliation

The three subagents agreed on the main picture:

• This is a policy proposal in IFP's Transit Abundance Playbook, not a formal academic research paper.
• The contribution is a program design: FTA should build a centralized data repository plus a RAG/LLM platform for transit planning and construction.
• The strongest sections are the problem framing, use cases, and implementation sketch.
• The weakest sections are causal benefit claims: reduced costs, reduced consultant reliance, and fewer delays are plausible but not directly demonstrated.
• The PDF contains no labeled figures, no charts, and no tables; the only substantive image is an unlabeled page 5 hero graphic.

No substantive disagreement emerged. The main synthesis decision here is to treat the paper's "method" as a policy design and implementation argument, not as an empirical research design.

Glossary

Paper Walkthrough

Summary

What the paper claims: moving more planning functions in-house can reduce transit project costs, and FTA should support that shift by building a centralized repository plus AI-backed platform (p. 1).

My interpretation: the real concept is not simply "add AI." It is "make past project records legible and reusable, then give staff a searchable interface with citations."

Problem

The paper says FTA already supports operational technology tools such as GTFS/GTFSEd, STOPS, and NTD reporting, but agencies lack comparable tools for planning and construction (pp. 1-2). It identifies three cost generators: consultant overreliance, construction delays from data limitations, and limited access to insights from past projects (p. 2).

Evidence cited:

• Heavy consultant use allegedly raised costs for projects such as New York City's Second Avenue Subway and Boston's Green Line Extension by 10% (p. 2).
• Second Avenue Subway project management and design contracts were 21% of construction costs, compared with a typical 7-8% range in France (p. 2).
• Inaccurate Second Avenue Subway ground-condition documentation allegedly led to ground freezing and an added $27.9M cost (p. 3).
• Every month of delay on Boston's Green Line Extension after construction started allegedly cost $1-2M (p. 3).
• A commonly cited utility-identification statistic says every $1 spent early saves $4.62 later (p. 3).

Verification caution: these are external claims summarized by the paper. The PDF does not reproduce the underlying studies, interview transcripts, or estimation methods.

Solution

The paper proposes a two-part solution: a centralized report repository and an LLM-powered platform that lets agency staff query the repository (p. 4). Use cases include:

• planning and alternatives analysis;
• NEPA procedure and risk assessment;
• grant applications and FFGAs;
• construction monitoring (p. 4).

The paper explicitly says the platform should link to specific source reports and documents (p. 4). That source-link requirement is one of the proposal's most important design constraints.

Precedents

The paper gives three precedents:

• FDA's Elsa, described as an AI tool for reading, writing, summarizing, scientific evaluation, and inspection prioritization (p. 5);
• Advana, described as a data platform that standardizes access to many sources and automates internal review (p. 5);
• a Caltrans/UCLA prototype that reportedly ingested roughly 12,000 pages of PMOC reports plus SANDAG quarterly updates and board materials for a San Diego trolley extension (p. 5).

My interpretation: these are analogy cases, not direct evidence that the proposed FTA platform would reduce transit project costs. The Caltrans/UCLA prototype is the closest precedent because it involves transit project documents.

Potential Data Sources

Initial sources include PMOC reports, risk analyses, Environmental Impact Statements, FFGAs, and other transit project documents already submitted to or created around FTA-funded projects (p. 6).

Future expansions could include EPA and Army Corps records, state/local utility records, zoning and land-use documents, agency charters, Metropolitan Planning Organization reports, private data, and National Zoning Atlas data (p. 6).

My interpretation: the platform's value depends less on the model and more on data quality, coverage, rights, metadata, and standardization. The paper names the right categories but does not fully specify the data-governance work.

Implementation

The paper suggests a RAG implementation. It explains that a RAG system retrieves from a curated set of documents rather than relying only on model training data, which can reduce hallucination risk and enable source citations (p. 6).

My interpretation: RAG is the right architectural family for this proposal, but RAG does not automatically make answers safe or correct. The implementation would need retrieval evaluation, citation verification, document-quality controls, access controls, and workflows for users to challenge or correct outputs.

Building and Managing the Platform

The paper recommends assigning a single internal FTA owner with technical expertise to manage collaboration with a consulting firm, technology company, or academic institution (p. 7). It also calls for sourcing reports and data across FTA/USDOT, performing comprehensive testing, monitoring uptime and performance, soliciting feedback, creating a common data model, and forming a planner working group to identify needed data (p. 7).

My interpretation: this is the most operational section. The missing layer is a phased rollout plan: pilot corpus, pilot agencies, evaluation metrics, procurement path, privacy/security review, and maintenance budget.

Platform Benefits

The paper claims the platform could:

• curb reliance on consultants by making past project knowledge easier for agency staff to use (p. 7);
• preempt construction delays by surfacing risks from comparable projects and, later, integrating local data such as utility and zoning information (pp. 7-8);
• centralize data management through a "buy once, use many" strategy (p. 8).

Verification caution: these are projected benefits. The PDF does not estimate adoption rates, staff time saved, consultant work actually substitutable, delay-reduction probabilities, or net program cost.

Legislative and Administrative Pathways

The paper recommends creating a National Transit Planning Data & AI Program in the Surface Reauthorization Bill (p. 8). It proposes:

• amending 49 U.S.C. 5335 so NTD includes project lifecycle data;
• authorizing a National Transit Planning Data and Analytics Program under 49 U.S.C. 5312;
• assigning a clear owner such as FTA's Office of Research, Demonstration, and Innovation, FTA CIO, or USDOT Chief AI Officer (p. 8).

My interpretation: this section gives the proposal a plausible federal policy vehicle, but statutory fit, appropriations, procurement authority, and data-sharing constraints would need legal review.

Concept Map

Method Diagram

Evidence Table

Figures, Tables, and Visual Claims

The PDF contains no labeled figures, tables, charts, equations, or formal notation.

Visual inventory:

Because there are no data visuals, the report's quantitative claims must be evaluated from the cited prose and underlying external sources, not from charts in the PDF.

Claims vs Interpretation

Caveats

• The paper is a policy proposal, not a peer-reviewed study or technical evaluation.
• It has no formal experiments, no pilot results for the proposed national platform, and no quantitative cost-benefit model.
• It does not specify AI evaluation metrics such as retrieval recall, citation precision, grounded answer accuracy, hallucination rate, user task success, or time saved.
• It under-specifies data governance: document permissions, local utility-data sensitivity, private-provider licenses, update cadence, access control, retention, and correction workflows.
• It under-specifies engineering constraints: OCR quality, metadata extraction, duplicate/conflicting reports, geospatial data integration, data model design, uptime, logging, and security.
• It under-specifies human workflow: who is trained, which consultant tasks are actually replaced, how outputs are reviewed, and who is liable if AI-supported guidance is wrong.
• Several important claims depend on external sources not reproduced in the PDF: the 10% consultant-cost claim, 21% vs 7-8% soft-cost comparison, $27.9M ground-freezing claim, $1-2M/month delay cost, $4.62 utility-identification savings statistic, FDA Elsa performance, Advana details, and Caltrans/UCLA prototype details.
• The attribution inconsistency should be fixed before the PDF is cited in a formal setting.

Missing Background and Assumptions

To fully understand and evaluate the proposal, you need background in:

• FTA project lifecycle: Capital Investment Grants, PMOC oversight, FFGAs, risk analysis, and grant closeout.
• Transit planning workflows: alternatives analysis, station design, alignment decisions, public engagement, ridership forecasting, and construction sequencing.
• Environmental review: NEPA, EIS preparation, mitigation plans, and how environmental documents interact with project delivery.
• Utility and subsurface risk: utility mapping, relocation, geotechnical baseline reports, ground freezing, change orders, and claims.
• Data architecture: document repositories, OCR, metadata extraction, common data models, geospatial joins, access control, and audit logs.
• RAG evaluation: retrieval quality, answer faithfulness, citation correctness, hallucination, incomplete-corpus risk, and human-in-the-loop review.
• Public procurement and governance: federal IT procurement, data-sharing agreements, local data rights, cybersecurity review, and program authorization.

Follow-Up Reading

Start with:

• FTA documentation on Capital Investment Grants, PMOC oversight, FFGAs, STOPS, GTFS/GTFSEd, and the National Transit Database.
• A NEPA/EIS primer focused on transportation projects.
• Practical material on utility coordination, subsurface utility engineering, and geotechnical baseline reports.
• RAG system evaluation guides covering retrieval recall, answer faithfulness, citation accuracy, and human review.
• The playbook pieces the PDF footnotes cite: Paul Lewis on consultant overuse and Philip Plotch on transit construction lessons (p. 9).
• Case studies on Second Avenue Subway, Boston Green Line Extension, and the San Diego trolley extension if you want to test the proposal's examples.

Open Questions

1. Which specific planning tasks would the platform replace, accelerate, or merely support?
2. What percentage of consultant spend is actually substitutable by better document search and in-house staff tooling?
3. What corpus would the first pilot include, and how complete/clean are those documents?
4. How would the system handle contradictory reports, outdated assumptions, poor OCR, missing metadata, and project-specific context?
5. What AI evaluation metrics would FTA require before staff or grantees rely on the platform?
6. How would the platform protect sensitive utility, security, property, procurement, or legal information?
7. Would local agencies be required to submit new project lifecycle data, or merely encouraged?
8. Who owns errors: FTA, the software vendor, the local agency, or the staff member using the output?
9. Can the Caltrans/UCLA prototype be evaluated with real users, measured time savings, answer-quality benchmarks, and documented failure cases?
10. What would a minimum viable national pilot cost, and what project-delivery savings would justify it?

One-Sentence Takeaway

The concept to learn is RAG as public-sector institutional memory: a system that makes scattered transit project records searchable, citable, and reusable so agencies can learn from past projects without treating the AI itself as the source of truth.

Related

• LLM Wiki — the other end of the same problem. Where RAG retrieves per question and keeps nothing, a second brain does the synthesis once and writes it down. The comparison table there is the clearest statement of the tradeoff this paper implicitly accepts.
• Building an AI-First Bank Culture — the private-sector mirror: JPMorgan names knowledge management an emerging job family for exactly the reason this paper argues FTA needs a repository.
• AI-Augmented Software Engineering — on why designing retrieval pipelines is becoming its own discipline, and why context quality, not model quality, is the binding constraint.