Delay analysis with AI: What it can and cannot do

That distinction matters because delay analysis is rarely lost on arithmetic. It is lost on weak records, a method that did not fit the data, and logic nobody validated against what happened on site. Software that makes those failures faster does not help. Software that makes them visible does.

TL;DR

• No single method is mandated. The SCL Delay and Disruption Protocol and AACE RP 29R-03 are the two main reference frameworks, and the method should be proportionate to the contract, the project value and the quality of the records.
• The most useful AI today assimilates fragmented records (change orders, site logs, resource plans) and flags likely delays early, rather than producing a final causation opinion.
• Research models that map dependencies between activities outperform those that treat each activity in isolation, but accuracy figures alone do not make a model trustworthy.
• Keep a human in the loop for causation and liability, and require every AI output to show its sources and assumptions.

What delay analysis actually has to prove

Delay analysis answers three questions: what caused the delay, how much completion moved because of it, and who bears the risk. The SCL Protocol describes it as a systematic process for establishing the causes, effects and responsibility for delay. A calculation that shows a number of days is not enough. The number has to be traceable to contemporaneous evidence and to the contract.

That is why the work is so labor-intensive. A single claim can draw on baseline and updated schedules, daily logs, correspondence, change orders, RFIs, resource histories and weather records, all in different formats and often inconsistent with one another. A 2026 AACE conference session on AI-powered agents for delay analysis frames the problem in just these terms: manual assimilation of large, fragmented datasets, with the risk of human error in documentation that follows from it.

The frameworks AI has to respect

In the United States, two documents dominate practice, and a third carries weight in the courtroom.

• AACE Recommended Practice 29R-03 is the forensic schedule analysis reference most common in the U.S. The SCL International paper comparing it with the SCL Protocol describes both as peer-reviewed institutional guides to forensic delay analysis methods.
• The SCL Delay and Disruption Protocol, second edition, is widely used internationally and is frequently written into contracts outside the U.S.
• ANSI/ASCE/CI 67-17, Schedule Delay Analysis, presents guiding principles for determining the impact of delays and the evidential value of CPM schedules.

For prospective time impact analysis, a forensic consultancy’s overview of TIA points to AACE RP 52R-06 as the U.S. recommended practice devoted to it, and notes that TIA is one commonly used method rather than a universally preferred one.

The method families these documents describe include as-planned versus as-built, windows analysis and time impact analysis. A 2024 ASCE journal paper counts more than two dozen delay analysis methods in use and observes that nobody had compared all of them against their data requirements. Choosing among them is the first real decision, and it is not one for a model.

Choosing a method before choosing a tool

The sophistication of a method is not a virtue in itself. The SCL Protocol favors contemporaneous analysis, which supports real-time mitigation. Its guidance on analysis distant from the delay event is a reminder that after-the-fact assessment calls for different handling than prospective assessment.

The practical trap is applying an elaborate retrospective method to records that cannot carry it. A time impact analysis built on a project with irregular schedule updates tends to look speculative rather than evidence-based, and a trier of fact will treat it that way. The validity of the method hinges on the quality of the update chain: the baseline and the series of progress schedules.

A workable selection logic looks like this:

Question	If the answer is yes	If the answer is no
Are periodic schedule updates complete and native files available?	Windows or contemporaneous period analysis is realistic	Lean on as-planned versus as-built with supporting records, and say so openly
Does the contract prescribe or exclude a method?	Follow it	Choose by data quality and the nature of the event
Is the claim value high enough to justify detailed modeling?	Invest in a rigorous method	Use a proportionate, simpler method
Can causation be tied to dated events in the record?	Prospective methods such as TIA become defensible	Retrospective methods with strong documentary support

The lesson for AI is direct. A tool that quietly runs the most advanced method on thin data produces confident output with no evidential value. A tool that reports how complete the update chain is, before any analysis runs, is more useful than one that computes faster.

Schedule slippage is not unique to heavy civil work either. Even a residential extension timeline shows how a handful of recurring delay causes compound across sequential trades, which is the same dependency logic that a forensic analyst has to untangle on much larger projects.

Where AI genuinely helps

Assimilating the record

The heaviest labor in a delay analysis is not the critical path calculation. It is finding, reading, dating and cross-referencing the documents. This is where AI has the clearest case. Reading change orders, matching them to schedule activities, extracting dates from daily logs and building a chronology are tasks of document processing, and they can be done with citations back to the source page.

Traceability is the point. Institutional standards such as AACE 29R-03 demand it, and an AI output that cannot be traced to a document is worthless in a dispute. Our own notes on change order analysis cover what contractors and project managers need from that first pass.

Predicting delays before they happen

The research literature has moved from project-level forecasting to activity-level prediction. A 2025 study in the Journal of Management in Engineering on a relationship-aware multihead graph attention network notes that earlier machine learning delay models could not process dependencies among construction progress records. Depending on whether contractual or spatial dependencies were emphasized in the network configuration, the models in that work reached roughly 65% to 77% predictive accuracy. Tree-based algorithms such as Random Forest, working on raw data from existing planning software, have been reported in recent studies to exceed 90% recall in identifying delayed starts and finishes for specific activities.

