SL-DEMO

This report analyses a chronological series of schedule snapshots. A schedule is one uploaded snapshot — the baseline or a progress update. A comparison period is the change between two consecutive snapshots (P1 is snapshot 1 to 2, and so on), so N snapshots give N−1 periods. A baseline era is the span over which one plan is the yardstick: this programme was re-baselined mid-series, so each snapshot is measured against the plan in force for its era — see Baseline evolution.

The project finish date has moved seven calendar days earlier than the era baseline, driven by a net recovery despite one period of slip. This pull-in is significant relative to the programme, although the trajectory shows mixed performance with one period recovering and another slipping by five working days. Confidence in these figures is undermined by critical path divergence on up to eighty-three activities and high critical-path churn, suggesting the schedule logic may not accurately reflect the current construction sequence. The reader should review the baseline evolution and critical path stability sections to verify the integrity of the reported finish movement.

This programme was re-baselined during the monitored period, so a single engine-attributed delay figure across the whole series would smear plans that changed. Each era below is measured against the baseline in force at the time. 'Slip within era' is the finish movement from that era's baseline to its last snapshot; 'Re-plan reset' is how far the next re-baseline moved the finish at the boundary — negative means the re-plan pulled the finish in (absorbing prior slip), positive means it added time.

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.

Project completion trajectory across the update series. The observed cumulative delay is the authoritative measure — the actual movement of the project finish date between the first schedule and each subsequent update. How much of each period's movement the engine could tie to specific critical activities (per-event attribution) is in the per-period detail in the appendix, and is shown visually in the period-by-period waterfall below.

The observed programme finish movement of fourteen calendar days stands as the authoritative delay figure for this period. The activity-level drivers table below provides a structural signal of where pressure built up, detailing progress shortfalls, duration extensions, and scope additions as independent measures rather than a summed project delay total. Because parallel paths and float absorption are accounted for individually, these categories serve as a map of churn and the denominator for the subsequent WBS rollup. The topology section identifies where the schedule was rewired between baseline and update, specifically within the Superstructure package, though it does not quantify the isolated working-day impact of each edit. This limitation exists because sizing each event requires a calendar-aware critical path method pass per event, as defined in Methodology §5a.

What this section answers: whether near-critical paths are steadily burning float across the update series — risk that builds before it reaches the completion date and the delay totals. Each period shows the like-for-like float consumed since the previous update; periods with a re-baseline (wholesale constraint or calendar change) or a re-sequence (float released roughly as fast as it is consumed) are flagged rather than reported, because their raw float deltas are artefacts of re-planning, not genuine erosion.

Supporting charts behind the Brief-layer cumulative delay profile: the completion trajectory S-curve and every datable delay event across the series on one calendar.

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

Why. The engine logged 1 activity-level event — progress behind plan, duration extensions, and scope additions — broken down by category in the table below. Each activity is measured on its own, so the categories are a churn and structural signal of where movement arose, not a project delay total: parallel paths and float-absorbed slip both count here, and neither adds to the programme finish movement above. Read them as a map of where pressure built up and as the denominator for the WBS rollup that follows.

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

What happened is the authoritative project-level movement. The activity-level drivers and topology signals below show where and how it arose — each measured on its own, so they are diagnostics rather than additional delay totals, and are not expected to sum to the programme finish movement. 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.

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 the Narrative layer.

Measured against the baseline governing this update (SL-DEMO, finishing 2028-06-08), the work done by the data date (2026-02-04) was planned to be done by 2026-02-05: 1 days ahead of the baseline. That is a schedule performance index (SPIt) of 1.02. At that pace the baseline's planned duration (885 days from 2026-01-05) runs to 2028-05-22. 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-15. Work is weighted by the baseline's original durations.

To finish by the programme's own date (2028-06-15), the remaining 854 days of baseline work must be done in 862 days: a required pace (TSPIed) of 0.99 days of baseline work per day, against 1.02 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 (METHODOLOGY §5a).

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 and retrospective, so it is not a time impact analysis, which is additive and prospective (AACE MIP 3.6/3.7; CIOB §5.8.36, §5.8.40). The figures are isolated from one another and must not be summed (METHODOLOGY §5a.5). 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 earlier schedule and the update.

