Cpp Cpm Engine

Run forensic windows analysis (AACE RP 29R-03 §3.3, MIP 3.3 Observational / Dynamic / Contemporaneous As-Is) across multiple Primavera P6 XER snapshots and return the full analysis dict. This is the headline forensic tool — it computes per-window completion shifts, per-window slip registers (per-activity slip with critical/non-critical flag), per-window duration growth on critical-path activities, per-window per-party attribution (Owner / Contractor / Concurrent / Force Majeure / Unattributed), and cumulative project drift from baseline. The attribution math satisfies the AACE 29R-03 §4.1 conservation rule (per-party day buckets sum to project drift within ±1 day, no cascade-double- counting). Use this tool for the full multi-window forensic claim. If you already have a windows result and only want the per-window ×

• schedulesarrayrequired
• project_namestring
• baseline_idxinteger
• entitlement_milestonestring
• output_dirstring

Build the per-window x per-party concurrent-delay attribution matrix from a chronological list of XER snapshots. Implements the per-window concurrency view per AACE RP 29R-03 §4.2.B (concurrent delay apportionment). Where ``forensic_windows_analysis`` answers "how many days does each party own across the whole project?", this tool answers "how did each window distribute its shift across the parties?" — useful when defending or attacking concurrency findings on a window-by-window basis. Conservation rule (AACE 29R-03 §4.1): the sum of per-party column totals equals the sum of per-window completion shifts within ±1 day of rounding. The ``conservation_check`` field on the response reflects this; ``conservation_diff_days`` carries the exact gap. Use this tool when you only need the matrix view; use ``forensic_

• xer_pathsarray
• xer_contentsarray

Worked-vs-On-time Execution Timeline (WOET) per-activity day-by-day classification of as-built execution against baseline. For each pairable activity (matched by ``task_code``), classifies execution into 4 day-states: - PROGRESS: work performed during the baseline-planned window - GAIN: work performed BEFORE the baseline window opened - EXTENDED: work performed AFTER the baseline window closed - VOID: baseline-window day where activity was NOT active This is a CPP-disclosed enhancement layered on top of AACE 29R-03 §3.3 Windows Analysis — a per-day execution classifier (Progress/Gain/Extended/Void) NOT itself AACE-defined. It is not a substitute for fragnet-based AACE 29R-03 §3.7 (TIA) modeling. It gives the trier-of-fact a calendar picture of how the project executed versus how it was supposed to execu

• baseline_xer_pathstring
• actual_xer_pathstring
• baseline_xer_contentstring
• actual_xer_contentstring
• todaystring

Per-window slip velocity & acceleration trend across XER snapshots. Computes three signed metrics per window from the underlying forensic windows analysis: - slip_velocity_days_per_day: completion shift / window duration (positive = slipping, negative = recovering) - slip_acceleration: velocity[n] - velocity[n-1] (positive = slip rate increasing, negative = decelerating/recovery) - half_period_estimated_slip_days: shift / 2 (forensic "where were we at the midpoint" centroid estimate) Cumulative aggregates ``mean_velocity_days_per_day``, ``max_velocity_window``, accelerating/decelerating/recovery window counts. Honest caveats embedded in the response (mandatory for expert reports): midpoint estimates are probabilistic centroids, not observed events; velocity is per-window average, not inst

• xer_pathsarray
• xer_contentsarray

Collapsed As-Built / But-For analysis on a post-impact XER. Implements AACE RP 29R-03 §3.8 Modeled / Subtractive / Single Base method (paired with MIP 3.3 Windows for the dual-method gap report per SCL §11.5). Validates a forensic windows analysis (MIP 3.3) by independently computing the same project drift via subtractive removal of delays from the as-built schedule. For each delay event, the as-built duration of every ``affected_activity`` is shortened by ``impact_days`` (or removed entirely if ``removal_method="remove"``), then CPM re-runs and the resulting "but-for" finish date is compared to the as-built finish. Cumulative pass removes ALL events at once for a project-level but-for finish. Use this tool when opposing counsel demands a but-for analysis or you need a dual-method validation pairing §3.3 (windows) wit

• as_built_xer_pathstring
• delay_eventsarray
• as_built_xer_contentstring
• output_dirstring
• project_namestring
• removal_methodstring
• contractor_filterboolean

Time Impact Analysis (TIA) — prospective fragnet insertion into a pre-impact baseline schedule. Supports two modes. **Single-base mode** (legacy): supply ``baseline_xer_path`` or ``baseline_xer_content``. All fragnets are inserted into the same shared baseline XER and impact is measured against that shared baseline. The result carries a ``single_base_disclosure`` warning explaining this is an AACE 29R-03 §3.7 simplification — acceptable when all events share a single baseline window, but not strict MIP 3.7 Multiple Base. **Multi-base mode** (AACE 29R-03 MIP 3.7 Multiple Base): supply ``per_event_bases`` — a dict keyed by each fragnet's ``id``, with each value a dict containing EITHER ``xer_path`` OR ``xer_content`` for that event's pre-event contemporaneous baseline. Each fragnet is inserted into its OWN ba

• baseline_xer_pathstring
• fragnetsarray
• baseline_xer_contentstring
• per_event_basesobject
• output_dirstring
• project_namestring

Critical-path validation, logic health, and DCMA-14 assessment of a Primavera P6 schedule. Runs the CPP critical-path validator: checks for false criticality, constraint-driven CP segments, open ends, broken logic, and surfaces a DCMA-14 block with the 14 metrics (logic, leads, lags, FS%, hard constraints, high float, high duration, invalid dates, resources, missed tasks, critical tasks, CPLI, BEI, etc.) at the chosen profile threshold (commercial / nuclear / mining). When ``baseline_xer_path`` is supplied, BEI (Baseline Execution Index) is computed. Use this tool to grade a schedule's logic health and find what should be fixed before forensic analysis. For the full HTML health-dashboard PDF render, use ``dcma14_health_check``. Args: xer_path: server-side path to the schedule XER. xer_content: full

