SL-DEMO

This programme was re-baselined during the series. The observed cumulative delay column below measures every snapshot against the original baseline only (one fixed anchor), so figures after a re-baseline fold in the plan change; read them as a vs-original reference, not the headline. The per-era measure — each snapshot against the plan in force — is in the Baseline evolution section above. Periods marked ↺ straddle a re-baseline and are excluded from the trajectory counts.

The observed cumulative delay, the project finish's movement from the first schedule to each update, is the authoritative measure; what the engine tied to critical activities is in the per-period detail.

Whether near-critical paths are burning float across the series, before it reaches the completion date. See Methodology (§34).

The per-period detail behind the cumulative delay profile: each period's finish movement, the completion trajectory S-curve, and every datable delay event across the series on one calendar.

For each period: of the activities the earlier update forecast to finish (or start) before the later update's data date, how many the later update records as done. A percentage is shown only where at least 30 were forecast.

Activity-level drivers summed by category over every period. Each activity is measured on its own, so the rows are not a delay total and are not expected to sum to the programme finish movement. See Methodology (§34).

What happened. The project-finish date moved 7 calendar days (5 working days) later between the earlier schedule and the update.

Why. The engine logged 1 activity-level event, by category in the table below: a map of where movement arose, not a delay total.

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

The drivers and topology signals below are diagnostics, each measured on its own: they are not expected to sum to the programme finish movement. See Methodology (§34).

Of the 3 activities the earlier schedule (data date 5 Jan 2026) forecast to finish before 4 Feb 2026, 3 had finished by the update, over 30 days; 1 of the 1 it flagged critical did. Shown as a count: fewer than 30 activities were forecast in this period.

Starts: of the 6 activities it forecast to start in the period, 6 had started.

Where else forward risk sits: alternative chains to the project end within 20 working days of the critical path. See Methodology (§34).

9 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.

Top 3 of 10 paths shown (the primary driving path plus 9 near-critical) — the full 5-path table and the float-path overlay chart are in Float paths — detail; every path is in the Excel appendix.

Measured against the baseline governing this update (SL-DEMO, finishing 2028-06-12), the work done by the data date (2026-02-04) was planned to be done by 2026-02-04: on the baseline. That is a schedule performance index (SPIt) of 0.98. At that pace the baseline's planned duration (889 days from 2026-01-05) runs to 2028-06-27. Earned Schedule measures the rate of work (PMI Standard for EVM, 2019, §4.4); it is not a reschedule. The programme's own finish is 2028-06-19. Work is weighted by the baseline's original durations.

To finish by the programme's own date (2028-06-19), the remaining 859 days of baseline work must be done in 866 days: a required pace (TSPIed) of 0.99 days of baseline work per day, against 0.98 achieved so far (SPIt). The required pace is within 0.10 of the pace achieved, which NDIA reads as in line with performance to date (NDIA Predictive Measures Guide, 2025, §2.6.2).

The full register for this period is in the All Delay Events sheet of the Excel companion (see the note under the composition chart below); this section shows its composition.

Each register row carries an Impact basis tag (matching the composition chart) so the reader can 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 earlier schedule 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 contribution without a calendar-aware CPM pass per event (see Methodology (§34)).

Positive delay values indicate delay to the project finish; negative values indicate acceleration. The Isolated contribution (wd) column gives, for each critical event, the working-day movement of the project finish when that event's change alone is reverted out of the update. It is a screening measure for triage, not an entitlement figure: it is subtractive, so it is not a time impact analysis, which is additive (AACE MIP 3.6/3.7; CIOB §5.8.36) and, as the CIOB Guide uses the term, prospective (CIOB §5.8.40). The figures are isolated from one another and must not be summed (see Methodology (§34)). 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 (§34) for the limitation. The Entitlement (prelim.) column carries a rule-based first-pass classification: Employer risk or Contractor risk (the SCL Protocol's two event types), or 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 one identified change is activity-level, so there is no composition to chart.

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.

All 5 working days of critical delay come from one category (Duration change), so there is no breakdown to chart.

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

One delay event, so no timeline: Bulk excavation Zone A (duration change, 23 Mar 2026 to 16 Apr 2026).

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 14 calendar days (10 working days) later between the earlier schedule and the update.

