AI and schedule analysis: four different things under one word
"AI-powered schedule analysis" is now on almost every product page in this market, and it covers at least four techniques with different failure modes and very different standing when somebody asks how a number was produced. This page separates them, says where each genuinely helps, and says what a reviewing authority or a tribunal can check about each.
The position of this tool is stated in one sentence on what it does: it makes no network calls, contains no language model anywhere in the answer path, and has no third-party runtime dependencies — enforced as a build failure rather than as a policy. This page is that sentence expanded into an argument. It is not an argument that the techniques below are worthless. Three of the four are useful, and the fourth is useful somewhere other than in the answer.
The four things
| Technique | What it produces | Can a second person reproduce it exactly? | Where it belongs |
|---|---|---|---|
| Deterministic computation | dates, floats, path membership | yes, from the same inputs, by anyone with the same rules | the answer |
| Statistical analysis | a distribution, a percentile, a confidence band | the arithmetic, yes; the inputs are judgments | forecasting, contingency |
| Machine learning | a fitted prediction from historical projects | only with the model, the weights and the training population | screening, prioritising |
| Language-model reasoning | prose, summaries, drafts, extraction | no — same prompt, different output | reading and drafting, never the number |
The column that matters is the third one. A number a second person can reproduce from the same inputs is a different kind of object from one they cannot, and the difference is not a matter of how good the number is.
Deterministic computation
A forward pass and a backward pass over a network of activities, relationships and calendars produce the same early dates, late dates and floats every time from the same inputs. There is no sampling, no seed, no model. Change an input and the output changes in a way you can point at.
Nobody markets this, which is exactly why it is worth saying out loud: the numbers in a delay claim are arithmetic. Total float, the length of an overlap window, whether a path was driving on a given data date — computed, not estimated.
What makes that checkable rather than merely true is stating the options. A critical path computed under longest path is not the same set as one computed under a total float threshold; retained logic and progress override give different answers on the same out-of-sequence work; the lag calendar changes dates. Those settings live in the schedule file itself, and this tool reads them and prints them above the findings rather than assuming a house default. Verification re-runs a recorded answer and either reproduces it or names the first value that differs.
Where it fails: it cannot tell you what a delay was about. It computes overlap and never infers whose delay a period was.
Statistical analysis
Schedule risk analysis, Monte Carlo simulation over duration distributions, correlation between activities. Given duration ranges it produces a distribution of completion dates and a percentile you can quote, and it helps where the question is genuinely about uncertainty: how much contingency to hold, which paths are most likely to become critical.
Where it fails, and it is not the arithmetic. The simulation is deterministic given its seed; the inputs are not measurements. A three-point duration estimate is a judgment, correlation between activities is usually assumed rather than observed, and the output inherits all of it. A P80 date is a statement about a model, and its defensibility is the defensibility of the ranges somebody typed in.
What a reviewer can check: the input distributions, the correlation assumptions, the seed, and the number of iterations. If those are published, the run reproduces. If they are not, the percentile is unfalsifiable.
Machine learning
A model fitted to a corpus of historical projects, predicting which activities tend to slip, how much, or where a schedule resembles ones that ran late. Several products in this market are positioned this way, and their own pages describe forecasting for delivery rather than retrospective analysis of a past delay — which is the honest place for it.
It helps as a screen. "These twelve activities most resemble ones that slipped on comparable work" is a useful sentence to a team deciding where to spend a week of attention.
What it would take for such a model to be defensible in a dispute, stated as the questions the other side's expert will ask:
- What was it trained on? Which projects, sectors, contract forms, how many, over what period. A model fitted on data centre fit-out is evidence about data centre fit-out.
- Is that population disclosed and inspectable? A confidential training corpus cannot be examined by anyone who did not build it.
- What is the error on held-out data? Not how well it fits what it was trained on, but the error on projects it never saw.
- Does it reproduce? Same inputs, same weights, same output, in two years, after the vendor has retrained.
- Can it say why? A feature attribution is not a causal account, and a tribunal asking why an activity was flagged is asking a causal question.
None of that is impossible; all of it is work, and a product that has done it will say so specifically rather than saying "AI-powered". The practical consequence today is that a fitted prediction is a reason to go and look, not a finding about what happened.
Language-model reasoning
This is what most of the market now means by AI. An LLM reads a specification, summarises a narrative, drafts a section, extracts dates from a letter, classifies correspondence. One hosted product's own page says its reports carry an AI-generated executive narrative alongside the PDF and the spreadsheet, which is a fair description of where the technique fits.
Where it genuinely helps:
- Reading a long specification and pointing at the clauses that mention scheduling, so a person reads the right twelve pages instead of all ninety.
- Summarising a monthly narrative report, or a pile of correspondence.
- Drafting — a first cut of a delay narrative for a person to correct, or a plain-English explanation of a technical finding.
- Extraction with a human check: pulling candidate dates and references out of unstructured documents for somebody to verify against the source.
Where it must not be trusted:
- A date. Arithmetic over calendars is exactly the task where a language model produces a confident, well-formatted, wrong answer.
- A float value. Worse, because float is a difference of two computed dates and the error compounds.
- A causation finding. Which delay caused what is the disputed question, and a model answering it cannot show its working in a form anybody can check.
- A clause verdict. "This schedule satisfies §3.3.11" is a rule applied to a fact; both, and the step between them, should be inspectable.
An LLM is good at language and bad at ledgers. Put it where the subject is language, keep it out of the arithmetic, and say which side of the line it sat on.
Automated specification checking
Running a specification's clauses against a file mechanically is genuinely valuable and genuinely limited, and the limit is the interesting part.
A check can establish that a stated condition is or is not met in the file: this many activities have no predecessor, this many carry a constraint of this type, the data date is this. It cites the clause, shows the rows, and the count either reproduces or it does not.
What it cannot establish is whether a requirement is satisfied as a contractual matter. A clause asking for a "reasonable" sequence, or an "adequate" narrative, commits the question to a person's judgment, and a green tick against it is a machine answering a question it was not given. This tool refuses those structurally — a rule marked as judgment cannot return a pass — and where it lacks the input to decide, it abstains and names the input it would need. That worklist is the output, not a byproduct of it.
A second limit is invisible: a check that confirms a clause exists is not confirming it is the right clause. The first is mechanical, the second is not, and the two are easy to confuse.
Anomaly detection
Outlier detection over a schedule — durations far from their peers, unusual lag patterns, progress that moved in a direction it should not — is cheap, deterministic if you write it that way, and useful.
It finds unusual, not wrong. A 400-day activity is unusual and may be a perfectly correct level-of-effort line. The DCMA 14-point checks are the best-known example, and the GAO guide's own appendix says those thresholds are not compliance triggers — see the GAO assessment page.
Two failure modes to watch for: a tool that converts an outlier into a verdict, and one that converts a threshold it chose itself into a verdict. A generic cut-off is the tool's own view about what a schedule should look like; a clause citation is the contract read back to you.
Automated delay detection
Comparing successive updates and reporting what changed — which activities slipped, which paths became driving, where float was consumed — is mechanical and reproducible, and it is the most useful automation in this field. It stops short of a claim in three places:
- It does not know the cause. An activity finished late; the file does not say why.
- It does not know the party. Attribution is a fact about the project record, not about the network.
- It does not resolve concurrency. Overlap is arithmetic; whether two overlapping delays are concurrent in a sense a tribunal recognises depends on which theory and which causation doctrine you apply, and the authorities do not agree. See concurrent delay.
Those gaps are also why an import-time convenience deserves attention. One platform's published API specification names an import-change metric for generated logic ties — relationships added during import. A computed critical path can then rest on logic the schedule's author never wrote. The same specification contains no field for concurrency, none for excusability or compensability, and none recording which analysis method produced a result. An interface is a good description of what a product models.
What a tribunal or a reviewing authority can check
The reproducibility test, in the order it usually gets asked:
- Can I re-run it? Same inputs, same stated options, same answer — on a different machine, by a different person, later.
- Can I see the rule? The condition it applied, and the clause it came from.
- Can I see the rows? The activities that met the condition, by the identifier the planner actually types.
- Does it say what it did not decide? A tool that answers everything has either been given more than the file contains, or is guessing somewhere.
- Was a person in the loop where judgment was required, and does the output say where?
A pipeline that includes a language model can pass all five, provided the model did not touch the answer and the output says so. A pipeline that cannot answer (1) is producing something other than a measurement, whatever it is called.
What this tool contains, and what it does not
No network calls. No language model in the answer path. No third-party runtime dependency — checked at build time, so the claim fails loudly rather than drifting. That is not a claim of superiority over a hosted product; it is a claim about what can be said about the output, and it has costs. A hosted product a stranger can open from a link is easier to try than a local install, and several in this market are. Limitations and is this real? state what has and has not been established here.
Related
- What it does and how it works
- Verification — re-running a recorded answer
- Concurrent delay: the authority map
- Limitations
Source: web/pages/ai-schedule-analysis.md. Source commit date: 2026-09-11.