These figures are encouraging and should be read carefully. Recall of delayed activities says little about whether the prediction is explained. High statistical accuracy without a map of the dependencies behind it produces forecasts that no project manager will act on.

Explaining the why

A 2024 study on delays caused by variation orders reflects a broader shift in the field: from predicting that a delay will occur toward modeling why, whether through variation order impacts or resource shortages. A reason is what changes management behavior. A probability alone rarely does.

Checking the schedule itself

AI is also well suited to repetitive quality checks: broken logic, open ends, constraints that distort float, and updates that contradict the daily record. These are the defects that later undermine a claim, and finding them while the project is still running is cheaper than finding them in a dispute.

Where AI must not be the decision-maker

The authoritative position is consistent. AI should support the principled approach to forensic delay analysis, not replace it. The SCL International paper and ASCE 67-17 both rest on analysis that balances CPM calculation with practical examination of resource, production and record data. Causation and apportionment of liability are the part that determines the outcome of a dispute, and that rigor cannot be outsourced.

Three failure modes recur:

1. Black-box schedule output. Relying on scheduling software output without validating the logic against what happened on site is a primary reason delay claims fail in arbitration and litigation.
2. Models blind to dependencies. Construction activities depend on one another through contractual logic and through space and logistics. A model that treats activities as isolated nodes can report impressive accuracy and still mislead.
3. Unexamined assumptions. Any analysis embeds choices: which updates are the baseline, how concurrent delay is treated, which calendar applies. If the tool does not write these down, a reviewer cannot challenge them.

An American Bar Association overview of scheduling and claims makes the legal stakes plain: forensic schedule analysis methods have been accepted and rejected by triers of fact depending on how they were applied. Courts and administrative boards, as an older ASCE study noted, do not specify a standard delay analysis practice, so the burden of showing that a method fits the facts sits with the party relying on it.

A human-in-the-loop workflow that holds up

A division of labor that respects the standards might run as follows.

1. Define the question and the contract basis. An analyst or counsel identifies notice provisions, time-extension entitlements and any prescribed method.
2. Let AI build the evidence base. The system collects schedules, logs, change orders, RFIs and correspondence, dates them, links them to activities and lists gaps, each with a link to the source document.
3. Assess record quality. Before any method is chosen, check the update chain and the completeness of the records. This decides which methods are defensible.
4. Select the method with a person accountable. The choice follows contractual requirements, data quality and the nature of the causative event.
5. Run the analysis with assumptions written down. Calendars, logic changes, concurrency treatment and excluded events are listed so a reviewer can contest them one by one.
6. Expert review of causation and liability. The human expert tests the logic against site reality and owns the conclusion.
7. Feed lessons back into live projects. Early-warning flags and schedule-quality checks run during construction, not only after the damage is done.

The seventh step is where the economics improve. The same document understanding that supports a claim also reduces the number of claims, because slippage is flagged while it can still be mitigated.

Our perspective

We build Yesper as an AI civil engineer, and our view of delay analysis follows from how engineers review work. The most valuable thing an AI colleague can do is show its working. When Yesper produces a deliverable, it writes down its assumptions so that a reviewer can examine them the way they would examine a colleague’s. For delay analysis, that is the entire difference between a useful draft and a liability.

We also think the industry’s attention is in the wrong place. Debates about which algorithm predicts delays best matter less than whether the underlying project record is organized, searchable and traceable. Most of the effort in a delay analysis goes into assembling documents, and that is work an AI agent can do end to end, with sources attached. Our customers report 50 to 95 percent time saved on projects, and we see the largest gains where the work is document-heavy and repetitive.

But we are explicit about the boundary. Causation, entitlement and liability belong to qualified people, and tools should be designed so that those people can review rather than trust. That is why we build for source verification and human sign-off, a theme we explore in our pieces on AI for BIM and tender document analysis.

Putting this to work with Yesper

Teams that want delay evidence organized before a dispute starts can use Yesper to search project documents, check them against regulatory and contractual requirements, detect errors and draft reports with traceable sources. Agents can be configured for different project roles, and the platform integrates with common project tools. To see how it works in practice, book a demo or read how the platform is built.

What to ask of any AI delay analysis tool

• Does every statement link back to a source document? If not, it cannot support a claim.
• Does it report record quality before analysis? Update-chain gaps should be surfaced, not hidden.
• Are assumptions written out? Calendars, logic changes and concurrency treatment need to be reviewable.
• Does it model dependencies? Both contractual and spatial relationships between activities should be represented.
• Does it explain causes? A forecast without a reason rarely changes behavior.
• Who signs off? A named, qualified human must own the conclusion.

For wider context on adoption, our articles on AI for civil engineering, construction risk AI and proving AI return on investment cover governance and measurement.