top of page


An examination of a $30 million institutional construction project raises an important question: how many costly changes could have been identified before construction began?


By John Burton, CEO and Co-Founder, Core Runway


A $30 million institutional construction project ultimately generated nearly $3 million in change orders.


That's approximately 10% of the original construction budget.


Some changes during construction are inevitable. Building owners revise their requirements, unexpected site conditions emerge, and projects evolve. But other changes arise from issues that were already present in the design documentation before the first contractor arrived on site.


A missing specification. A conflict between an engineering drawing and an institutional design standard. An equipment requirement that was never incorporated into the project documents.


These are precisely the problems that more systematic design review could identify earlier.


At Core Runway, we've been examining the change-order history of a completed institutional project to explore a straightforward question:


How many of these changes might have been avoided if the project's design documentation had been systematically checked against the owner's requirements before construction began?


The Problem Isn't a Lack of Documentation


Large institutional construction projects generate enormous volumes of technical documentation.


A university building might involve:


  • Thousands of pages of architectural and engineering specifications.

  • Hundreds of drawings covering multiple disciplines.

  • Institutional design standards developed over decades.

  • Building codes, regulatory requirements, and referenced technical standards.

  • Thousands of product requirements and construction decisions.


Each document may be individually correct while the overall project contains inconsistencies.


An electrical drawing might specify equipment that conflicts with an owner's engineering standards. A mechanical specification might omit a required component.


A product might satisfy a manufacturer's published requirements without satisfying the institution's particular requirements.


These discrepancies are difficult to identify because the relevant information is distributed across different documents, sometimes thousands of pages apart.

And as designs evolve, the problem gets harder.


Not All Change Orders Are Preventable


It's important to distinguish between changes that could reasonably have been identified during design and those that could not.


In our analysis, we're separating change orders into several categories:


Change-order cause

Potential for earlier detection

Conflicts with owner design standards

High

Missing specification requirements

High

Conflicting drawings and specifications

High

Missing or incorrect equipment requirements

High

Incomplete design details

Moderate to high

Unforeseen site conditions

Generally low

Owner-requested scope changes

Generally low

Market-driven price changes

Low

These are preliminary classifications, not measured prevention rates.


The distinction matters. AI shouldn't be credited with preventing changes that were unavoidable or outside the scope of the documentation available for review.


But when a change results from a requirement that was already documented and simply wasn't incorporated into the design, there's a compelling argument for identifying that issue earlier.


What Would Even a Modest Improvement Be Worth?


Consider the economics of our $30 million project.


Illustrative savings scenarios

Share of change-order costs avoided

Potential savings

10%

$300,000

20%

$600,000

30%

$900,000

40%

$1,200,000


These figures are scenarios, not demonstrated savings. Actual avoidable costs depend on the reasons for each change order, the documentation available at the time, and whether earlier detection would have eliminated or simply reduced the cost.


Nevertheless, the financial implications are significant.


Even preventing a relatively small percentage of avoidable changes could justify investment in more comprehensive design compliance checking.


And these calculations don't capture every possible benefit of early detection, such as reduced disruption, fewer clarification requests, or improvements in project scheduling.


Why Traditional Design Reviews Miss Things


Architects and engineers already invest considerable effort in quality assurance and quality control.


The issue is not a lack of expertise. It's the scale of the information that must be checked.


A human reviewer might need to connect a paragraph in a university's engineering standards to an equipment schedule, a technical specification, and a drawing detail.


That comparison becomes even more difficult when documents are revised repeatedly.


Research supports the broader importance of better information management. A 2021 study by Autodesk and FMI, involving more than 3,900 construction professionals, found that organizations with stronger data practices reported fewer delays, budget overruns, rework events, and change orders.


The challenge is making the correct requirements available to the right people at the right time.


A Different Approach: Continuous Compliance Intelligence


Core Runway is developing an AI-powered platform that examines institutional design standards alongside architectural specifications, engineering drawings, revisions, and construction submittals.


Rather than relying solely on a general-purpose AI question such as "find problems in these documents," the platform structures requirements into individually evaluated rules.


Each requirement can be compared against the relevant project documentation.


Findings are categorized to help reviewers understand what action may be necessary:


Non-compliant: A specification or drawing conflicts with an applicable requirement.


Partially compliant: The design satisfies part of a requirement but omits an important element.


Stricter compliance: The design exceeds the owner's requirement, potentially creating an opportunity for value engineering.


Missing reference: The documentation does not explicitly reference a required standard or code.


Manual verification required: The available evidence is insufficient for a reliable automated determination.


Crucially, findings are linked to their source documents so architects, engineers, and building owners can review the evidence and make the final decisions.


