CPM Engine Cross-Validation Results

The Python reference is pinned by SHA-256 and the hash is printed at the start of every run, so an external auditor can confirm the reference has not drifted between runs. To reproduce:

git clone https://github.com/danafitkowski/cpp-cpm-engine
cd cpp-cpm-engine
git checkout v2.9.43
npm install
npm run test:all

The tag is pinned deliberately. This page records a run performed on 8 September 2026 at engine v2.9.43, and the hashes and dates below are that run's. Checking out the tag is what makes them reproducible; v2.9.43 is the current release, and the 1,273 unit tests pass in the same run. The agreement figure moved from the 931 of 995 recorded at v2.9.41 when v2.9.42 corrected constraint pairing and restored SS/SF late-finish conversion; it has held at 1009 of 1015 through v2.9.43. The run prints the reference path, byte count and SHA-256 before the first fixture, then one line per field check. The final block prints the fixture and check totals shown on this page.

Comparison is field by field rather than on a single summary value. A fixture passes only if every enumerated field matches between the two implementations.

Per-activity checks dominate the count because every activity in every fixture contributes its early and late dates, total float, free float, the rendered date strings, and both float values converted to working days on that activity's own calendar.

1. Free-float parity is a documented gap

Fixture F24 was labelled a documented gap in the suite itself when the Python reference did not compute free float. That gap closed when the free-float port landed: ff and ff_working_days are cross-validated on every fixture, and the signed variants on every activity where either engine emits them. What remains uncompared is 6 comparisons on three fixtures, on completed activities where NEITHER implementation emits the signed free-float fields, so there is nothing to verify and no one-sided gap behind them.

2. The engine is day-granular

P6 stores lags in hours and honours sub-day precision. This engine works in whole days. A sub-day lag raises a SUB_DAY_LAG_ROUNDED alert and rounds. In forensic strict mode that alert is fatal and the engine refuses to produce a result rather than quietly rounding. The case is validation/engine-limitations/cases/01-fractional-lag-engine-rounds/.

3. Two cases are known to diverge from P6 by construction

Fractional lag and dangling relationships test inputs P6 itself cannot produce. Rather than leave them in the P6 comparison matrix where they would look like failures or be silently dropped, they were moved to validation/engine-limitations/cases/ and will never carry a P6 verdict. A dangling relationship, meaning one that references an activity not present in the file, raises an alert and the relationship is dropped; in forensic strict mode it is fatal.

The engine's answers were published before P6 was asked the same questions, and the capture itself was blind: an automated harness imported the 13 mini-projects into P6 Professional 23.12, a human pressed F9 once, and P6's stored answers were read back from the database. The first capture scored 6 of 13. The seven failures were diagnosed into five divergence families (working-day float units, open-end late-date seeding, mandatory-finish semantics, retained logic on out-of-sequence progress, and free-float conventions), fixed in both engine implementations against P6's pinned numbers, and the matrix re-verified at 13 of 13. Every fix is a public commit citing the capture.

Alert counts include informational alerts. The remaining alerts are by design: the completed-successor backward-pass skip on case 09, out-of-sequence progress on case 10, and constraint-application alerts on cases 05, 11 and 12.

Two cases formerly numbered 14 and 15 are excluded by construction and live under validation/engine-limitations/. See the gaps drawer above.

1. Unit suite. 1216 assertions across calendar arithmetic, the forward and backward pass, topological sort, cycle detection and the public API. 0 failures.
2. No fabricated citations. Scans markdown, JavaScript, HTML and Python for standards citations that do not resolve.
3. No client names. Scans tracked source for client and project identifiers, so no real engagement can reach a public commit.
4. No truncation. Confirms engine surfaces return complete data rather than a capped subset.
5. No stale version references. Scanned 16 files, 3595 lines and 151 version references against the current engine version.
6. Procedure validator. Four fixtures exercising the documented analysis procedure.
7. Signing and attestation. Seven sub-suites over the cryptographic sign-off path.
8. P6 comparison validator and corpus topology. Seven scenarios, one real and six synthetic, plus a topology fixture confirming the diamond-cascade shape of case 13.

The release-evidence packet for v2.9.39 was built from the release commit and passed its strict gate with all ten required files present; the v2.9.43 packet does the same (CI-signed witness, Sigstore Rekor logIndex 2685194682). An independent evaluation record from 16 August 2026 documents what an external audit found and what was done about each item.