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. The baseline is fixed for the whole series: every snapshot is measured against the first schedule.

The project completion date has shifted by ten working days, driven primarily by a single period of deterioration in the SL-DEMO update series. This movement is concentrated in one update rather than spread across the series, indicating a specific disruption rather than a systemic schedule drift. The schedule quality remains high with a Baseline Execution Index of 1.00, which supports confidence in the reported finish dates despite the critical path divergence warning. The reader should review the period-by-period trajectory analysis to verify the timing and magnitude of the slip.

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 completion movement of ten working days constitutes the authoritative and sole delay figure for this period. The table below details the activity-level drivers—progress behind plan, duration extensions, and scope additions—as a structural signal of where pressure built up, rather than a summed project delay total. Because each activity is measured independently, parallel paths and float-absorbed slip are included in these categories without adding to the final completion movement. The topology section identifies where the schedule was rewired between baseline and update, serving as a direction-of-travel signal rather than a quantified working-day impact, which would require a calendar-aware CPM pass per event. Readers should focus on the Superstructure WBS package, where logic edits indicate the primary areas of structural change.

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.

What this section answers: whether the remaining plan is drifting away from anything the project has demonstrated it can produce. Each row divides the production rate the remaining plan requires (remaining EV over the window to that snapshot's stored finish) by the rate the recent EV history demonstrates. Compression has held broadly steady across the series.

Rows marked "not computable" lack the EV history for an honest rate quote (short window, no forward progress, noisy fit, or no stored finish ahead of the data date). Band thresholds (1.10 / 1.35 / 1.75) are heuristic calibration — see the Remaining-plan compression panel for the full method notes.

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

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.

Top 3 of 4 shown — 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 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 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 baseline 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 completion 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 baseline 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 completion 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.

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.

Top 3 of 5 shown — the full 5-path table and the float-path overlay chart are in the Narrative layer.

Recent EV gradient is too unstable to extrapolate reliably — the forecast finish is 341 calendar days later than the schedule's stored date — a gap of 40% of the time left to run. A gap that large (over 30%) usually reflects a short-term burst or stall in progress, not a pace that will hold, so the forecast isn't dependable enough to show. 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).

Remaining-plan compression: 1.40× the demonstrated production rate — significant compression (required 0.113 vs demonstrated 0.080 pp/day; band thresholds 1.10 / 1.35 / 1.75 are heuristic calibration — a feasibility flag, not a determination). The remaining plan asks for roughly 40 % faster production than the recent demonstrated pace, sustained to completion — out-performance of a kind the recent history does not show. At the demonstrated rate the plan crosses the severe-compression threshold around 2027-04-03.

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

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.

Top 3 of 4 shown — the full 5-path table and the float-path overlay chart are in the Narrative layer.

Recent EV gradient is too unstable to extrapolate reliably — the forecast finish is 378 calendar days later than the schedule's stored date — a gap of 47% of the time left to run. A gap that large (over 30%) usually reflects a short-term burst or stall in progress, not a pace that will hold, so the forecast isn't dependable enough to show. 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).

Remaining-plan compression: 1.47× the demonstrated production rate — significant compression (required 0.116 vs demonstrated 0.079 pp/day; band thresholds 1.10 / 1.35 / 1.75 are heuristic calibration — a feasibility flag, not a determination). The remaining plan asks for roughly 47 % faster production than the recent demonstrated pace, sustained to completion — out-performance of a kind the recent history does not show. At the demonstrated rate the plan crosses the severe-compression threshold around 2027-02-05.

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