Critical Path Partners forensic scheduling MCP

13 tools for Primavera P6 forensic delay analysis — AACE windows (29R-03 MIP 3.3), DCMA-14 health checks, Monte Carlo SRA with AACE 122R-22 QRAMM maturity…

От сообществаРаботаетБез входаГлобальныйБесплатноТолько чтение

Что умеет

  • Forensic Windows Analysis: Run forensic windows analysis (AACE RP 29R-03 §3.3, MIP 3.3 Observational / Dynamic / Contemporaneous As-Is — Modified) across multiple Primavera P6 XER snapshots and return
  • Concurrent Delay Matrix: 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
  • Woet Classifier: 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``), class

Какие данные видит

Нужен ли аккаунт

Не нужен: сервер работает без входа

13 tools for Primavera P6 forensic delay analysis — AACE windows (29R-03 MIP 3.3), DCMA-14 health checks, Monte Carlo SRA with AACE 122R-22 QRAMM maturity, TIA fragnet (MIP 3.7), collapsed as-built (MIP 3.8), and claim workbench evidence ledger. Open-source CPM engine (MIT) at github.com/danafitkowski/cpp-cpm-engine. Daubert-disclosed methodology. 66-jurisdiction holiday calendars. SHA-256 topology hash on every output.

Список инструментов сервера (13)

Технические названия из tools/list. Нужны только разработчикам.

