Construction project documentation: AI on the building site

Construction is one of the most document-intensive industries operating today, and one of the most fragmented. Every project produces an enormous volume of documentation — requests for information (RFIs), submittals from subcontractors, change orders, daily reports from the site, safety inspection records, punch lists, contractor coordination memos, owner communications. The volume scales with project complexity and project count, and the documentation has real consequences: change orders drive cost; RFIs drive schedule; safety records drive liability.

AI has been integrated into construction documentation workflows fast in the past three years. The bill is real and growing. The data is competitively sensitive in specific ways. And the deployment realities of construction sites favor local inference more strongly than most office workflows.

The work

Construction AI workloads include:

RFI processing: contractors submit RFIs to clarify design details. AI helps draft responses, route them to the right parties, and identify when an RFI is signaling a deeper issue (a design conflict, a constructability problem, a scope ambiguity).

Submittal review: subcontractors submit shop drawings, product data sheets, and samples for approval. AI helps review submittals against the spec, identify deviations, and draft review comments.

Change order management: cost and schedule changes are negotiated through change orders. AI helps draft change order documentation, analyze cost impact, and identify patterns across change order history.

Daily reports: site superintendents produce daily reports describing the work performed, the weather, the crew counts, and any incidents. AI helps draft these from voice notes, photos, and structured input.

Safety documentation: incident reports, near-miss tracking, JSA (job safety analyses), toolbox talks. The volume is large at any active jobsite and the documentation has legal significance.

Punch lists and closeout: identifying and tracking the final list of items needed to close out a project. AI helps generate, categorize, and track punch lists.

Contract and spec analysis: parsing the contract and the specifications to identify obligations, risks, and ambiguities. The documents are long and dense; AI helps make them navigable.

The math

A representative midsize general contractor works on perhaps fifteen to thirty active projects at any given time, with project values ranging from a few million to a few hundred million dollars. Each project generates hundreds to thousands of documents over its lifecycle.

Aggregate documentation volume across the firm is in the tens of thousands of items per month. Each item involves multiple AI operations: classification, summarization, routing, response drafting, comparison against precedent.

A reasonable per-operation token budget is in the range of $0.02 to $0.05, weighted by document complexity. The aggregate bill is in the low to mid five figures per year for a midsize GC, scaling to the low six figures for a large GC or a major specialty contractor.

For very large construction companies — top ENR firms with global operations — the bill scales further. The largest construction firms are at six to seven figures per year for the AI documentation layer alone.

These numbers exclude the project management software, the building information modeling (BIM) tools, the cost estimation systems. The AI augmentation layer on top is the line item we're examining.

Why construction is structurally a local-SLM case

The properties for local-SLM suitability are present, with several that are unusually strong in the construction context.

The work is narrow within each project. A model fine-tuned on the firm's project history, contract templates, and specification patterns outperforms a general model on the firm's specific work.

The work is repetitive in structure. RFIs follow predictable formats. Daily reports follow predictable templates. Change orders follow predictable structures. Specialization compounds.

The privacy and competitive intelligence story is real. Project documentation reveals project costs, schedule challenges, subcontractor relationships, design issues, and dispute patterns. For competitive contractors, this is intelligence about their cost structure, their risk patterns, and their operational maturity. Sending all of it to a third-party cloud LLM creates competitive intelligence exposure.

The owner confidentiality story matters too. General contractors work on projects whose details are often confidential to the owner. Healthcare facility construction, government facilities, corporate offices, and many other project types have confidentiality requirements that constrain how project data can be handled.

The site deployment realities matter. Construction sites often have poor connectivity. Field personnel use tablets and phones in environments where mobile data is unreliable. A cloud-LLM workflow that depends on a reliable round trip fails on a jobsite; a local-SLM workflow that runs on a site server or on edge devices works regardless of connectivity.

The latency story matters when a superintendent or a project manager needs information quickly. A two-second cloud round trip in a field environment is often longer; a local inference happens in milliseconds.

What changes with local inference

A construction AI workflow on a local SLM looks like this.

A model is fine-tuned on the contractor's project corpus — historical RFIs, submittals, change orders, daily reports, contracts, specifications. The fine-tune captures the firm's specific document patterns and the patterns of its typical work.

The model deploys on the firm's infrastructure — typically in the project management environment, with edge deployments at active jobsites where field connectivity is poor.

Documentation flows through the inference pipeline. The model produces classifications, summaries, drafts, and analyses. The work integrates with the existing project management software, the document control systems, and the BIM environment.

The cost flips from per-document to fixed. Project volume can grow with the firm's business.

The competitive intelligence stays inside. The accumulated knowledge of the firm's project patterns, cost structures, and operational mediocrities-and-strengths remains the firm's asset.

The owner confidentiality is respected. Project data doesn't cross to third-party providers.

The fragmentation opportunity

Construction is fragmented in a specific way that matters for vendor strategy.

The largest GCs build their own software stacks or contract with specialty vendors for major systems. Mid-sized GCs use industry-standard platforms (Procore, Autodesk Construction Cloud, BIM 360, and others). Small GCs and specialty contractors use a long tail of simpler tools.

A category-defining local-SLM construction tool would need to integrate with the dominant project management platforms (so it slots into existing workflows), support easy deployment for small operators (no ML team required), and produce credible work product across the long tail of project types.

Several vendors are building in this space. The category leader hasn't emerged yet, and there's significant room for vendor activity that combines local-inference architecture with deep construction-domain fine-tuning.

Where the cloud LLM is still acceptable

A few cases.

For very small contractors — owner-operator or small specialty contractors — where the infrastructure investment doesn't pay back at small scale.

For one-off project analyses or research workflows where the work doesn't recur.

For preconstruction and bidding workflows that operate on public information (bid documents, public solicitations) without crossing into the firm's competitive intelligence.

For the bulk of construction documentation work at any midsize-to-large contractor — the recurring project management work that constitutes most of how the firm operates — the local-SLM case is strong on cost, on privacy, and on site deployment.

The pattern, on the build site

Avery NXR scaffolds Next.js applications. It is not a construction tool. The architectural pattern repeats.

Construction documentation is a narrow, repetitive, high-volume, competitively-sensitive, deployment-challenged workload. The economics that favor a specialized local model for code scaffolding favor a specialized local model for construction. The deployment realities of jobsites strengthen the case beyond what cost alone would justify.

The construction tech vendors that build local-inference tools — with appropriate fine-tuning, integration with the major construction platforms, and deployment options that work in field environments — will find willing buyers across the industry. The cloud-LLM-default tools will hold parts of the market but face structural friction with how construction actually operates.

The pattern continues. Construction is one of the workflows where the local-SLM case is supported by multiple factors at once — cost, privacy, operational fit — making the architectural shift feel less like a debate and more like an obvious match to how the work actually gets done.