Why. The engine logged 4 activity-level events — progress behind plan, duration extensions, and scope additions — broken down by category in the table below. Each activity is measured on its own, so the categories are a churn and structural signal of where movement arose, not a project delay total: parallel paths and float-absorbed slip both count here, and neither adds to the programme finish movement above. Read them as a map of where pressure built up and as the denominator for the WBS rollup that follows.

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

What happened is the authoritative project-level movement. The activity-level drivers and topology signals below show where and how it arose — each measured on its own, so they are diagnostics rather than additional delay totals, and are not expected to sum to the programme finish movement. 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.

3 sub-critical paths within 20 working days of critical, plus 5 additional chains at or past critical, 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.

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 the Narrative layer.

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 (METHODOLOGY §5a).

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 and retrospective, so it is not a time impact analysis, which is additive and prospective (AACE MIP 3.6/3.7; CIOB §5.8.36, §5.8.40). The figures are isolated from one another and must not be summed (METHODOLOGY §5a.5). 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
• Progress shortfall: 1
• 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.

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 3 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 earlier schedule 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 earlier schedule and the update.

Why. The engine logged 2 activity-level events — progress behind plan, duration extensions, and scope additions — broken down by category in the table below. Each activity is measured on its own, so the categories are a churn and structural signal of where movement arose, not a project delay total: parallel paths and float-absorbed slip both count here, and neither adds to the programme finish movement above. Read them as a map of where pressure built up and as the denominator for the WBS rollup that follows.

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

What happened is the authoritative project-level movement. The activity-level drivers and topology signals below show where and how it arose — each measured on its own, so they are diagnostics rather than additional delay totals, and are not expected to sum to the programme finish movement. 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.

5 sub-critical paths within 20 working days of critical, plus 2 additional chains at or past critical, 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.

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 the Narrative layer.

Measured against the baseline governing this update (SL-DEMO, finishing 2028-06-29), the work done by the data date (2026-04-09) was planned to be done by 2026-04-09: on the baseline. That is a schedule performance index (SPIt) of 1.00. At that pace the baseline's planned duration (906 days from 2026-01-05) runs to 2028-07-01. Over the 34 days since 2026-03-06, the baseline's data date, the project earned 34 days of the baseline's planned work (SPIt 0.99); at that pace the remaining 812 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-22. Work is weighted by the baseline's original durations.

To finish by the programme's own date (2028-06-22), the remaining 812 days of baseline work must be done in 805 days: a required pace (TSPIed) of 1.01 days of baseline work per day, against 1.00 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 (METHODOLOGY §5a).

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 and retrospective, so it is not a time impact analysis, which is additive and prospective (AACE MIP 3.6/3.7; CIOB §5.8.36, §5.8.40). The figures are isolated from one another and must not be summed (METHODOLOGY §5a.5). 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 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 earlier schedule 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.

This report applies the same Delay Analysis treatment to each consecutive pair of schedules in the series and aggregates the results. The Brief layer's cumulative delay profile reports one authoritative figure — observed cumulative delay; the engine's per-period attribution is carried by the period-by-period waterfall and the per-period appendix detail, not by a second Brief column. The distinction between the two 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.

Engine-attributed delay is the running sum of each consecutive pair's attributed delay — the figure shown by the period-by-period waterfall. It subtracts concurrent absorption per the named concurrency methodology, so it 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 it diverges materially from the observed movement, 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 CPM pass per event (METHODOLOGY §5a).

Concurrent delay handling. Each period applies the named concurrency strategy to decide which overlapping critical events drive the period's engine-attributed delay. The strategy is fixed across the series — switching mid-series would invalidate the running attributed 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 earlier-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-part 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.

Use of AI. The ScheduleLens analysis engine computed every finding, figure, score and chart in this report. At the requester's election, a language model (qwen3-6-27b, via Venice) then wrote the explanatory prose in the sections “Executive summary” and “What happened · Why · Where to investigate (series)”. It worked only from those computed results. It did not see the schedule file and did no analysis of its own. Where prose and a table or chart differ, the table or chart governs.