Critical Path Partners

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 a critical flag (total float of zero or less, or the driving path in a schedule with negative float)), 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 CPP conservation check, per the AACE 29R-03 §3.3.E.13 requirement that the summed per-period net impacts equal the difference between the first schedule update and the last schedule update used in the evaluation (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 × per-party grid view, call ``concurrent_delay_matrix`` instead. Args: schedules: list of dicts in chronological order. Minimum 2 entries (baseline + at least one update). Each dict must contain ``label`` (str) and EXACTLY ONE of: - ``xer_path`` — server-side filesystem path, OR - ``xer_content`` — full XER text content. Use ``xer_content`` when calling a hosted MCP server from a remote client whose XER lives locally. project_name: optional override; auto-picked from XER if "". baseline_idx: which ent

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 §3.3.I (apportionment) and §4.2 (concurrency). 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. CPP conservation check, per the AACE 29R-03 §3.3.E.13 requirement that the summed per-period net impacts equal the difference between the first schedule update and the last schedule update used in the evaluation: the sum of per-party column totals equals the sum of per-window completion shifts within ±1 day of rounding. The column-total definition is this tool's own bookkeeping, not an AACE rule. The ``conservation_check`` field on the response reflects this; ``conservation_diff_days`` carries the exact gap. IMPORTANT — conservation is NOT attribution. ``conservation_check`` can be True (the columns sum to the grand total) even when 100% of the shift lands in the Unattributed column, i.e. no party owns any of the drift. Read ``unattributed_share_pct`` and ``high_unattributed_share_warning`` to know whether a meaningful apportionment actually occurred. A fully-unattributed matrix conserves perfectly but attributes nothing — never present its green conservation check as a validated apportionment. Use this tool when you only need the matrix view; use ``forensic_windows_analysis`` for the full claim. Args: schedules: chronologically

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 execute, which is otherwise buried in finish-date deltas. Use this tool when you want a per-activity execution-quality picture (on-time %, count of activities with VOID days, etc.). Args: baseline_xer_path: server-side path to baseline XER (target dates). actual_xer_path: server-side path to as-built XER (act dates). baseline_xer_content: full text of baseline XER (alternative). actual_xer_content: full text of as-built XER (alternative). Supply EXACTLY ONE of path/content per pair. today: optional ISO date (YYYY-MM-DD) reference for in-progress activities. Defaults to actual XER's last_recalc_date if available, else today's date. Returns: { "method": "WOET", "standard": "AACE 29R-03 §3.3 Windows Analysis — per-day execution classi

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). Numerator is the WORKING-day completion shift. The denominator is WORKING days between the prior and later data dates on the same calendar (``window_duration_workdays``), making this a same-day-type working-day/working-day rate. It falls back to CALENDAR days only for legacy window dicts that predate that field, and such a row is flagged ``velocity_basis="wd/cd"``. Read ``velocity_basis`` to know which denominator produced the figure. Each velocity field name states the ratio it holds: ``slip_velocity_workdays_per_workday`` (populated only on the wd/wd path), ``slip_velocity_workdays_per_calendar_day`` (working-days of slip per CALENDAR day elapsed, computed against ``window_duration_days``), and ``slip_velocity_days_per_day`` as the retained back-compat name for whichever basis was selected. Quote ``basis`` in any expert report. NOTE (2026-09-03): the two named fields are no longer equal. ``slip_velocity_workdays_per_calendar_day`` used to be a blind copy of the headline velocity, which made its name wrong once the denominator moved to working days — it read 5/10 = 0.500 while its name promised 5/14 = 0.357. It now holds the calendar-day rate it is named for. - slip_acceleration: velocity[n] - velocity[n-1] (positive = slip rate increasing, negative = decel

Collapsed As-Built / But-For analysis on a post-impact XER. Implements AACE RP 29R-03 §3.8 Modeled / Subtractive / Single Simulation 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`` working days on that activity's calendar (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. Every finish shift is stated in working days on ``workday_calendar``; the calendar-day span of the same shift is kept beside it, and ``day_unit_basis`` names the unit of every bare ``*_days`` key in the result. Use this tool when opposing counsel demands a but-for analysis or you need a dual-method validation pairing §3.3 (windows) with §3.8 (collapsed-as-built). For prospective fragnet insertion (MIP 3.7), use ``time_impact_analysis_fragnet`` instead. Args: as_built_xer_path: server-side post-impact XER (after delays incurred). as_built_xer_content: full text of post-impact XER (alternative for hosted/remote use). Supply EXACTLY ONE of path/content. delay_events: list of event dicts. Each must have ``event_id``, ``affected_activities`` (list of task_codes), and ``impact_days`` (number of working days on the affected activity's calen

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 base, impact is measured against THAT base's pre-event finish, and the result carries ``per_event_methodology``, ``per_event_base_count``, and ``per_event_bases_used`` (sha256-truncated content hashes for audit reproducibility). The cumulative-impact figure carries ``cumulative_caveat`` because the sum of events measured against different bases is NOT a valid joint impact. Exactly ONE of {baseline_xer_path, baseline_xer_content, per_event_bases} must be supplied. Multi-base mode errors out (returning ``{"error": ...}``) if any fragnet id is missing from ``per_event_bases``. Use this tool when modeling delay impact prospectively (e.g. quantifying RFI / change-order delay before settlement). For retrospective windows analysis after the fact, use ``forensic_windows_analysis`` (MIP 3.3 windows). For an impacted a

Impacted As-Planned (IAP) on an unprogressed as-planned baseline. Implements AACE RP 29R-03 MIP 3.6 (Modeled / Additive / Single Base) and SCL Protocol 2nd ed. §11.6(a). Two modes. **screen** (default): inserts each delay fragnet into the as-planned baseline, first one at a time and then all together, re-runs CPM, and reads the joint impact against verdict bands (NO SIGNAL, LOW SIGNAL, MODERATE SIGNAL, STRONG SIGNAL, or INDETERMINATE when the joint pass fails). Use it as a quick read on whether a delay claim has legs before a fuller analysis. The sum of the one-at-a-time impacts is reported beside the joint impact; ``overstatement_days`` is the difference, from fragnets that share a path. Check each ``per_fragnet[].status`` before quoting a figure: a fragnet that failed on its own carries ``status`` "error" and its ``error``, and is left out of the one-at-a-time sum. The joint pass inserts every fragnet together, so read ``joint.status`` and the "iap-joint" warnings too: with a bad fragnet the joint pass can fail (verdict INDETERMINATE) or run without the ties it could not insert. **rebut**: tests an opposing expert's IAP submission. Supply at least one of: ``opposing_impacted_xer_path`` or ``opposing_impacted_xer_content`` (tier A: re-runs their impacted schedule and diffs it against the baseline), ``opposing["fragnets"]`` (tier B: re-models their fragnets on the baseline), or ``opposing["claimed_impact_days"]`` (tier C: their stated figure). IAP does not look at what actually happened on site: it measures the planned logic plus the inserted delays. The result carries ``iap_method_caveat`` saying so, and a ``precondition``

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 text of the schedule XER (alternative for hosted/remote use). Supply EXACTLY ONE of path/content. project_index: which project to analyze in a multi-project XER (0 = first/primary; default). profile: DCMA threshold profile - 'commercial' (default), 'nuclear', 'mining'. baseline_xer_path: optional server-side baseline XER for DCMA BEI. baseline_xer_content: optional baseline XER text content (alternative). Returns: Full validator result dict including: - 'project_name', 'data_date', 'analysis_timestamp' - 'total_activities', 'complete', activity counts - 'critical_path_findings': list of issues - 'logic_findings', 'constraint_findings' - 'overall_rating' / 'overall_score' / 'overall_confidence': LOGIC-HEALTH verdict only (open

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 the server (the dashboard renders via headless Chromium). The tool returns a clear error if either prerequisite is missing. Use this tool when you need the formal HTML deliverable. Do NOT treat ``critical_path_validator`` as a JSON view of this tool. It runs CPP's other DCMA-14 engine (``critical-path-validator/scripts/dcma14.py``). Since 7 November 2026 both engines, and CPP Lens, measure to one written definition (``_cpp_common/references/DCMA_DEFINITION.md``, published at criticalpathpartners.ca/dcma-14-definition.html), and every engine's test suite checks it against the same hand-worked parity fixtures, check by check and count by count. They remain two programs with different outputs: this tool renders the client deliverable and grades it A to F (CPP's convention, not DCMA's, given only when at least 10 of the 14

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 49R-06 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 task_codes to trace; if empty, all CP / near-critical endpoints are traced. direction: 'backward' (predecessors), 'forward' (successors), or 'both' (default). include_near_critical: also trace near-critical endpoints (within float band). output_dir: optional dir for HTML / CSV / JSON outputs. company: optional, the firm the dashboard carries (title block, print cover). Blank unless supplied, and blank carries no firm: a hosted run is the caller's document. Returns: { "paths": [{chain dicts ...}], "output_files": {dashboard, csv, json}, "project_finish": "YYYY-MM-DD", "project_name": ..., "data_date": ... }

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 QRAMM-aligned five-level maturity badge (AACE 122R-22) on the result, pipe the response into ``qramm_maturity``. 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. iterations: number of MC iterations (default 5000). distribution: 'Triangular', 'BetaPERT', 'Uniform', 'Lognormal' (case-insensitive — passed through). optimistic_pct, most_likely_pct, pessimistic_pct: % of baseline duration for the distribution params (defaults: 85 / 100 / 120). seed: optional fixed seed for reproducibility (0 = system entropy = non-reproducible). output_dir: optional output dir; tempdir if "". company: optional, the firm the dashboard carries (title block, print cover). Blank unless supplied, and blank carries no fi

QRAMM-aligned maturity reading for an SRA result. Places a Schedule Risk Analysis run (from ``monte_carlo_p50_p80`` or any equivalent dict) on the five named maturity levels of AACE RP 122R-22 (Quantitative Risk Analysis Maturity Model), section 3: level 1 Reactive, level 2 Ad-hoc, level 3 Centralized, level 4 Dynamic, level 5 Adaptive. Inputs the SRA inspects (defensively, all keys optional): - baseline.percentiles (lowercase p50 / p80 presence) - baseline.config (iterations, opt/ml/pes %, distribution) - baseline.sensitivity (per-activity tornado rows, on_cp) - mitigated (scenario comparison evidence) - risk_register_simulation + risk_register_used (Hulett quantified risk register evidence) - convergence (MC diagnostics, required for level 5) Use this tool any time you have an SRA result and want a maturity reading for a forensic-claim methodology section. Note the scope limit the badge carries on every render: AACE 122R-22 assesses the quantitative-risk capability of an ORGANIZATION and states it is guidelines rather than a standard, so a reading on one simulation run is CPP's placement on the RP's scale, not a QRAMM score. Report it as "QRAMM-aligned", never as "per AACE 122R-22". Args: sra_result: dict from ``monte_carlo_p50_p80``. May be {} - the badge degrades to level 1 with the missing evidence listed. Returns: { "rp_citation": "AACE RP 122R-22 ...", "scale_max": 5, "scale_note": "... names five levels ...", "level": int (1-5), "level_name":

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, every-activity-hits-baseline, etc.) - Slip-to-evidence cross-reference: each forensic slip auto-paired with documents in its window mentioning affected activity codes - Unified HTML dashboard with all of the above Use this tool when starting forensic delay analysis from raw evidence. For single-XER-pair forensic with hand-prepared events, use ``forensic_windows_analysis`` instead. Two input modes (supply exactly one): * ``folder_path`` — the ``staged_folder_path`` that POST /stage returned for YOUR upload, passed back exactly as received. No other folder is accepted: not a desktop path, not the server temp directory, not another folder inside it. * ``evidence_files`` — a CONTENT MANIFEST: a list of ``{"name": str, "content_b64": str}`` entries carrying base64-encod

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: { "filepath": absolute path, "encoding_used": "utf-8" | "cp1252" | ..., "ermhdr": file header dict (P6 version, export user, etc.), "tables": [{"name", "fields", "record_count"}, ...], "table_count": int, "total_records": int, "project_summary": { "proj_id", "proj_short_name", "proj_long_name", "data_date", "plan_end_date" } (from first PROJECT row, if any) }