When a Preliminary Engineering Report comes back with deficiency comments, the instinct is to assume the engineering was wrong. Usually, it wasn't. The reviewers flagged how the analysis was presented— not the analysis itself. That distinction is what separates a funded project from a third revision cycle.
Getting a deficiency letter is not failure. It's the documented revision cycle for infrastructure funding applications. USDA Rural Development, state revolving fund programs, and similar agencies send PERs back when the written alternatives justification doesn't give reviewers a clear path from the LCCA data to the preferred alternative— even when the underlying engineering is sound.
On the third draft of one such PER, something different happened. A project team at a mid-size civil engineering firm didn't add more sections or rerun their calculations. They changed how they approached the revision— starting from the reviewer's language instead of their own. That shift is what this article is about, and understanding how AI fits into technical engineering workflows is part of what makes it repeatable.
What USDA Reviewers Are Actually Evaluating
USDA Rural Development requires a completed Preliminary Engineering Report before approving Water and Waste Disposal program funding for rural water and wastewater projects. The PER isn't a formality— it's the document the reviewer uses to decide whether the preferred alternative is justified. USDA RUS Bulletin 1780-2 is the standard PER template accepted by multiple state and federal funding agencies1, meaning a well-prepared PER generally doesn't require amendment to meet different program requirements.
The Bulletin is explicit about what the document must accomplish. Per USDA RUS Bulletin 1780-21: "The Report should identify alternatives, present a life cycle cost analysis of technically feasible alternatives and propose a specific course of action."
Life Cycle Cost Analysis (LCCA) is the required analytical framework for every PER alternatives analysis, using the formula: Capital costs + O&M − Salvage value. Every feasible alternative must be analyzed. The preferred alternative must be justified with engineering AND operational reasoning— not just the lowest LCCA result.
Non-monetary factors are also explicitly valid evaluation criteria under the Bulletin1:
- Sustainability considerations and non-monetizable resilience benefits
- Greenhouse gas emission reductions
- Community objections and operator training requirements
- Wetland relocation and environmental considerations
- Domestic preference requirements
These factors need to be documented in the PER, not just mentioned. That's the level of specificity reviewers are working from — which is why a technically correct LCCA isn't enough if the narrative doesn't connect each factor to the preferred alternative recommendation. Reviewers also evaluate demand analysis, rate impacts on users, future financial needs, and a complete implementation plan, per Commonwealth Engineers2. And per Morrison-Maierle3, a realistic PER development period spans 9–12 months, including two public hearings and environmental agency reviews.
Where Draft 1 and Draft 2 Usually Fall Short
The most common reason a PER comes back with deficiency comments isn't a flawed LCCA or a missing environmental section. It's insufficient justification for the preferred alternative— meaning the analysis is there, but the written narrative doesn't clearly connect the results to the recommendation.
As McWane Ductile documents4: "Rejection of a proposed alternative is made due to insufficient justification of the proposed alternative or rejection of available alternatives." The burden is on the designer to justify with sound engineering and operational data. Not on the reviewer to read between the lines.
Draft 1 typically gets the engineering right. The LCCA tables are correct, the alternatives are real, and the environmental section is complete. But the written narrative reads like a checklist— each section standing on its own without building toward the preferred alternative.
Draft 2 usually makes it worse in a specific way. The team reads the deficiency comments, adds more data, adds more pages, and resubmits. More of the same structure doesn't solve a structural problem. The engineer knows why Alternative B is the right choice. The reviewer is still waiting for the document to tell them.
There's a useful framing for why this cycle repeats: you can't read the label from inside the bottle. After months of fieldwork, stakeholder interviews, and LCCA modeling, the engineer knows the reasoning intimately— and that familiarity makes it genuinely hard to see why the document still isn't landing. What looks obvious from the inside isn't legible from the outside. That gap is exactly what the third-draft approach addresses.
What Changed on Draft 3: The AI Revision Workflow
The shift wasn't in the engineering— the LCCA was already correct. The shift was in how the revision was approached: instead of rewriting from the engineer's perspective, the revision started from the reviewer's language.
Here's the four-step workflow that worked on draft 3.
- Feed the deficiency letter in as-is. The reviewer's exact language— not a summary of it— went into Claude alongside the relevant PER sections. The specific sentences where the deficiency appeared, verbatim.
- Ask the right question. Not "rewrite this section." The question: where does this document lose the connection between the LCCA results and the recommendation for the preferred alternative? Find those gaps.
- Review the structural diagnosis. The AI surfaced three to five specific places where the logic broke down— where analysis ended and the preferred alternative reasoning began without a bridge. The engineer reviewed each one. Is this a real gap? Is this what the reviewer was flagging?
- The engineer makes the calls. For each diagnosed gap, the engineer decided what additional LCCA context to include, what language to revise, and how to frame the transition from data to recommendation. Technical content stayed engineer-owned throughout.
The result: a restructured alternatives narrative that addressed the deficiency comments directly, written in the engineer's voice with the engineer's data. Technical SMEs using AI-assisted processes like this see up to 45% time savings on proposal and report revision work, according to Full Sail Partners5.
What this workflow is NOT: AI generating the LCCA. AI inventing cost estimates. AI writing the engineering recommendation. AI-powered proposal development can accelerate the drafting process significantly6, but every technical claim in a PER must originate from a licensed engineer. The AI's role was diagnostic— identifying where the narrative broke down, not determining what the right answer was.
The reviewer's deficiency letter, it turns out, is the highest-quality brief you'll ever get. It tells you exactly what the document failed to communicate.
Where AI Belongs in a PER — and Where It Doesn't
AI belongs in the narrative layer of a PER— structure, clarity, transitions, connecting analysis to recommendations. It does not belong in the technical layer— LCCA calculations, demand figures, cost estimates, design criteria. That line is not advisory. In a government-reviewed compliance document, crossing it creates liability.
42% of AEC proposal professionals cite hallucination as their top concern with AI5— fabricated case studies, false compliance claims, invented statistics. In a USDA-reviewed PER, a hallucinated cost figure is a deficiency letter waiting to happen.
| Where AI helps in a PER | Where AI stops |
|---|---|
| Restructures the alternatives narrative | Generates LCCA calculations |
| Identifies where logic breaks down | Invents demand figures or cost estimates |
| Improves transitions from analysis to recommendation | Writes engineering conclusions |
| Flags stale or vague language | Produces design criteria |
| Generates cleaner framing for first drafts | Makes the technical judgment call |
Human review of all technical claims is non-negotiable. Every quantitative figure, compliance statement, and engineering finding must be verified by a licensed engineer before submission. As Usman Shuja, CEO of Bluebeam, put it7: "The question now isn't whether AI works— it's how to integrate it effectively." For compliance-critical technical documents, that integration means keeping AI in the narrative layer.
For AEC firms working through managing AI risk in compliance-sensitive technical workflows, this table is the starting framework. And if you want context on what goes wrong when AI isn't used with the right guardrails, the failure modes in government-reviewed documents are worth understanding before you encounter them.
AI is intellectual augmentation, not engineering replacement. The distinction matters most in documents where the reviewer's job is to verify your data.
The AEC Industry Is Starting to Move — But Most Firms Haven't Yet
Only 27% of AEC firms currently use AI tools, according to a 2025 Bluebeam survey of more than 1,000 AEC technology decision-makers7. Among the early adopters, 68% saved at least $50,0007. 46% reclaimed 500 to 1,000 hours7. The firms that got there first have a real advantage.
The move is coming faster than most expect. Nearly 75% of AEC firms are already using or planning to use AI in business development within the next year8. But the PER-specific opportunity is almost entirely unclaimed: using AI in compliance-critical infrastructure funding documents where no competitor content exists.
Integrating AI across your project teams is where most firms start. But integrating it into the technical report revision workflow, where deficiency cycles create real time pressure, is where the repeatable advantage lives.
The pattern shows up in adjacent domains. Fielding Jezreel is a federal grant writer with a decade of experience navigating the same government compliance review cycle. He spent most of 2024 buying and refunding multiple AI tools. His assessment in October 2024: "I don't get it, it's not doing what I need." He worked through a structured implementation process and built five AI-powered tools for his grant-writing practice. Same domain complexity, same compliance stakes. The skepticism was valid— the tools just needed to be applied to the right layer of the work.
FAQ
What is a PER in construction?
A Preliminary Engineering Report is a technical planning document required by infrastructure funding agencies— including USDA Rural Development and state revolving fund programs— before approving construction grants for water, wastewater, and related infrastructure projects. Per USDA RUS Bulletin 1780-21, it analyzes project alternatives using life cycle cost analysis and justifies the recommended course of action. The Bulletin is the standard PER template accepted by multiple state and federal agencies, so a well-prepared PER typically doesn't need to be amended for different programs.
Why did my PER get rejected?
Most PER deficiency letters cite insufficient justification for the preferred alternative. As McWane Ductile documents4, the engineering data exists but the written narrative doesn't clearly connect the LCCA results to the recommendation. Reviewers need the document to show the reasoning— not just present the numbers. Adding more data in the next draft without fixing the narrative structure usually doesn't resolve it.
Can AI write a PER?
AI can help structure and improve the narrative sections of a PER— clarifying transitions, identifying where the logic breaks down, and framing the alternatives justification more clearly. All technical content (LCCA calculations, demand analysis, cost estimates, design criteria) must come from licensed engineers. 42% of AEC proposal professionals cite AI hallucination as their top concern5: in compliance documents, fabricated technical data creates real liability.
How long does a PER take?
A realistic PER development timeline is 9 to 12 months, according to Morrison-Maierle3. This includes two public hearings, environmental agency review, and coordination with funding agencies. The revision cycle after a deficiency letter adds time— which is why a clear alternatives narrative on the first submission matters.
What do USDA reviewers look for in a PER?
USDA reviewers evaluate life cycle cost analysis of feasible alternatives, clear justification for the preferred alternative, demand analysis, financial standing of the community, sustainability documentation, and implementation plan. Per USDA RUS Bulletin 1780-21, non-monetary factors— including greenhouse gas emissions, community objections, and wetland considerations— are also explicitly valid evaluation criteria.
What Changed on Draft 3 — And Why It Works
The preliminary engineering report that got funded on the third draft wasn't rewritten. It was clarified. The engineering was always there— the revision made the reviewer's path through it obvious.
The workflow is repeatable. Feed the reviewer's exact deficiency language into the AI alongside the relevant sections. Ask where the narrative loses the connection between the analysis and the preferred alternative. Review the diagnosis. Make the judgment calls as the engineer. Revise. Submit.
AI doesn't change what a good PER requires. It changes how efficiently you can present what you already have.
If you're evaluating how AI fits into your firm's technical report process, start with an AI decision framework for your firm to clarify where it belongs. And if you want help mapping that to your specific workflows, Dan Cumberland Labs works with AEC firms on exactly this kind of implementation— keeping the right things human while using AI where it actually helps.
References
- USDA Rural Utilities Service, "Preliminary Engineering Reports for the Water and Waste Disposal Programs — Bulletin 1780-2" (2012) — https://www.rd.usda.gov/files/UWP_Bulletin_1780-2.pdf
- Commonwealth Engineers, "Preliminary Engineering Reports" (2024) — https://commonwealthengineers.com/preliminary-engineering-reports/
- Morrison-Maierle, "How to Prepare a Preliminary Engineering Report" (2024) — https://m-m.net/insights/how-to-prepare-a-preliminary-engineering-report/
- McWane Ductile, "Using the Preliminary Engineering Report (PER) in Funding Requests" (2024) — https://www.mcwaneductile.com/blog/using-the-preliminary-engineering-report-per-in-funding-requests/
- Full Sail Partners / Shred.ai, "AI Assisted Proposal Writing Clears the Way for Creativity in AEC" (2025) — https://www.fullsailpartners.com/fspblog/ai-assisted-proposal-writing-clears-the-way-for-creativity-in-aec
- AEC Business / Unanet, "AI Strategies for Smarter Proposal Writing in AEC" (2025) — https://aec-business.com/ai-strategies-for-smarter-proposal-writing-in-aec/
- Bluebeam, "New Bluebeam Report Shows Early AI Adopters in AEC Seeing Significant ROI Despite Uneven Adoption" (2025) — https://press.bluebeam.com/2025/10/new-bluebeam-report-shows-early-ai-adopters-in-aec-seeing-significant-roi-despite-uneven-adoption/
- Unanet, "How AI Helps AEC Firms Win More Work with Less Effort" (2025) — https://unanet.com/blog/how-ai-helps-aec-firms-win-more-work-with-less-effort
