The project finish date has moved forward by ten working days across the update series, driven by a net reduction in critical path durations, with the largest shift occurring in a single update period. This movement represents a meaningful acceleration relative to the remaining programme duration, and the consistent forward trajectory across two out of three update periods indicates sustained improvement rather than an isolated adjustment. However, a critical-path divergence on 68 activities raises concerns about the reliability of the schedule logic, which may affect confidence in the reported finish date. The reader should review the timeline of project finish dates across updates to verify the observed acceleration trend.

Project completion trajectory across the update series. The observed cumulative delay column is the authoritative measure — it reflects the actual movement of the project finish date between the first schedule and each subsequent update. The pairwise cumulative column sums the engine's per-period net delay figures; it is shown for period-level attribution but should not be used as a headline figure where it diverges from the observed column.

The project finish date moved ten working days earlier than the baseline, representing the observed completion movement and serving as the authoritative top-line metric. The summed activity-level slip of +14 working days reflects the total churn within the schedule, capturing extensions, progress delays, and scope additions across all affected activities regardless of criticality or float absorption, and should be interpreted as a structural signal rather than a direct measure of project impact. This figure provides a sanity check against the finish movement and serves as the denominator for the WBS-level rollup that follows. The topology edits, which indicate where the schedule logic was altered between baseline and update, are grouped by WBS package and act as direction-of-travel signals rather than quantified day impacts due to the absence of calendar-aware Time Impact Analysis per event. Investigation should focus on the Superstructure package, where the highest concentration of logic changes occurred.

What happened. The project-finish date moved out by +5 working days between the baseline and the update.

Why. The engine logged 1 activity-level event — progress behind plan, duration extensions, and scope additions — totalling +5 working days of summed activity-level slip. This figure is a measure of churn and a structural signal of the schedule, not project impact: each activity is counted independently, so parallel paths and float-absorbed slip both add to it. Read it as a sanity check against the project-finish movement above (a small total against a large movement points to topology drivers below) and as the denominator for the WBS rollup that follows.

Where to investigate. No topology edits were identified between the schedules.

The three figures above answer different questions and are not expected to reconcile. What happened is the authoritative project-level movement; Why is the summed activity-level slip across every event — a churn and structural signal, with each activity counted independently so parallel paths and float-absorbed slip both add to it; Where is a direction-of-travel signal for structural edits the engine cannot size without a calendar-aware Time Impact Analysis per event. See METHODOLOGY §5a.

What this section answers: where else forward risk is concentrated besides the controlling chain. Each row is an alternative chain to the project endpoint that's within 20 working days of the critical path; any of them could become controlling with a small slip.

3 sub-critical paths within 20 working days of critical — a delay on any of them could shift the controlling path. Rank 1 in the table below is the primary critical path for reference.

The register below lists every identified change between baseline and update. Each row carries an Impact basis tag (matching the chart that follows) so the reader can immediately see whether its delay-days value is a directly-measured figure or a placeholder:

• Activity-level (measured) — Duration change and Progress shortfall events. The delay-days value is a directly-measured working-day figure (update duration minus baseline duration for duration changes, or days-behind-current-plan for progress events).
• Scope — upper bound — Added scope and Removed scope events. The activity's own planned duration is shown as an upper bound; the real delay contribution depends on whether the activity sits serially on the critical path, which this engine does not verify per event.
• Topology (engine-unresolved) — Logic change, Constraint change, and Calendar change events. These carry a 0 delay-days value because the engine cannot size each event's isolated impact without a calendar-aware Time Impact Analysis per event (METHODOLOGY §5a).

Positive delay values indicate delay to the project finish; negative values indicate acceleration. The TIA (wd) column carries the isolated Time Impact Analysis figure for each critical event — working-day movement of the project finish when the event's change is reverted in isolation (AACE MIP 3.4-shaped; CIOB §5.8.34–5.8.43). Events off the critical path show "—"; events whose category is not resolvable by the calendar- and constraint-agnostic trace (constraint / calendar changes) show "see note" — see METHODOLOGY §5a for the limitation. The Entitlement (prelim.) column carries a rule-based first-pass classification per SCL Protocol §10.4 (Employer risk / Contractor risk / Neutral / Concurrent / Not assessed). The first-pass reads activity descriptions for cause-of-delay keywords and falls back to category-default rules where no keyword fires. Verify every classification against the contract, the variation register, NCRs, and documentary evidence before relying on it in any formal correspondence — the final call is a legal / contractual determination this tool does not make.

