A windows analysis you can re-run yourself.

Six duration changes across three windows. The last two columns are the interesting pair. Critical in later snapshot is the engine's total-float test, which treats a completed activity as not critical because a completed activity has no float. So an activity that both grew and finished inside the same window shows as a duration change that never appears in duration_growth_cp, even where it drove the window's slip. That is exactly what happens in windows two and three here. Reading only duration_growth_cp would report zero drivers for both of those windows while the completion date moved +7 and +2 working days. That is why this table reports duration_growth_all and shows both columns side by side.

6 duration changes, all windows, none omitted. Noise floor: changes under 0.1 working days are dropped by the engine as rounding jitter.

This is the register the method actually produces. The Responsible party and Cause notes columns are empty in every row, and they are empty on purpose. The engine does not guess. Note also the Driver type column: the method distinguishes an activity whose own duration grew from an activity that merely inherited a push from upstream, which is the distinction that stops a cascade being counted as 64 separate delays.

64 rows total (W1: 26, W2: 24, W3: 14). Scroll inside the frame; the header stays put. No row is hidden.

Working-day and calendar-day slip are shown side by side for every milestone, because the same movement reads as a different number in each unit and a claim quotes one of them.

8 milestone movements across all windows.

Signed slip per activity summed across all three windows. Reading this as a per-party total would double count: a single upstream growth appears here once for itself and once for every downstream activity it pushed. The attribution section below deals with that.

26 activities moved at least once across the run.

The critical path shrinks across the run because activities complete and completed activities are not critical. No activity became newly critical in any window, which is consistent with the only thing changing being duration on paths that were already critical.

Worth stating explicitly, because in a real matter these are where the arguments live.

logic changes      added 0   removed 0   type_changed 0   lag_changed 0
activities added    0   (all three windows)
activities removed  0   (all three windows)
out-of-sequence     0   (all three windows)

So in this example there is no retroactive baseline edit, no scope creep hidden in an activity insert, no relationship retyped to shorten a path, and no progress recorded against work whose predecessor had not finished. A real schedule chain rarely looks like this. The example is deliberately clean on those axes so the day arithmetic can be checked without them.

These are the skill's own outputs, unedited. The HTML dashboard and the DOCX report are the skill's deliverable format; this page is a separate write-up of the same run.

The skill's manifest schema declares fields that this run did not populate. Rather than leave the gap unstated or fill it from assumption, both lists are published and the source of every substitute is named.

input fields returning null:
  activity_count, calendar_count, data_date, relationship_count, topology_hash

convention fields returning null:
  calendar_basis_id, excluded_from_analysis, float_basis, scheduling_mode_as_read

The five input fields were recomputed directly from the XER files by the run script, using the same parser and the same topology-hash function the engine uses, and those recomputed values are what the Input topology table above shows. The four convention fields are reported as null. The float-basis row in the Conventions table describes the behaviour observed in this run and says so; it is not presented as a manifest value.

Copied from the manifest without edit, including the em-dashes and section references in the original.

1. Engine `computeCPM` (Section C) is the calendar-aware path. Section D / `runCPM` is NOT used in forensic deliverables (it is the Monte Carlo inner-loop engine, intentionally not calendar-aware).
2. Bayesian and kinematic public-API surfaces are JS-only and excluded from JS↔Python parity claims (see cpm-engine DAUBERT.md §11).
3. Multi-jurisdiction default holiday rule sets are framework-aligned defaults sufficient for general-purpose date math; analysts must verify the operative jurisdiction's statute for forensic use (see cpm-engine docs/jurisdictions.md).
4. Topology hash is a canonicalized-topology signal under the hashed-field set (codes, durations, predecessor links + types + lags); it is NOT a forensic-equivalence statement.
5. Windows analysis (AACE 29R-03 MIP 3.3) is observational; it does NOT prove causation. Causation is the analyst's burden.
6. Concurrent-delay attribution uses the engine's attribution rules (see SKILL.md). Other AACE-recognized attribution methods (Time Impact, As-Planned vs As-Built, Collapsed As-Built) may produce different attributions on the same fact set.