The goal is not to replace professional judgment. It's to help experienced professionals focus their attention on issues that might otherwise be overlooked.


The Real Opportunity Is Before Construction

A design discrepancy identified during preconstruction may require a specification correction, drawing revision, or clarification between engineering disciplines.


The same discrepancy discovered after equipment has been purchased or installed can trigger significantly more work.


That is why the timing of a finding can be as important as the finding itself.

For institutional owners operating extensive building portfolios, the opportunity extends beyond individual projects.


Once an organization's design standards have been structured into a reusable compliance system, those requirements can be evaluated consistently across multiple projects and design teams.


Over time, approved exceptions, recurring decisions, and institutional preferences can also become part of a continuously improving knowledge base.


Back to the $3 Million Question


We're not claiming that AI could have eliminated the entire $3 million in change orders on our example project.


It couldn't.


What we're investigating is how many of those changes were associated with detectable problems in the original documentation, and what the financial impact might have been if those problems had been identified earlier.


The analysis requires more than reading the change-order descriptions. Each candidate needs to be connected to its underlying design requirement, original project documents, and the reason the change became necessary.


That's the standard of evidence we believe construction AI should meet.


The question isn't whether AI can find discrepancies in construction documents. It increasingly can. The question is whether those findings can prevent enough expensive problems to materially improve construction economics.


For universities, hospitals, airports, and other institutional owners managing hundreds of millions of dollars in annual construction spending, even modest improvements could have substantial financial consequences.


And that's a question worth investigating.

 
 
 

A construction project can comply perfectly with an owner's standards on paper and still end up with the wrong product installed in the building.

Why?

Because design compliance and construction compliance are often treated as separate processes.

They shouldn't be.

The Requirement Starts Upstream

Consider a relatively simple product such as paint.

The owner's standards may establish acceptable manufacturers, sustainability requirements or performance criteria.

The project specification then defines the required coating system.

The drawings may identify locations, colors and finishes.

The subcontractor prepares a submittal.

The manufacturer supplies product data, technical documentation and environmental information.

The architect or engineer reviews the package.

Eventually, someone installs the product.

The important point is that the requirement has traveled through multiple documents and multiple organizations before becoming something physical.

At every handoff there is an opportunity for information to be lost.

Specifications Are Only One Link in the Chain

Traditional document review tends to look at each stage separately.

The specification is checked during design.

Submittals are reviewed during construction.

Sustainability documentation may be reviewed by another consultant.

Owner requirements may be checked by the facilities team.

Each reviewer is looking at a different piece of the same decision.

But the real question is simpler:

Does the thing we are actually going to install satisfy what the owner originally required?

Answering that question requires connecting the documents rather than reviewing them in isolation.

The Submittal Is Where Theory Becomes Reality

During design, a specification might require:

  • a particular performance level

  • an approved manufacturer

  • a material composition

  • a VOC threshold

  • a finish

  • a warranty

  • specific testing

  • particular supporting documentation

But the specification is still an instruction.

The submittal introduces the actual proposed product.

That makes the submittal process one of the most important compliance checkpoints in construction.

It is where:

“This is what the project requires”

meets:

“This is what we intend to buy and install.”

Yet much of that comparison is still performed manually.

The Information Is Spread Everywhere

A reviewer may need to move between:

  • owner design standards

  • project specifications

  • drawings and schedules

  • approved manufacturer lists

  • product data sheets

  • environmental documentation

  • shop drawings

  • previous review comments

Even apparently straightforward scopes can involve dozens of individual requirements.

The difficulty is not necessarily that any single requirement is hard to understand.

The difficulty is finding all of them reliably.

Moving the Review Earlier

There is an opportunity to improve the process before the submittal even exists.

Instead of waiting for a subcontractor or manufacturer to assemble a package and then discovering what is missing, AI can first extract the applicable requirements from the project documents.

Those requirements can become a structured pre-submittal checklist.

For example:

Required product → location → performance criteria → approved manufacturers → documentation required

The subcontractor or manufacturer begins with a clear definition of what the project expects.

Then, when the actual submittal package comes back, it can be compared automatically against those same requirements.

The workflow becomes:

Requirements → submittal preparation → manufacturer evidence → automated comparison → human review

That is fundamentally different from simply using AI to summarize a product data sheet.

Connect the Owner All the Way to the Product

For institutional building owners, the bigger opportunity is connecting this workflow all the way upstream.

Imagine a single chain:

Owner standards

↓

Project specifications and drawings

↓

Submittal requirements

↓

Proposed manufacturer and product

↓

Supporting evidence

↓

Human approval

Every decision remains traceable to the requirement that created it.