Composition by category:

• Duration change: 1

The full register for this period (1 event) is in the All Delay Events sheet of the Excel companion — filter the Period column to P1. The composition chart above and the cumulative waterfall below summarise the register's shape; the Brief layer's WBS-impact decomposition names the packages where action is warranted.

Timeline visualisation of delay events plotted against the project schedule. Events are coloured by category; concurrent-delay windows are shaded.

This section lists time windows where two or more independent critical delay events overlap. The "net impact" column shows the delay days that flow through to the project completion date under the methodology named in the disclosure at the top of the report; the "absorbed" column shows delay days that would otherwise have been counted twice and are removed from the total.

The delay register contains 1 critical event(s), of which 1 carry a measurable delay in days.

Concurrent delay analysis requires at least two independent, measurable critical events overlapping in time.

What happened. The project-finish date moved out by +10 working days between the baseline and the update.

Why. The engine logged 3 activity-level events — progress behind plan, duration extensions, and scope additions — totalling +24 working days of summed activity-level slip. This figure is a measure of churn and a structural signal of the schedule, not project impact: each activity is counted independently, so parallel paths and float-absorbed slip both add to it. Read it as a sanity check against the project-finish movement above (a small total against a large movement points to topology drivers below) and as the denominator for the WBS rollup that follows.

Where to investigate. A further 1 topology event (logic, constraint or calendar edits) sit across 1 WBS package. The engine cannot size each event's isolated working-day impact without a calendar-aware Time Impact Analysis per event (METHODOLOGY §5a) — these are direction-of-travel signals showing where the schedule was rewired between baseline and update, not how many days each edit added. Review those packages to understand the structural shift.

The three figures above answer different questions and are not expected to reconcile. What happened is the authoritative project-level movement; Why is the summed activity-level slip across every event — a churn and structural signal, with each activity counted independently so parallel paths and float-absorbed slip both add to it; Where is a direction-of-travel signal for structural edits the engine cannot size without a calendar-aware Time Impact Analysis per event. See METHODOLOGY §5a.

Activities that exist in one schedule but not the other. Added activities represent new scope; removed activities represent scope deletion.

• Added activities: 1 (total planned duration 14 working days)
• Removed activities: 0

The activity matching process uses four cascading strategies before an activity falls into these pools:

• Exact ID
• Normalised ID
• Name plus WBS path
• Name-only fallback

Surviving entries are genuine scope changes, not renumbering or WBS-restructuring artefacts.

Full per-activity lists (every added and removed activity) are in the Excel appendix under the Scope Changes tab.

What this section answers: where else forward risk is concentrated besides the controlling chain. Each row is an alternative chain to the project endpoint that's within 20 working days of the critical path; any of them could become controlling with a small slip.

2 sub-critical paths within 20 working days of critical, plus 2 additional zero-float chains parallel to the primary driving path — a delay on any of them could shift the controlling path. Rank 1 in the table below is the primary critical path for reference.

At the current earned-value gradient (EV 5.4 % at the data date, slope 0.09 pp/day, R² 0.99), the schedule reaches 100 % around 2029-01-20 — roughly 205 calendar days later than the stored finish of 2028-06-29. The productivity-factor rows below show how the implied finish responds to slower execution.

Indicative only. The PF rows apply the named productivity factor to remaining durations on labour activities (procurement / milestones are not scaled) and re-trace the longest path. They do not re-level resources, re-apply calendars, or re-optimise logic — use alongside a native P6 re-schedule for any contractual decision (METHODOLOGY §5b).

The register below lists every identified change between baseline and update. Each row carries an Impact basis tag (matching the chart that follows) so the reader can immediately see whether its delay-days value is a directly-measured figure or a placeholder:

• Activity-level (measured) — Duration change and Progress shortfall events. The delay-days value is a directly-measured working-day figure (update duration minus baseline duration for duration changes, or days-behind-current-plan for progress events).
• Scope — upper bound — Added scope and Removed scope events. The activity's own planned duration is shown as an upper bound; the real delay contribution depends on whether the activity sits serially on the critical path, which this engine does not verify per event.
• Topology (engine-unresolved) — Logic change, Constraint change, and Calendar change events. These carry a 0 delay-days value because the engine cannot size each event's isolated impact without a calendar-aware Time Impact Analysis per event (METHODOLOGY §5a).

