Why comparing two schedule revisions is harder than it looks.

Ask anyone outside construction and comparing two schedules sounds like a solved problem. Line up the activities, subtract the dates, print what moved. Anyone who has actually tried it on a real pair of revisions knows how fast that falls apart.

The activity you are comparing may not exist in both files

This is the whole problem in one sentence. A comparison is only possible once you know which activity in Rev 7 is which activity in Rev 6. Between revisions, schedulers:

• renumber activities, often wholesale when a WBS is restructured
• split one activity into three as an area gets broken down
• merge three back into one when a phase is simplified
• rename activities while keeping the ID, or keep the name and change the ID
• delete work that moved into another contract, and add work that came back

Match on ID alone and a renumbering reads as "everything was deleted and replaced". Match on name alone and two identical names in different areas collapse into one. A comparison worth trusting has to use the ID, the name, the WBS path, the duration and the neighbours, and it has to say when it is unsure rather than guess quietly.

A date change is not the same as a change

Half the dates in a revision move. Most of those moves are consequences, not decisions. If an activity three steps upstream slipped four days and everything downstream slid with it, you have one change and forty symptoms. A list of forty is worse than useless — it buries the one line you needed to read.

What you want separated out:

• Duration changes. Somebody decided your activity now takes nine days instead of fourteen. That is a decision about you.
• Logic changes. A predecessor was added, removed or swapped. Your work is now waiting on something different.
• Sequence changes. The order of your areas flipped. Same dates, completely different mobilisation.
• Constraint changes. A "start no earlier than" appeared and is now driving the date rather than the logic.
• Pure drift. Everything moved because something upstream moved. Worth knowing, not worth reading line by line.

Float is where the damage hides

An activity whose dates did not move at all can still have had a terrible revision. If it went from twelve days of float to zero, nothing in a date comparison will tell you, and you have just become critical without being told. Float deltas belong in the comparison at the same level as date deltas, and they almost never are.

The calendar can change underneath you

Same start, same finish, same duration in days — and a different calendar. Six-day weeks became five, or a holiday set was applied, or the shift pattern on your area changed. Nothing in the comparison looks different and the work got harder. Any comparison that does not read the calendars is comparing numbers that no longer mean the same thing.

Two revisions is the easy case

Jobs do not arrive in pairs. A job that runs eighteen months arrives as Rev 1 through Rev 40, and the question you eventually have to answer is not "what changed last fortnight" but "when did this date first move, and what was the stated reason at the time". That is a baseline question, and it needs every revision held against one fixed point rather than each against the last.

And then you have to prove it

The output of a comparison is rarely for you. It is for the email you are about to send the GC, or the claim you are about to support six months from now. So it has to be legible to somebody who was not in the room: what changed, by how much, against which revision, and when you noticed. A highlighted printout is not that. A dated report is.

How GanttAI does it

Comparison in GanttAI is built around the matching problem first, because everything downstream depends on it. It aligns activities across revisions using ID, name, WBS position and shape rather than any single key, then reports what moved across dates, durations, logic and sequence — separating the decisions from the drift. Accuracy across those four is above 99%.

You pick the baseline. Compare Rev 7 against Rev 6, or every revision against Rev 1, as many times as the job throws them at you — comparisons are unlimited inside a project on every plan. The result downloads, and the report shares with a link, so the person who needs to see it does not need an account.

The useful part is not the speed. It is that the second revision costs you the same effort as the fortieth.