A long document problem with a new computational answer
A typical hydropower EPC tender for a 500-1,000 MW dam project includes a concrete specifications section running to several hundred pages, a contract clauses section running to several hundred more, a Bill of Quantities of similar length, technical drawings numbering in the thousands, and reference standards (IS, ACI, ASTM, FIDIC, ICOLD) running to thousands of pages combined. The Owner’s Engineer reviewing this on the owner’s behalf has historically had two practical options: read every page (slow, expensive, error-prone, and increasingly hard to staff for the level of attention required) or sample selectively (fast, cheaper, but riskier).
The result is well-documented across the industry: critical clauses get missed, inconsistencies between sections get propagated into construction, and disputes that could have been prevented at tender stage become claims and arbitrations during construction. The cost of these downstream issues can run to a significant fraction of project value.
Large language models have created a third option: rapid full-document review with senior engineer validation of any flagged item. The LLM reads the entire document in minutes. The engineer reviews only the items the LLM has flagged. The total review covers more ground, more consistently, faster, than either option alone could achieve.
PCCI’s Owner’s Engineer service methodology incorporates LLM-assisted review where the document volume justifies it. The methodology is grounded in a clear understanding of where LLMs help, where they fail, and what governance discipline is required to use them responsibly on safety-critical infrastructure projects. This article describes how it works.
What LLMs do well, and where they fail, on technical concrete documents
LLMs are useful for specific tasks within tender spec review. They are not useful for all tasks, and the difference matters.
Tasks where LLMs add value
Cross-document consistency checking. A 600-page specification often has the same clause referenced or restated in multiple sections. Inconsistencies between these mentions (different concrete grade, different acceptance criteria, different test references) are common errors that human reviewers miss because they read sections sequentially. LLMs read the whole document at once; they identify inconsistencies routinely.
Standards reference verification. Where the specification cites standards (IS, ACI, ASTM, ICOLD), an LLM with access to the actual standard documents as context can flag clauses where the citation does not match the standard’s actual content. This is exactly the kind of error that produces a contractor claim during construction.
Element-specific completeness checking. A project-specific checklist (mass concrete thermal control clauses, RCC-specific clauses, embedded steel liner contact grouting, second-stage powerhouse concrete, drainage gallery waterstops, et cetera) can be applied by the LLM across the entire specification to flag missing or inadequate clauses. The same exercise done manually takes days; the LLM does it in minutes.
Clause summarisation for engineer review. Long sections summarised in plain language allow the senior engineer to identify items requiring deep review without reading the entire section first. The summary is a navigation aid, not the deliverable.
Translation across project languages. Where projects involve non-English source documents (contractor proposals in Mandarin, supplier specifications in German, reference documents in French), LLM translation provides workable English text that the engineer can review. This was previously a slow human task or a poor-quality machine translation.
Tasks where LLMs fail
Hallucinated standard references. An LLM asked about a standard it does not have direct context for will produce an answer in the same confident tone whether the answer is correct or invented. This is the highest-risk failure mode for technical concrete review. Mitigation: the LLM is provided with the actual standard text as context, and any standard-related claim is verified by the engineer against the source.
Numerical drift. When summarising specifications with multiple numerical thresholds (cement content limits, water-cement ratios, temperature limits, sampling frequencies), the LLM may state an incorrect value confidently. A 0.45 water-cement ratio might be summarised as 0.40 or 0.50 with no signal that the value is wrong. Mitigation: every numerical claim in the LLM output is verified against the source document.
Missing engineering nuance. A clause that requires careful interpretation against a specific dam type, exposure condition, or construction sequence may be summarised generically. The LLM does not have the dam-engineering judgment to recognise that a generic summary misses a project-specific requirement. Mitigation: the senior engineer reviews flagged items in the project context, not in isolation.
False confidence in tone. LLMs present all outputs in the same authoritative tone regardless of the underlying source quality. A clear conclusion from a well-supported source reads identically to a confabulated conclusion. The engineer must treat tone as no signal at all and verify content independently.
Cross-reference following errors. When a specification refers to another section (“see clause 5.3.2 for placement requirements”), the LLM may not faithfully follow the reference, instead producing a plausible-sounding answer that does not reflect the referenced clause. Mitigation: cross-references in the LLM output are verified against the actual referenced text.
The model is a draft generator; the engineer is the verifier
The most defensible posture for LLM-assisted technical review is to treat the LLM output as a draft requiring verification, not as a conclusion. Every claim, every numerical value, every standard reference, every cross-reference is verified by the senior engineer against the source before it informs any recommendation to the project authority. This is slower than treating the LLM output as authoritative, but it is the only posture defensible in a downstream dispute or audit.
How PCCI’s Owner’s Engineer methodology applies LLMs
The application sits at four stages of a typical Owner’s Engineer engagement.
Stage 1: Pre-tender review
When PCCI is engaged at the design and tender preparation stage (the best practice we describe in our Owner’s Engineer scope article), the draft tender concrete specifications go through LLM-assisted review against a project-specific completeness checklist. Items flagged: missing element-specific clauses, internal inconsistencies, references to outdated standards, ambiguous acceptance criteria, gaps in the QA/QC framework.
The senior PCCI engineer reviews each flagged item, validates the LLM’s interpretation, and recommends clause additions, modifications, or clarifications to the project authority. The recommendation is the deliverable. The LLM-flagged list is the working document the engineer uses to focus the review.
Stage 2: Bid evaluation
When tender responses arrive from bidders, LLM-assisted comparison identifies bidders whose proposals deviate from the specifications, contain ambiguous commitments on critical clauses, or reference unfamiliar materials and methods that need verification.
The senior PCCI engineer reviews the LLM’s flagged deviations against the bid documents and the specification. The engineer’s bid evaluation report to the project authority is informed by the deeper review made possible by the initial LLM filtering.
Stage 3: Construction-phase document review
Throughout construction, the contractor submits documents to the Owner’s Engineer for review: mix designs, method statements, NCR records, monthly QA/QC reports, test result summaries, change requests. The volume is significant on a 24-36 month project.
LLM-assisted review identifies inconsistencies between submittals, missing items required by the specification, technical claims that warrant verification, and trends across documents that suggest underlying issues. The senior engineer reviews flagged items, decides what action is required, and produces the response to the contractor or recommendation to the project authority.
Stage 4: Documentation and reporting
PCCI’s Owner’s Engineer engagements produce monthly progress reports, periodic quality reports, and event-driven technical reports. LLM assistance accelerates the drafting of these documents, with the senior engineer validating every technical claim and approving the final version. The contractually binding deliverable is the engineer-validated report; the LLM-drafted version is internal working material.
The governance framework
PCCI’s methodology for LLM use in the Owner’s Engineer service aligns with the principles in the NIST AI Risk Management Framework: govern, map, measure, manage. The framework is generic; the project-specific application has four components.
| Principle | Application in PCCI’s methodology |
|---|---|
| Govern | Written protocols for which tasks LLMs are used on, which they are not used on, and what verification is required at each stage |
| Map | Identification of failure modes specific to technical concrete documents (hallucinated standards, numerical drift, missing nuance, false confidence, cross-reference errors), and the specific verification required for each |
| Measure | Tracking of the LLM output validation rate, that is, how often the engineer’s verification finds errors in the LLM output. The rate informs whether the LLM tool remains in active use on a project |
| Manage | Human-in-the-loop discipline at every stage. The senior engineer has the final say on any contractually or technically binding output |
The validation rate metric matters. If the engineer’s review finds errors in 5 percent of LLM outputs, the tool is genuinely useful and the verification overhead is justified by the speed gain. If the validation rate is 30 percent, the tool is not adding value because the engineer is doing more work to verify the LLM than to do the task without it. PCCI’s methodology requires the validation rate to be tracked and the tool to be retired or reconfigured if the rate climbs.
The Owner's Engineer is what the project pays for
The contractually binding deliverable in any Owner's Engineer engagement is the senior engineer's review, recommendation, and certification. The LLM is internal working tool that accelerates the engineer's coverage of long documents. The owner is paying for the engineer's judgment, not for an LLM output. PCCI's methodology keeps this distinction clear at every stage of the engagement.
What this means for owners specifying an Owner’s Engineer scope
For PSU and EPC owners writing the Owner’s Engineer scope of work for a new hydropower project, the implications are practical:
- The Owner’s Engineer should be specified as the entity producing the binding review, with internal tools (including LLMs) used at the firm’s discretion to deliver the review efficiently.
- The scope should not require or prohibit LLM use; it should require the deliverables and the verification framework, and trust the consulting firm to use appropriate tools.
- Any project-specific data handling restrictions (confidential project information, security clearance requirements, data residency) should be specified, and the consulting firm should confirm its LLM tool selection complies with these.
- The validation rate metric is internal to the consulting firm’s methodology and is not typically a contract deliverable; it is part of the firm’s quality system.
This is consistent with how Owner’s Engineer engagements have always handled internal tools: the firm uses what works, the deliverable is what the contract specifies, the firm is responsible for the deliverable quality.
How PCCI applies this in practice
PCCI’s Owner’s Engineer service operates on dam projects across the 4,000+ MW portfolio, including Punatsangchhu-1 (1,200 MW) where PCCI’s leadership prepared the comprehensive QC manual that defined the quality framework for the concrete program, Mangdechhu (720 MW), and Tanahu (140 MW), an ADB and JICA co-financed project where ACI and ASTM-aligned consulting was provided. The methodology described here is part of how the Owner’s Engineer service operates in 2026: senior engineer review as the binding deliverable, LLM tools as accelerators where appropriate, governance framework aligned with the NIST AI RMF, and verification of every LLM-derived claim before it informs any recommendation.
Book a Technical Call → to discuss how PCCI’s Owner’s Engineer service can be applied to your project.