Positive delay values indicate delay to the project finish; negative values indicate acceleration. The TIA (wd) column carries the isolated Time Impact Analysis figure for each critical event — working-day movement of the project finish when the event's change is reverted in isolation (AACE MIP 3.4-shaped; CIOB §5.8.34–5.8.43). Events off the critical path show "—"; events whose category is not resolvable by the calendar- and constraint-agnostic trace (constraint / calendar changes) show "see note" — see METHODOLOGY §5a for the limitation. The Entitlement (prelim.) column carries a rule-based first-pass classification per SCL Protocol §10.4 (Employer risk / Contractor risk / Neutral / Concurrent / Not assessed). The first-pass reads activity descriptions for cause-of-delay keywords and falls back to category-default rules where no keyword fires. Verify every classification against the contract, the variation register, NCRs, and documentary evidence before relying on it in any formal correspondence — the final call is a legal / contractual determination this tool does not make.

Composition by category:

• Duration change: 2
• Logic change: 1
• Added scope: 1

The full register for this period (4 events) is in the All Delay Events sheet of the Excel companion — filter the Period column to P2. The composition chart above and the cumulative waterfall below summarise the register's shape; the Brief layer's WBS-impact decomposition names the packages where action is warranted.

Timeline visualisation of delay events plotted against the project schedule. Events are coloured by category; concurrent-delay windows are shaded.

This section lists time windows where two or more independent critical delay events overlap. The "net impact" column shows the delay days that flow through to the project completion date under the methodology named in the disclosure at the top of the report; the "absorbed" column shows delay days that would otherwise have been counted twice and are removed from the total.

The delay register contains 2 measurable critical events. None met the SCL §10.4 independence test for concurrency — the events are either causally linked in the schedule network (one activity is upstream of the other in either the baseline or the update) or their time windows do not overlap. This is a defensible zero, not an absence of analysis: SCL true concurrency requires two or more independent critical chains contending for the finish during the same period. Where a schedule shows a single dominant delay chain — for example a vendor procurement sequence or a commissioning chain — the events on that chain are causally linked and correctly excluded. Where two or more independent chains exist, this section will populate with the windows during which they overlap. Review the delay register and the schedule logic to confirm the chain structure is expected.

What happened. The project-finish date pulled forward by +5 working days between the baseline and the update.

Why. The engine logged 2 activity-level events — progress behind plan, duration extensions, and scope additions — totalling −5 working days of summed activity-level slip. This figure is a measure of churn and a structural signal of the schedule, not project impact: each activity is counted independently, so parallel paths and float-absorbed slip both add to it. Read it as a sanity check against the project-finish movement above (a small total against a large movement points to topology drivers below) and as the denominator for the WBS rollup that follows.

Where to investigate. No topology edits were identified between the schedules.

The three figures above answer different questions and are not expected to reconcile. What happened is the authoritative project-level movement; Why is the summed activity-level slip across every event — a churn and structural signal, with each activity counted independently so parallel paths and float-absorbed slip both add to it; Where is a direction-of-travel signal for structural edits the engine cannot size without a calendar-aware Time Impact Analysis per event. See METHODOLOGY §5a.

What this section answers: where else forward risk is concentrated besides the controlling chain. Each row is an alternative chain to the project endpoint that's within 20 working days of the critical path; any of them could become controlling with a small slip.

2 sub-critical paths within 20 working days of critical, plus 1 additional zero-float chain parallel to the primary driving path — a delay on any of them could shift the controlling path. Rank 1 in the table below is the primary critical path for reference.

Recent EV gradient is too unstable to extrapolate reliably — implied finish is 378 calendar days later than stored (47% of remaining schedule), beyond the 30% envelope at which the recent gradient is usually a phase transition rather than a sustainable productivity trend. The single-number EV-implied finish has been suppressed; the productivity-factor scenarios below give a defensible bracketed range against the stored finish (METHODOLOGY §5b.5).

Indicative only. The PF rows apply the named productivity factor to remaining durations on labour activities (procurement / milestones are not scaled) and re-trace the longest path. They do not re-level resources, re-apply calendars, or re-optimise logic — use alongside a native P6 re-schedule for any contractual decision (METHODOLOGY §5b).

The register below lists every identified change between baseline and update. Each row carries an Impact basis tag (matching the chart that follows) so the reader can immediately see whether its delay-days value is a directly-measured figure or a placeholder:

• Activity-level (measured) — Duration change and Progress shortfall events. The delay-days value is a directly-measured working-day figure (update duration minus baseline duration for duration changes, or days-behind-current-plan for progress events).
• Scope — upper bound — Added scope and Removed scope events. The activity's own planned duration is shown as an upper bound; the real delay contribution depends on whether the activity sits serially on the critical path, which this engine does not verify per event.
• Topology (engine-unresolved) — Logic change, Constraint change, and Calendar change events. These carry a 0 delay-days value because the engine cannot size each event's isolated impact without a calendar-aware Time Impact Analysis per event (METHODOLOGY §5a).

Positive delay values indicate delay to the project finish; negative values indicate acceleration. The TIA (wd) column carries the isolated Time Impact Analysis figure for each critical event — working-day movement of the project finish when the event's change is reverted in isolation (AACE MIP 3.4-shaped; CIOB §5.8.34–5.8.43). Events off the critical path show "—"; events whose category is not resolvable by the calendar- and constraint-agnostic trace (constraint / calendar changes) show "see note" — see METHODOLOGY §5a for the limitation. The Entitlement (prelim.) column carries a rule-based first-pass classification per SCL Protocol §10.4 (Employer risk / Contractor risk / Neutral / Concurrent / Not assessed). The first-pass reads activity descriptions for cause-of-delay keywords and falls back to category-default rules where no keyword fires. Verify every classification against the contract, the variation register, NCRs, and documentary evidence before relying on it in any formal correspondence — the final call is a legal / contractual determination this tool does not make.

Composition by category:

• Duration change: 2

The full register for this period (2 events) is in the All Delay Events sheet of the Excel companion — filter the Period column to P3. The composition chart above and the cumulative waterfall below summarise the register's shape; the Brief layer's WBS-impact decomposition names the packages where action is warranted.

Timeline visualisation of delay events plotted against the project schedule. Events are coloured by category; concurrent-delay windows are shaded.

This section lists time windows where two or more independent critical delay events overlap. The "net impact" column shows the delay days that flow through to the project completion date under the methodology named in the disclosure at the top of the report; the "absorbed" column shows delay days that would otherwise have been counted twice and are removed from the total.

The delay register contains 1 critical event(s), of which 1 carry a measurable delay in days.

Concurrent delay analysis requires at least two independent, measurable critical events overlapping in time.

This report applies the same Delay Analysis treatment to each consecutive pair of schedules in the series and aggregates the results. Two cumulative figures appear in the Brief layer's cumulative delay profile and the distinction between them is load-bearing.

Observed cumulative delay is derived from the project-finish date stored on each schedule, measured in working days from the first schedule's finish using the first schedule's default calendar. It reflects what actually happened to the completion date and is the authoritative top-line figure for the series. It is independent of how the engine attributes delay to specific events.

Pairwise cumulative delay is the running sum of the engine-attributed net delay for each consecutive pair of schedules. Net delay subtracts concurrent absorption per the named concurrency methodology, so the pairwise sum answers a different question than the observed movement: it shows what share of the movement the engine could attribute to specific delay events at the activity level. Where the two diverge materially, treat the observed figure as authoritative and read the per-period decomposition (in the appendix) for the structural shifts the engine could not size without a calendar-aware Time Impact Analysis per event (METHODOLOGY §5a).

Concurrent delay handling. Each period applies the named concurrency strategy to decide which overlapping critical events drive the period's net delay. The strategy is fixed across the series — switching mid-series would invalidate the running pairwise sum. The disclosure at the top of the report names the strategy in force; review the alternative listed there if the contract calls for a different approach.

Concurrency criticality test (approximation note). Within each period, criticality for concurrency-candidate selection is evaluated as the union of baseline-side and update-side critical-path membership. This is a snapshot-level approximation of "critical during the overlap window" — a precise window-level test would require a CPM walk per overlap interval, which is outside V1 scope. The approximation will under-detect concurrency in cases where an activity was on the critical path only during a sub-window of the overlap and not at either snapshot date; this is a known limitation.

As-built critical path. This V1 series report does not produce a single stitched as-built critical path across the update series. The substitute is to read each period's delay register (in this Appendix), where critical events are flagged in the Critical column and represent the chain of activities driving the finish during that period. A reader can stitch the as-built CP manually by tracking which activity IDs appear as critical in successive periods. Producing a single stitched as-built CP timeline as a Brief-layer section is on the V1.1 roadmap.

Per-period appendix sections. Each period below emits the full Comparison-report appendix view: three-number decomposition, scope-change WBS clustering, float-path analysis on the post-period schedule, PF completion scenarios, the full delay register with cumulative waterfall, the delay timeline, and the concurrent-delay analysis. Section ids and chart ids are namespaced by period number so each period stands on its own.