Now a facilities team can ask not merely whether a project specification complied with its standards during design, but whether the actual products proposed during construction still comply.

Compliance Should Be Continuous

Construction documentation is constantly changing.

So compliance cannot realistically be treated as a one-time event.

A project may be compliant when the specification is issued and become non-compliant after a substitution.

A compliant design may generate a non-compliant submittal.

A product that meets the technical specification may conflict with an institutional preference that was never carried forward correctly.

The solution is not simply another review step.

It is maintaining the connection between requirements and decisions throughout the project.

AI makes that increasingly practical.

The goal is not to remove architects, engineers, contractors or facilities professionals from the approval process.

It is to give them something they have rarely had before:

A continuous, source-linked line from the owner's rulebook to what eventually goes into the building.

 
 
 

Universities, healthcare systems and other large building owners often maintain extensive internal design standards.

They exist for good reasons.

An institution may have decades of experience operating hundreds of buildings. It knows which equipment performs reliably, which materials cause maintenance problems, which systems its facilities teams can support, and which design decisions create unnecessary operating costs.

That knowledge gets turned into design guidelines, technical standards, preferred manufacturers, standard details and specifications.

The problem is not creating the rulebook.

The problem is making sure every project actually follows it.

The Scale Problem

Consider what an architectural or engineering team may be asked to reconcile.

On one side is the owner's design manual — potentially hundreds or thousands of requirements covering architectural systems, mechanical equipment, electrical infrastructure, plumbing, controls, finishes, sustainability requirements and preferred products.

On the other is a project specification that can itself run to several thousand pages, accompanied by hundreds of drawings.

Every applicable requirement has to make it across that gap.

And the comparison is not simple keyword matching.

A standard might require a particular material, prohibit another, specify a preferred manufacturer, establish a performance threshold, require documentation, or allow an exception under certain circumstances.

Someone has to understand both documents well enough to identify the relationship.

Standards Change. Projects Change.

The problem becomes harder because neither side is static.

Institutional standards evolve as facilities teams learn from completed buildings, products change, regulations are revised and operating priorities develop.

Project documentation changes too.

Specifications are revised. Addenda are issued. Products are substituted. Value engineering changes decisions. Submittals introduce the actual products that will eventually be installed.

That means compliance is not a single review performed at one point in the project.

It is a continuing comparison between what the institution requires and what the project is proposing.

Why Previous Projects Are Not a Reliable Compliance System

One common approach is to begin a new project using specifications from a previous project.

That is understandable. Reusing proven work is efficient.

But it creates a hidden risk.

The previous specification may have been based on an older version of the owner's standards. It may contain an approved exception that applied only to that project. It may contain something that was never compliant in the first place.

Once copied, those decisions can propagate from project to project.

The specification begins functioning as an informal version of the owner's rulebook.

The institution now has two standards:

The one it publishes.

And:

The one its projects have historically used.

Those two can slowly diverge.

The Institutional Knowledge Problem

There is another complication.

The written rulebook is rarely the complete rulebook.

Experienced facilities personnel know things that have never been formally documented.

A particular product may technically comply but have performed poorly in the field.

A specified system may require an exception in a particular building type.

A facilities team may prefer one solution because its technicians already stock parts and know how to maintain it.

These decisions often live in people's memories, emails and previous project files.

When experienced employees retire or leave, some of that knowledge leaves with them.

The next team has to rediscover it.

AI Changes What Is Practical

Until recently, comparing every requirement against every relevant section of a multi-thousand-page project package was technically possible but economically difficult.

The labor required made comprehensive review impractical.

AI changes that equation.

A system can now ingest an institutional rulebook, analyze a complete project specification and systematically identify where requirements appear to be satisfied, contradicted or only partially addressed.

Importantly, AI should not make the final professional decision.

Its job is to perform the exhaustive research.

A qualified human reviewer remains responsible for determining whether a design is acceptable.

The useful model is therefore:

AI finds and compares. Humans decide.

From Static Rulebook to Living Institutional Knowledge

The bigger opportunity goes beyond faster document review.

Imagine that every time a reviewer approves an exception, rejects a product, clarifies a requirement or establishes a preferred approach, that decision can become reusable institutional knowledge.

The next project starts with what the organization learned on the previous one.

Instead of repeatedly interpreting the same rules, institutional knowledge accumulates.

The rulebook becomes more than a PDF.

It becomes a living system connecting:

Standards → project designs → products → evidence → human decisions → future standards

That may ultimately be the most important application of AI in institutional construction.

Not replacing professional judgment.

Making sure that professional judgment is applied consistently — and that what the organization learns is never lost.

 
 
 
bottom of page