Why. The engine logged 4 activity-level events, by category in the table below: a map of where movement arose, not a delay total.

Where to investigate. A further 1 topology event (logic, constraint or calendar edits) sits across 1 WBS package. They show where the schedule was rewired between earlier schedule and update, not how many days each edit added: sizing one needs a calendar-aware CPM pass per event. See Methodology (§34).

How to read this section: see Period 1: What happened · Why · Where to investigate.

Of the 7 activities the earlier schedule (data date 4 Feb 2026) forecast to finish before 6 Mar 2026, 7 had finished by the update, over 30 days; 2 of the 2 it flagged critical did. Shown as a count: fewer than 30 activities were forecast in this period.

Starts: of the 6 activities it forecast to start in the period, 6 had started.

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.

Where else forward risk sits: alternative chains to the project end within 20 working days of the critical path. See Methodology (§34).

8 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.

Top 3 of 9 paths shown (the primary driving path plus 8 near-critical) — the full 5-path table and the float-path overlay chart are in Float paths — detail; every path is in the Excel appendix.

How to read this section: see Period 1: Delay and change register.

Composition by category:

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

The full register for this period (5 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.

All 10 working days of critical delay come from one category (Duration change), so there is no breakdown to chart.

How to read this section: see Period 1: Delay timeline.

How to read this section: see Period 1: Concurrent delay.

The delay register contains 2 measurable critical events. None met this engine's test for concurrency — the events are either causally linked in the schedule network (one activity is upstream of the other in either the earlier schedule or the update) or their time windows do not overlap. This is a defensible zero, not an absence of analysis: under the SCL Protocol (§10.5) delays are concurrent only if each causes Delay to Completion, which on a network means 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 moved 4 calendar days (2 working days) earlier between the earlier schedule and the update.

Why. The engine logged 2 activity-level events, by category in the table below: a map of where movement arose, not a delay total.

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

How to read this section: see Period 1: What happened · Why · Where to investigate.

Of the 2 activities the earlier schedule (data date 6 Mar 2026) forecast to finish before 9 Apr 2026, 2 had finished by the update, over 34 days; 1 of the 1 it flagged critical did. Shown as a count: fewer than 30 activities were forecast in this period.

Starts: of the 3 activities it forecast to start in the period, 3 had started.

Where else forward risk sits: alternative chains to the project end within 20 working days of the critical path. See Methodology (§34).

7 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.

Top 3 of 8 paths shown (the primary driving path plus 7 near-critical) — the full 5-path table and the float-path overlay chart are in Float paths — detail; every path is in the Excel appendix.

Measured against the baseline governing this update (SL-DEMO, finishing 2028-07-03), the work done by the data date (2026-04-09) was planned to be done by 2026-04-08: 1 days behind the baseline. That is a schedule performance index (SPIt) of 0.98. At that pace the baseline's planned duration (910 days from 2026-01-05) runs to 2028-07-17. Over the 34 days since 2026-03-06, the baseline's data date, the project earned 33 days of the baseline's planned work (SPIt 0.96); at that pace the remaining 817 days of baseline work would take about 2 years. Earned Schedule measures the rate of work (PMI Standard for EVM, 2019, §4.4); it is not a reschedule. The programme's own finish is 2028-06-29. Work is weighted by the baseline's original durations.

To finish by the programme's own date (2028-06-29), the remaining 817 days of baseline work must be done in 812 days: a required pace (TSPIed) of 1.01 days of baseline work per day, against 0.98 achieved so far (SPIt). The required pace is within 0.10 of the pace achieved, which NDIA reads as in line with performance to date (NDIA Predictive Measures Guide, 2025, §2.6.2).

How to read this section: see Period 1: Delay and change register.

Composition by category:

• Duration change: 2

All 2 identified changes are activity-level, so there is no composition to chart.

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.

No critical delay to break down by category.

How to read this section: see Period 1: Delay timeline.

How to read this section: see Period 1: Concurrent delay.

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.

Questions to clarify

• Clarify 1. This link carries a lag: MEP-280 to FIT-160, 15 days into critical work. What does the gap represent? If it is real work, please show it as an activity.