• xer_pathstring
• project_indexinteger
• profilestring
• baseline_xer_pathstring
• xer_contentstring
• baseline_xer_contentstring

Full Schedule Health Dashboard HTML report — DCMA-14 + CPLI + BEI + variance/slip register against the baseline. Wraps the CPP Schedule Health Review skill, which produces a self-contained ~1.3 MB HTML dashboard. The dashboard renders DCMA metrics, charts, baseline-vs-current variance, slip register, GAO/AACE compliance bands, and a reproducibility manifest. Baseline XER is OPTIONAL as of Round 7 (Fix MCP-8). When omitted, the tool runs in "degraded mode": the current XER is used as its own baseline for a synthetic 0-variance run. The result carries ``degraded_mode: true`` and ``degraded_mode_reason`` explaining that BEI / variance / slip register KPIs are NOT meaningful in this mode. Supply baseline_xer_path or baseline_xer_content to get the real two-XER variance dashboard. REQUIRES Node + Playwright on

• current_xer_pathstring
• baseline_xer_pathstring
• current_xer_contentstring
• baseline_xer_contentstring
• output_pathstring
• timeout_secondsinteger
• debugboolean
• return_html_inlineboolean

Logic-trace driver-chain explorer — answers "WHY is this activity critical?" and "WHAT does it drive?". Traces driving predecessors backward from a target activity to project start (the "why critical" chain) and/or driving successors forward to project finish (the "what it drives" chain). Detects constraint-driven artificial criticality and cites AACE RP 24R-03 §4 when found. Supports multiple parallel critical paths (MCPM) and near-critical paths. Use this tool when investigating a single activity's logic chain. For a project-wide CP / logic health audit, use ``critical_path_validator``. Args: xer_path: server-side path to the schedule XER. xer_content: full text of the schedule XER (alternative for hosted/remote use). Supply EXACTLY ONE of path/content. target_activity_codes: list of

• xer_pathstring
• target_activity_codesarray
• directionstring
• include_near_criticalboolean
• output_dirstring
• xer_contentstring

Monte Carlo Schedule Risk Analysis — P10/P50/P80/P90 completion-date forecast for a Primavera P6 schedule. Implements an AACE-style quantitative SRA (the same math as CPP's browser Tool_11 Portfolio Risk Engine, scripted Python counterpart). For each iteration, every activity duration is sampled from the chosen distribution (Triangular, BetaPERT, Uniform, Lognormal, etc.) parameterized by % of baseline duration; CPM re-runs and the project finish date is recorded. After all iterations, P10/P50/P80/P90 completion dates and a sensitivity tornado (per-activity correlation to project finish) are reported. Use this tool when you need probabilistic completion forecasts or a tornado/sensitivity ranking. For the AACE 122R-22 QRAMM maturity badge on the result, pipe the response into ``qramm_maturity``. Args:

• xer_pathstring
• iterationsinteger
• distributionstring
• optimistic_pctnumber
• most_likely_pctnumber
• pessimistic_pctnumber
• seedinteger
• output_dirstring
• xer_contentstring

AACE 122R-22 QRAMM maturity tier badge for an SRA result. Scores a Schedule Risk Analysis run (from ``monte_carlo_p50_p80`` or any equivalent dict) against AACE RP 122R-22 (Quantitative Risk Analysis Maturity Model) structure: tier 1 (Initial) through tier 4 (Optimized) per CMMI-style framing of evidence the SRA carries. Inputs the SRA inspects (defensively, all keys optional): - baseline.percentiles (P50 / P80 presence) - baseline.config (iterations, opt/ml/pes %, distribution) - baseline.sensitivity (per-activity tornado rows) - mitigated (scenario comparison evidence) - risk_register_simulation + risk_register_used (Hulett qualitative risk register evidence) - convergence (optional MC convergence diagnostics) Use this tool any time you have an SRA result and want a

• sra_resultobjectrequired

Forensic claim workbench — analyzes a folder of mixed evidence (XER chain + MSG/PDF/DOCX/XLSX correspondence) and produces a unified workbench dashboard. Built from the real-world workflow where forensic delay analysis starts from a folder containing schedule updates, owner correspondence, RFIs, change orders, and meeting minutes — all mixed together. The workbench produces: - Evidence ledger (chronological): all artifacts dated and summarized - Schedule chain-diff: 14-category manipulation log (TASKPRED add/remove, constraint flips, retroactive baseline edits, completion reversals) - Rolling baseline: per-activity baseline-at-introduction across the entire XER chain - Trust score: statistical impossibilities flagged (zero-duration-variance schedules, no-new-activities,

• folder_pathstringrequired
• output_dirstring
• project_namestring
• original_baseline_xer_filenamestring
• contract_formstring
• run_forensicboolean

Parse a Primavera P6 XER file and return a TABLE SUMMARY (not the full row-level data — XER row dumps explode the MCP context window). For each table in the XER, returns the table name, field list, and record count. Per-row data is intentionally omitted — for forensic / DCMA / windows analysis use the dedicated tools (``forensic_windows_analysis``, ``critical_path_validator``, etc.) which consume the parsed XER internally and return analytical summaries, not raw rows. Use this tool to confirm an XER is parseable, list its tables, see the data date / project name from PROJECT, or count activities in TASK before deciding which deeper tool to run. Args: xer_path: server-side filesystem path to the XER file. xer_content: full text of the XER file (alternative for hosted/remote use). Supply EXACTLY ONE of path/content. Returns: {

• xer_pathstring
• xer_contentstring