Critical Path Partners

cpm-engine

An open-source CPM engine with AACE-aligned methodology and a published Daubert disclosure. 1,515 JS unit tests. The JS engine and its Python reference agree on all 22189 enumerated cross-validation comparisons, none skipped. That is a consistency check between two implementations by the same author, not a check against P6; what a third party can reproduce is in [DAUBERT.md §3.1](DAUBERT.md#31-independent-verification).

Court-facing usage: pair this engine with the analyst-application discipline in FORENSIC_USE_SOP.md, the verification chain in VERIFY_RELEASE.md, the per-release receipts in release-evidence/, the field-level P6 comparison framework in validation/p6-comparison/, and the held-out P6 comparison in validation/held-out/. Do NOT cite README in a court-facing report — cite the documents listed in DAUBERT.md and FORENSIC_USE_SOP.md §Required pairing.

Maintained by Critical Path Partners — a forensic-scheduling consultancy.

---

Quick start

The npm package lags this repository. npm latest is 2.9.19, published 2026-05-17 — that is the number the npm badge above renders, and nothing has been published to npm since, while every later release has shipped here as a git tag. npm install cpp-cpm-engine therefore does not give you the engine described by DAUBERT.md, by the release-evidence/ packets, or by any version reference in these docs. Install from the git tag:

git clone https://github.com/danafitkowski/cpp-cpm-engine.git

cd cpp-cpm-engine git checkout v2.10.15

The engine has zero runtime dependencies, so a clone is all it needs. This is the same install path VERIFY_RELEASE.md gives an opposing expert.

const E = require('./cpm-engine.js');

const result = E.computeCPM( [ { code: 'A', duration_days: 5, early_start: '2026-01-05', clndr_id: 'MF' }, { code: 'B', duration_days: 3, clndr_id: 'MF' }, { code: 'C', duration_days: 4, clndr_id: 'MF' }, ], [ { from_code: 'A', to_code: 'B', type: 'FS', lag_days: 0 }, { from_code: 'B', to_code: 'C', type: 'FS', lag_days: 0 }, ], { dataDate: '2026-01-05', calMap: { MF: { work_days: [1, 2, 3, 4, 5], holidays: [] } }, } );

console.log('Project finish:', result.projectFinish); // 2026-01-21 console.log('Critical path:', result.criticalCodesArray); // ['A', 'B', 'C'] console.log('Engine version:', result.manifest.engine_version); // 2.10.15

That's it. Forward pass, backward pass, total float, free float, calendar arithmetic, P6-conventional date math, multi-jurisdiction holidays — all done.

---

Why this engine?

*(Vendor comparison removed in the v2.9.33 audit cycle. Comparisons against specific commercial CPM tools should be supplied by an independent reviewer, not authored by the engine's maintainer.)*

The engine math is a commodity. What carries a forensic schedule analysis is the workflow, the methodology discipline, and the Daubert disclosure posture — not the forward pass itself. Critical Path Partners open-sources the engine so any academic, any solo forensic scheduler, any contractor's internal scheduler can build on a transparent, citable foundation.

---

What you can build

• Forensic delay analysis primitives — CPM forward/backward pass that supports analyses under AACE 29R-03 MIPs 3.3 (windows), 3.6/3.7 (prospective TIA single-base / multi-base), and 3.8 (collapsed as-built). The engine provides the CPM math; full method implementations (period selection, fragnet integration, as-built reconstruction) live in the CPP forensic skill suite — this OSS engine is the math core they build on, not the full method.
• Claim packages — owner-submission EOT bundles with cover letter, exhibits, mitigation logs
• Daubert disclosures — FRCP 26(a)(2)(B) reports, FRE 702/707 four-prong methodology statements
• Schedule risk primitives — Bayesian posterior estimation (computeBayesianUpdate); per-iteration CPM (runCPM) suitable as an inner loop for Monte Carlo wrappers built on top of this engine. Full Monte Carlo / QRAMM scoring lives in the CPP forensic skill suite (schedule-risk-analysis), built atop this primitive.
• Schedule health — DCMA-14 assessment, A-F auto-grade, baseline-vs-current diff
• Multi-jurisdiction calendars — 66 default holiday rule sets (CA-FED + 13 provinces/territories, US-FED + 50 states + DC). These are framework-aligned defaults sufficient for general-purpose date math — see docs/jurisdictions.md for the per-jurisdiction reference table and forensic-use verification guidance. They are not legally certified calendars; for forensic use, override with the project's contract calendar via opts.calendar.

---

AACE alignment

The engine implements the math behind these AACE Recommended Practices:

Method labels are emitted in result.manifest.methodology — exactly the strings AACE peer-reviewers and opposing experts expect.

---

Verifiable provenance

Every computation emits a manifest:

result.manifest = {

engine_version: '2.10.15', method_id: 'computeCPM', activity_count: 3, relationship_count: 2, data_date: '2026-01-05', calendar_count: 1, computed_at: '2026-05-10T14:32:01.847Z', }

Plus, for forensic provenance, every input carries a SHA-256 topology hash:

const hash = E.computeTopologyHash(activities, relationships);

console.log(hash.topology_hash); // 64-char hex over canonical (code, duration, sorted preds + types + lags) // Two XERs with identical hashes have IDENTICAL CANONICALIZED TOPOLOGY under the hashed-field // set (activity codes, durations, predecessor links + types + lags). NOT a forensic-equivalence // statement — different calendars, resources, WBS, names, or constraints can still produce // different schedules under the same hash. The hash is a signal, not a schedule-equivalence proof.

This is the engine's network-topology fingerprint. Bid-collusion signal, retroactive-manipulation signal, and copy-detection signal across XERs all rely on it. It is also the foundation that lets opposing counsel verify topology-level integrity of a CPP analysis post-hoc — they can recompute the hash from the same XER and confirm the activity/relationship network was not altered between submission and review.

---

JavaScript - Python parity

The engine has a Python sibling (_cpp_common/scripts/cpm.py) used by every CPP forensic skill. The two implementations are kept bit-identical via cross-validation:

npm run crossval

233 fixtures, 22189 checks executed, 0 deviations, measured 2026-11-01.

That is the whole enumerated surface: since v2.10.1 the harness field guards skip nothing.

Plus a 282-activity real-XER stress test reports 0 mismatches. That XER is a single non-public reference file, is not committed, and the run is not independently reproducible from this repo (see DAUBERT.md §2).

This means a forensic analysis run in JavaScript (browser, Node) produces the same numbers as one run in Python (claims-preparation skill, MCP server, batch pipeline). Every CPP deliverable carries the same manifest regardless of which surface produced it.

---

Third-party reproduction

Both the JS engine and its Python reference are maintained here, so their agreement is not independent testing. What a third party can do is reproduce the results on another machine, with a one-command reproduction harness:

git clone https://github.com/danafitkowski/cpp-cpm-engine

cd cpp-cpm-engine git checkout # the SHA cited in the disclosure npm run verify # unit, crossval, citation, truncation and version-drift tests

→ attestations/latest.json ← machine-readable witness file

Engine has zero npm dependencies, so reproduction requires only Node 18+ and Python 3.10+. The witness file contains:

• Engine SHA-256 + Python-reference SHA-256
• Commit SHA + git ref + workflow URL (in CI)
• Test counts: unit-tests passed/failed, crossval fixtures + checks, citation regression status
• Timestamp + Node version + platform
• Verdict (PASS/FAIL)

Compare the engine and Python-reference SHA-256s and the pass counts inside your locally generated witness with those inside the CI-signed witness. CI publishes a witness on every push as a workflow artifact, Sigstore-signed via actions/attest-build-provenance; each release's signed witness is committed at release-evidence/ /witness- .json and attached to the release as latest.json. Matching SHA-256s and pass counts on a clean clone show that the same bytes give the same results on your machine (the witness files themselves differ: each carries its own timestamp). That confirms reproduction, not independence: the tests and the reference are still the author's.

Verify the CI-signed witness of a release. A witness you generate locally with npm run verify is unsigned, so verifying it finds no attestat