Skip to content

METHODOLOGY.md

Latest commit

 

History

History
112 lines (62 loc) · 7.15 KB

METHODOLOGY.md

File metadata and controls

112 lines (62 loc) · 7.15 KB

Forensic-Record Archival Discipline

A one-page methodology brief for forensic-grade software outputs.

The premise

A forensic delay analysis is a document of record. It will be filed in a court, attached to an arbitration brief, served as part of an FRCP 26(a)(2)(B) disclosure, or produced under a litigation hold. It must remain readable, reproducible, and auditable five years after the analyst stops returning calls.

Most "forensic" software products treat their HTML / DOCX / PDF outputs the same way they treat a marketing dashboard — with a CDN-hosted font, a third-party charting library loaded by @import, an analytics tracker, a font.googleapis.com dependency. The output looks beautiful in 2026 and is unreadable in 2031 when the CDN is decommissioned, the font subscription lapses, the tracker domain is repointed.

This is unacceptable for court-filed work product.

CPP's forensic-record archival discipline is a six-pillar standard. The cpm-engine package is the first reference implementation.

Pillar 1 — System-font fallbacks for archived deliverables

Rule. No CDN, no @import, no font.googleapis.com dependencies in court-filed outputs. Every report uses CSS system-font stacks (-apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif) that resolve to whatever the reader's OS provides.

Rationale. A PDF served from a CDN-rendered HTML in 2026 may be unreadable in 2031. A system-font output renders identically on any machine, any era, any offline-air-gapped computer in a courthouse vault.

The engine's renderDaubertHTML() function and the report-generation surfaces in the CPP suite all follow this rule.

Pillar 2 — SHA-256 topology hash on every output

Rule. Every CPM result carries a topology_hash (SHA-256 over canonical (code, duration, sorted-predecessors, lag, type)). Every report embeds this hash in its manifest.

Rationale. A reader five years later must be able to verify that the analyst is reporting on the schedule the analyst claims to be reporting on. The hash is deterministic, reproducible, and excludes P6 UIDs / timestamps / cosmetic edits — so a "rotated UIDs" XER with the same logical content produces the same hash.

This is the foundation that makes post-hoc verification possible. An opposing expert can rerun the engine against the disclosed XER, recompute the hash, and confirm. Without the hash, a forensic report is a sworn statement; with the hash, it is a sworn statement that anyone can verify.

Pillar 3 — ENGINE_VERSION agreement check across all surfaces

Rule. The engine string ENGINE_VERSION must agree with package.json, with every dashboard footer, with every DOCX manifest, with every CSV header. There is no "this dashboard was generated by an older version" ambiguity.

Rationale. When an opposing expert discovers a bug in v2.6 and asks whether it affects the report, the analyst must be able to answer instantly. A version-skew between the engine that ran and the version label on the report is a Daubert vulnerability.

The engine exposes E.ENGINE_VERSION as a public constant. Every CPP skill that wraps the engine reads this constant and refuses to run if its own internal version label disagrees. It is a soft Daubert win that pays for itself in the first deposition.

Pillar 4 — JS-Python crossval bit-identical

Rule. The JavaScript engine and the Python reference implementation must produce bit-identical output on every cross-validation fixture. As of v2.8.0: 153 / 153 checks bit-identical across 13 fixtures, plus a 282-activity real-XER stress test with 0 mismatches.

Rationale. A forensic report should not change based on which surface produced it. A claim package assembled in Python (batch pipeline) must match a live demo run in JavaScript (browser). Two implementations of the same specification, kept in lockstep, materially improve the engine's Daubert posture relative to a single-implementation tool.

Run npm run crossval to verify. The Python sibling is in the CPP forensic skills suite.

Pillar 5 — Zero fabricated citations (audit-enforced)

Rule. Every legal citation, every AACE Recommended Practice, every academic reference must be verifiable against a primary source. The CPP audit discipline (v2.5, v2.6, v2.7) maintains a forbidden-citations list of cases that have circulated in scheduling literature but do not exist:

  • Emden v. Homer Holdings — does not exist.
  • Leopold-Leasco v. United States — does not exist.
  • J.A. Jones v. Plumbers & Pipefitters Local 598 (Wash. App. 2000) — does not exist.

Any commit that introduces these or similar fabricated citations is rejected at audit. Existing fabricated citations have been scrubbed across the entire CPP codebase (1,800+ tests green).

Rationale. A fabricated citation in an expert report destroys the expert's credibility for life. The discipline of "verify every citation against a primary source" is the price of a defensible report.

Pillar 6 — Forbidden-language blocklist

Rule. User-facing strings (HTML, DOCX, narrative output) must not contain Daubert-vulnerable language that presumes a conclusion before the analysis runs. The current blocklist:

  • "fudge" (the record) — presumes intent to deceive.
  • "cooked-schedule" — presumes intent to deceive.
  • "deposable" — presumes a litigation strategy.
  • "fabricated" / "after-the-fact" — presume a conclusion.

These phrases have been scrubbed from every user-facing string in the CPP codebase. Internal variable names and implementation-detail comments may retain technical language; the user-facing layer is clean.

Rationale. A forensic report is a correlation report, not an intent report. The engine reports what is in the data; the analyst (and ultimately the trier of fact) draws the inference about intent. Pre-loading the language with intent-presuming words is a Daubert vulnerability and a credibility failure under cross-examination.

Why this is patentable as a standard

These six pillars are not novel individually. They are novel as a package, applied with discipline across an entire forensic deliverable. No commercial competitor — SmartPM, ALICE, Nodes&Links, Acumen — currently meets all six.

CPP is publishing this brief as a public methodology specification. We invite peer adoption. The combination is the moat.

How to adopt

If you build forensic software:

  1. Pin your CSS to system fonts. Strip @import, strip CDN font references, strip font.googleapis.com.
  2. Hash your inputs. SHA-256 over a canonical input representation. Embed in every output manifest.
  3. Single-source your version. One ENGINE_VERSION constant. Every output reads it.
  4. Cross-validate. Two implementations of the same spec; bit-identical output; CI runs both.
  5. Verify your citations. Every legal case, every academic reference, every RP — primary source or remove.
  6. Audit your language. Strip intent-presuming words from user-facing strings.

The cpm-engine package is the reference implementation. Read the source, copy the patterns, ship a defensible product.

Critical Path Partners, 2026 https://criticalpathpartners.ca