forensic_windows_analysisRun forensic windows analysis (AACE RP 29R-03 §3.3, MIP 3.3 Observational / Dynamic / Contemporaneous As-Is — Modified) 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 × 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 entry in ``schedules`` is the contract baseline (default 0 = first one). entitlement_milestone: optional task_code (e.g. "Ready for Takeover") — recorded on the result, not used for math. output_dir: optional dir for HTML dashboard / DOCX report. If "", a tempdir is used and dropped after — the dashboard / report paths in the response will point to the temp location (caller responsible for moving them). Returns: { "analysis": full dict from run_windows() with keys: "windows", "cumulative", "baseline_label", "data_dates", "attribution_summary", "mcpm_attribution", ..., "dashboard": path to HTML dashboard (server-side), "report": path to DOCX executive report (server-side), "baseline_stability": {"worst_severity", "has_block", ...} } On failure: {"error": "..."} with no schedules processed.
concurrent_delay_matrixBuild 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_windows_analysis`` for the full claim. Args: xer_paths: chronologically ordered list of server-side XER file paths (local-server use). xer_contents: chronologically ordered list of XER text contents (hosted/remote use). Each element is the full text of one XER; server writes each to a tempfile. Supply EXACTLY ONE of paths/contents (lists must have at least 2 entries either way). Returns: { "parties": ["Owner", "Contractor", "Concurrent", "Force Majeure", "Unattributed"], "rows": [{ "window_label", "period_start", "period_end", "shift_days", "parties": {party: days}, "cascade_inferred": bool }, ...], "column_totals": {party: days}, "grand_total_shift": int, "conservation_check": bool, "conservation_diff_days": int, "standard": "AACE RP 29R-03 §4.2.B (concurrent delay apportionment)" }
woet_classifierWorked-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 calendar-shaped visualization layer above the AACE MIP 3.4 entitlement layer — 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": MIP-3.4 enhancement citation, "today": "YYYY-MM-DD", "project_totals": {progress, gain, extended, void}, "per_activity": [{code, name, baseline_start, ...}, ...], "on_time_pct": float (0-100) }
slip_velocityPer-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 instantaneous; acceleration is a finite difference, not a true second derivative. Built on top of AACE RP 29R-03 §3.3 windows analysis. Use this tool when you want a slip-rate trend line on top of the same per-window math ``forensic_windows_analysis`` already computes. Args: xer_paths: chronologically ordered list of server-side XER paths. xer_contents: chronologically ordered list of XER text contents (alternative for hosted/remote use). Supply EXACTLY ONE of paths/contents (at least 2 entries). Returns: { "rows": [{window_label, period_start, period_end, window_duration_days, shift_days, slip_velocity_days_per_day, slip_acceleration, midpoint_estimate_date, half_period_estimated_slip_days}, ...], "cumulative": {mean_velocity_days_per_day, max_velocity_window, accelerating_windows, decelerating_windows, recovery_windows}, "standard": "AACE RP 29R-03 §3.3 (Windows Analysis)", "caveat": "..." }
collapsed_as_builtCollapsed 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.5 framing for the dual-method gap report). 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) 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). Optional: ``removal_method`` ('shorten'|'remove'), ``responsible_party``, ``name``, ``description``. output_dir: optional output dir for HTML/CSV (tempdir if ""). project_name: optional override. removal_method: global default 'shorten' or 'remove'. contractor_filter: when True, exclude contractor-caused events from the cumulative pass (owner audit mode). Returns: { "as_built_finish": "YYYY-MM-DD", "per_event_results": [{event_id, but_for_finish, impact_days, ...}, ...], "cumulative_but_for_finish": "YYYY-MM-DD", "cumulative_impact_days": int, "dual_method_gap": dict | None, "output_files": {...}, "warnings": [...], "method": "AACE 29R-03 §3.8 (Modeled/Subtractive/Single Base)" }
time_impact_analysis_fragnetTime Impact Analysis (TIA) — prospective fragnet insertion into a pre-impact baseline schedule. Implements AACE RP 52R-06 (Time Impact Analysis as Applied in Construction) — the forward-looking / prospective sibling of ``collapsed_as_built``. For each fragnet (delay-event activity chain), the activities are inserted into the baseline network, CPM re-runs, and the resulting completion-date impact (in calendar days AND project-calendar working days) is reported per-fragnet plus cumulatively. 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). Args: baseline_xer_path: server-side pre-impact baseline XER. baseline_xer_content: full text of pre-impact baseline XER (alternative for hosted/remote use). Supply EXACTLY ONE of path/content. fragnets: list of fragnet dicts. Each must have: - 'id', 'name', 'liability' (responsible party) - 'activities': list of {code, name, duration_days, calendar_id?} - 'ties': list of {pred, succ, type, lag_days?} Optional: 'description'. output_dir: output dir for TIA_Report.txt + CSV (tempdir if ""). project_name: optional override. Returns: { "report": path to TIA_Report.txt, "impacts_csv": path to TIA_Impact_Details.csv, "baseline": {"project_finish", "critical_count"}, "per_fragnet": [{fragnet_id, name, liability, completion_before, completion_after, impact_days, impact_working_days, affected_activities, status, error}, ...], "cumulative_days": int (sum of per-fragnet impacts - NOT joint impact) }
critical_path_validatorCritical-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' - 'dcma_14': dict of 14 DCMA metric results - 'recommendations': list of remediation suggestions
dcma14_health_checkFull 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. REQUIRES BOTH XER inputs — without baseline the report is structurally complete but most KPIs blank. If you only have one XER, pass it twice for a synthetic 0-variance run. 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. For the JSON / dict shape only (no HTML), use ``critical_path_validator`` which exposes the same DCMA-14 block. === HOW TO PASS THE XER FILES === For each XER (current, baseline) you supply EXACTLY ONE of: - ``*_xer_path`` — filesystem path on the server. Use this when the MCP server runs locally and the file is already accessible to it. - ``*_xer_content`` — full text of the XER file as a string. Use this when calling a HOSTED MCP server from your local Claude — the server has no access to your local filesystem, so you must send the content over the wire. The server writes it to a tempfile, runs the pipeline, and cleans up afterward. If both are supplied for the same XER, content wins (the path is ignored). If neither is supplied, the call returns an error. Args: current_xer_path: server-side path to the current XER. baseline_xer_path: server-side path to the baseline XER. current_xer_content: full text of the current XER (alternative). baseline_xer_content: full text of the baseline XER (alternative). output_path: optional output HTML path. Ignored when content is supplied (output goes to a tempdir alongside). timeout_seconds: per-step Playwright timeout (default 120s). debug: pipe Playwright stderr / browser console to stderr. return_html_inline: when True (default), the generated HTML is read off disk and returned as ``html_content`` in the response. Required for hosted/remote use; set False to save bandwidth when calling a local server where you can open ``html_path`` directly. Returns: { "ok": True, "html_path": "absolute path on the server", "html_content": "<!DOCTYPE html>..." (when return_html_inline), "current_xer": "...", "baseline_xer": "..." } On error: {"error": "..."} Note: the inline HTML payload can be ~1.3 MB. Some MCP transport stacks have request/response size limits (typically 5-20 MB). For very large XERs / very long dashboards, this may fail at the transport layer; in that case set ``return_html_inline=False`` and arrange to fetch the file from ``html_path`` separately.
path_explorerLogic-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 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. Returns: { "paths": [{chain dicts ...}], "output_files": {dashboard, csv, json}, "project_finish": "YYYY-MM-DD", "project_name": ..., "data_date": ... }
monte_carlo_p50_p80Monte 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_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 "". Returns: Full SRA result dict, key paths: - 'baseline.percentiles': {'P10', 'P50', 'P80', 'P90'} - 'baseline.config': sim params used - 'baseline.sensitivity': per-activity tornado rows - 'project_name', 'data_date', ... - HTML / DOCX paths if outputs emitted
qramm_maturityAACE 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 maturity tier suitable for a forensic-claim methodology section. The badge carries a mandatory caveat that the tier definitions are an interpretation of typical risk-maturity- model structure pending confirmation against AACE 122R-22 §3 primary text. Args: sra_result: dict from ``monte_carlo_p50_p80``. May be {} - the badge degrades to Tier 1 with a clear note. Returns: { "rp_citation": "AACE RP 122R-22 ...", "tier": int (1-4), "tier_label": "Initial" | "Defined" | "Managed" | "Optimized", "tier_description": longer interpretive description, "tier_color": "#xxxxxx", "evidence": ["..." what the SRA had / lacked], "gaps_to_next_tier": ["..." concrete advance steps], "caveat": disclosure string }
claim_workbench_evidence_ledgerForensic 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. Args: folder_path: path to the evidence folder (must exist). output_dir: optional dir for outputs (tempdir if ""). project_name: optional override. original_baseline_xer_filename: optional filename in the folder identifying the baseline XER. contract_form: contract template tag (default 'CCDC2'). run_forensic: when True (default), also runs forensic_windows_analysis on the discovered XER chain. Returns: { "evidence_ledger": {...}, "chain_diff": {...} | None, "rolling_baseline": {...} | None, "trust_score": {...} | None, "cross_reference": {...} | None, "forensic_result": {...} | None, "output_files": {...}, "errors": {...} (per-step failure log) }
xer_parserParse 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) }