How to judge forensic scheduling software.

The 12 August verdict was a fail, and the reason it failed no longer holds. At that time the verification packet for the current release carried the previous release's fingerprints and told buyers no calculation behaviour had changed when the code said otherwise. That is fixed at the source, and the fix holds up under checking.

Every number in the current packet matches the tagged code. I recomputed the engine fingerprint and the companion Python fingerprint from the tag and both equal the published pins. The commit and release date match the tag. I cloned the code to a clean folder and checked out the release: the fingerprint reproduced exactly, so the instructions the packet gives a reader work on a plain Windows machine. The earlier note that they did not was a stale local copy, not a defect in the instructions.

The independent proof is real this time, and this is the largest change since the last review. The signed record is the full cryptographic bundle again, not a hand-written summary. The witness file in the packet is the byte-for-byte artifact that was signed: I hashed it and found the same digest inside the signed payload. The signing certificate names the release tag, the release commit and the build run. A buyer working offline can follow the chain from published number to signed evidence without trusting any prose.

The automatic check grew from one value to six. It recomputes the engine fingerprint, the Python fingerprint, the commit, the release date and the transparency-log entry from the tag and the signed bundle, and refuses to pass if the witness in the packet is not the signed one or if the signed record has been replaced by a summary. I ran it and it passed.

The claim of no behaviour change is true for this release. The difference between the last two releases is the version number and wording inside the product's own disclosure text.

Other gaps stay closed. There is a written procedure for reissuing and marking superseded a report already sent. Word reports refuse the "reproducible" stamp without a real version. Version fallbacks read "unknown" rather than a stale number. The web viewer's second hand-typed version is gone and a test prevents its return. Cross-validation is published as 925 of 989 comparisons executed with 64 skipped, not a clean 925 of 925, and the fitted nature of the Primavera P6 comparison is disclosed. Results reproduce: 1,134 unit checks pass, 45 fixtures pass, and all seven copies of the engine on this machine are byte-for-byte identical and correctly stamped.

The public website still names the wrong version. The live page a prospective buyer reads advertises the previous version while the product is a release ahead. The same stale number sits in the stored copies of that page and on the interactive demo page. This is the identical defect the last grade recorded, one release later, which shows it is corrected by hand each time rather than prevented. No test reads those pages, so nothing would catch it again.

Most report producers still do not print a version. Using the seller's own list of the tools that produce client documents, 18 of 54 refer to the engine version anywhere in their code. The other 36 do not. Word documents are protected because the seal is now refused without a version, but that protection does not reach the majority of outputs, including the HTML dashboards a buyer is most likely to receive.

The pre-deploy scrub for the website software is currently failing. Its own test suite reports one failure out of 310, and the failure is the check that stops a real organisation's name reaching a shipped bundle. The offending line is a comment added today to the very file that holds the single version number. The edit is not committed, so nothing wrong has shipped, but the gate is red right now, and it is red because of a change made to the version source file. That is the shape of problem change control exists to catch. It caught it, which is the system working; leaving it red is the part that is not.

The new automatic check has real edges. It skips entirely if the release has not been tagged yet, so it is silent during the window where mistakes are made. It does not compare the build-run link in the packet to anything, though that link happens to agree with the signed certificate today.

Smaller record-keeping gaps remain. A stored summary file still describes the previous release and is not included when the code is downloaded, so anyone reading it locally gets last month's answer. The file holding the single version number still cites an earlier release that has no tag, no change-log entry and no evidence folder, so a report stamped with that version points at nothing. Two of the seven copies of the engine on disk sit outside every check by deliberate exclusion, on the reasoning that they are regenerated rather than edited.

This row covers version and change discipline only. It says nothing about whether the schedule calculations are correct. Knowing which code ran is not the same as the code being right.

I verified the signed record as files on disk and by internal consistency: the witness hash equals the digest inside the signed payload, and the certificate names the tag, commit and build run. I did not query the public transparency log, so I cannot independently confirm the signature was issued.

I ran no report-producing tool end to end today. The finding that 36 of 54 producers carry no version comes from reading and searching their code against the seller's own list; a tool receiving the version indirectly could be undercounted.

Everything was checked on one machine where all repositories are present. Several checks weaken or skip elsewhere. I changed nothing, committed nothing and deployed nothing.

The comparison is genuine, not a self-check. Today I opened the scheduling software's own database read-only and confirmed all thirteen test projects are there, all scheduled in a single run stamped 2026-08-11 13:07:38.267. Every one of the 108 date values the maker published matches the database exactly. Zero mismatches. The file that was loaded into the scheduling software carries no computed dates and no float at all, so that software worked out its own answers with nothing to copy. I also re-ran the engine today at its current version against all thirteen inputs and got zero drift from the published engine columns. The maker's own validator passes thirteen of thirteen.

The honesty problem flagged in the previous grade has been largely fixed. In August the calibration story was buried in one file and the main court-facing document did not carry the result at all. Today the calibration is stated plainly in the court-facing disclosure, in the release notes, in the comparison folder's own front page, and in the schema document: the first and only capture scored six of thirteen, the engine was then changed to match, no held-out case exists, and the input sheet is not in the public repository. Two stale figures that contradicted each other in the same document have also been corrected, and the release history now records the versions that were previously missing. On disclosure, the earlier finding is now out of date and I am recording that as a fix.

The underlying evidence has not moved. There is still one capture, taken once, on one day. The engine failed seven of thirteen cases against it, was changed to match on those same cases, and was never tested against a fresh capture. Nothing has been added since. The second implementation the maker uses as a corroborating witness was edited in the very same commits, 231 lines added across the three fixes, so it is not independent confirmation for the behaviours this comparison covers.

Four specific things a buyer should check and will not like. First, the summary page a buyer opens still reports "Field-level checks: 27". That is the number of activity rows, not checks. The real cell count is 162. Anyone who counts the spreadsheets will catch it. Second, of those 162 cells only 152 are actual comparisons. Eight carry a date both tools were handed as an input, and two are blank. That census is not published anywhere. Third, and most serious for forensic work, no cell in this comparison tests a late date on an activity that has started or finished. The capture writes the actual date over the scheduling software's own computed value on those rows. I confirmed the discarded values today: on one case the software's own late start is 12 January while the published sheet reads 6 January; on another it is 26 January against 8 January; on a third, all four computed dates are 9 January and the sheet carries December actuals instead. In fairness, the engine's separate remaining-late-start field does match the software's raw value on the two cells I could check, so this looks like a display convention rather than a wrong answer. But the population that delay analysis lives on contributes no late-date comparison at all, and none of this is disclosed. Fourth, fifty-two of the comparisons are float values that the maker's own code converted from hours into days before comparing. Forty-two of those are zero on both sides, so ten are doing real work. The converter is loaded from a folder outside the repository.

Smaller but still true: the line stating which software version was used and that a human scheduled it is a fixed piece of text in a script. Nothing reads the version, the operator, or the date. Feed that script a hand-typed sheet and it prints the same line. The operator was the engine's author, and no third party has ever reproduced this. The input sheet is still excluded from the repository and the database path is hardcoded to one machine, so a buyer cannot re-run the comparison end to end. Criticality and driving-path data were captured but deliberately not compared, and on the one activity I checked by hand the two tools disagree on the label. And the two cases dropped from the count are still described as things the scheduling software cannot represent, when one of them is a four-hour lag that the software handles natively and the engine rounds. The maker's own limitation folder says so in its row text while its column heading still says the opposite, and both of those case files are still stamped with an engine version from several releases ago.

This row is only about whether the engine's answers agree with the industry-standard scheduling software. It does not grade anything else about the product: not the release process, not the version pinning, not the internal test suite, not the report writing. It does not say the engine is wrong. On the 152 cells that are real comparisons, both tools agree, and I confirmed that against the software's own database today. What it does not establish is how far that agreement generalises. The thirteen cases are synthetic, the largest has three activities, and all were run with one set of scheduling options, so nothing here speaks to real project files, alternative float settings, or the progress-override mode. The engine was fed hand-built inputs rather than a schedule file, so the file-reading path is untested by this comparison. I could not verify who pressed the schedule button or whether they had already seen the engine's expected answers, and the software's build number is not readable from the database, so the version is supported only by the installation folder and the file timestamps. The raw evidence exists on one machine, and the scheduled results currently sit in a sidecar file beside the database rather than in the database file itself, which is worth knowing if anyone ever needs to go back to the source. Finally, the disagreement I found on the critical-path label may be a definition difference rather than an error. It is unresolved because the comparison never tests that axis.

Two builds of the same engine, one in JavaScript and one in Python, are run side by side on 45 test cases and their answers compared value by value. It runs in one command, exits clean, and prints the fingerprint of the exact Python file it used so a checker knows which bytes were tested.

The accuracy failures found on 2026-08-12 have since been fixed, and I confirmed each one today.

The pass number used to be printed and published as "925 out of 925", which looked like a perfect score but was really just the count of comparisons that ran. Comparisons the two builds could not both answer were quietly dropped from the total. That is now published as 925 of 989, with the 64 dropped ones named and explained, in the badge, the readme, the court-facing disclosure document, the release verification file and the harness's own printed output. I instrumented the harness myself and counted the drops independently: exactly 64, made up of 61 on one field and 3 on another, and 58 of those are cases where the Python side has nothing to say and the JavaScript side prints a number. That is precisely what the published breakdown states.

The disclosure used to list a graph routine (Tarjan) as cross-checked when it was not in the Python file at all. It now says plainly that the routine is not on the cross-checked surface.

The fingerprint pinned in the documentation used to name a different file than the one shipped, which would have failed the product's own integrity step. It now matches the committed bytes, and an automated gate checks it on every run. The release evidence folders for the last two versions also now name the correct fingerprints for the code at those tags.

One production copy of the Python engine used to be a version behind and calculated differently. All four real copies on this machine now compute the core routine from identical code.

More of the production engine is cross-checked than the earlier grade credited. A second harness in the working skills tree also compares salvage mode, one alternative critical-path method and the multi-strategy path. It runs 10 cases and 35 comparisons and passes.

The product is also now candid about the deepest limit. The disclosure states that the JavaScript build was originally reconstructed from the Python file, that the two share an ancestor and one author, and that the check therefore cannot catch a mistake both inherited.

The test material is very small and entirely invented. All 45 cases are hand-built. There are 105 activity results compared in total. The largest single network is six activities. Delays between activities are only whole numbers from minus three to plus three. No real schedule file is cross-checked anywhere; the file format that real schedules arrive in is never mentioned in the harness. There is one claimed check against a real 282-activity file, but that file is not published and the run cannot be repeated by anyone else. The product says so, which is honest, but a claim nobody can re-run is not evidence.

The check reaches only part of the product. Measured today with coverage instrumentation on the parity run alone, it exercises 38.22 percent of the JavaScript engine's statements and 41 of its 87 functions. Reading P6 files, salvage mode, time impact analysis, schedule health and DCMA scoring, float burndown, statutory holiday calendars and the court-facing disclosure renderer all have no second build to compare against. The disclosure correctly says the parity claim applies only to the core maths, but nowhere states how small a share of the product that is.

One number the engine prints as forensic evidence is still largely unchecked. On 58 of 105 activity results there is no Python implementation of it to compare against. On 14 of those the JavaScript side prints a real figure, including one value of minus 10, which is exactly the kind of unusual reading a forensic report would rely on. This is now disclosed rather than hidden, but it is not fixed.

In the production Python engine, two of the ten published routines, float burndown and topology fingerprint, plus the internal cycle-detection routine, still have no second-implementation comparison at all.

The extra harness that does cover salvage mode and the alternative critical-path methods lives only in a private working tree. It is not in the published open-source package, so a buyer or an opposing expert cannot run it.

Warning comparison is still counts and severity only. No warning code and no warning wording is ever compared, so a renamed warning of the same severity would pass unnoticed.

Two stated reasons for excluding things from the check do not hold up. Three cases skip warning comparison on the stated ground that one warning exists only on the JavaScript side. I switched those skips off: six extra comparisons run and all six pass. And sub-day delay cases are excluded on the stated ground that the two languages round differently, when both were harmonised on the same rounding rule.

Small labelling drift remains. In one repository the Python version file says 2.9.39 while its own bundled JavaScript engine and the master version both say 2.9.40. Every function in that file is identical to the canonical one, so no number would come out wrong, but a document produced through that path would name the wrong engine version. The automated lockstep guard walks only the skills tree and does not reach that file.

This row is only about whether the maths is checked against a second build of itself. It does not say whether either build is right. Both builds have one author and one common ancestor, which the product now admits, so agreement between them proves the two ports match, not that they match how commercial scheduling software behaves or how a court would expect a schedule to be calculated. Anything about the separate comparison against actual P6 output, the unit test suite, the release signing chain, or the products built on top of the engine is graded elsewhere.

Three specific things I did not establish. First, the comparison is done by turning both answers into text and matching the text, so a whole number on one side and a decimal on the other would be treated as equal. That blind spot exists even where the comparison does run. Second, I did not test the live hosted service, so the version drift I found applies to the local working copy of that repository, not necessarily to what the server is serving. Third, the coverage figure of 38.22 percent is for the parity run only. That is the right measure for this question, but it is not the product's overall test coverage, which is reported separately and is much higher.

One local wrinkle worth naming so nobody is surprised. On this Windows machine the reference file on disk carries Windows line endings, so running the documented fingerprint command against it returns a value that does not match the pin. The committed bytes do match, and a fresh checkout would match, so the pin itself is correct. But the instructions tell a checker that a mismatch invalidates the result and say nothing about line endings, so a Windows-based checker could stop at step one for no real reason.

Four things improved since 12 August and I confirmed each today.

The headline agreement score is now openly labelled as a self-corrected result. The engine was checked against the industry-standard scheduling application once, scored 6 of 13, was then changed to match the answers that check had produced, and only then scored 13 of 13. That admission now appears in the change log, the court-facing disclosure document, the validation folder README, the cross-examination prep notes, the live public results page, and the free viewer.

Two specific faults named in the earlier review are genuinely fixed, so the earlier finding is wrong as written today. The court-facing document used to describe this evidence as still pending and file it under future work. It now describes it as delivered and fitted, and names the commits that did the fitting. The validation folder README used to say the reference columns were empty and awaiting an analyst. It now says they are filled, dated, and fitted rather than blind.

The free viewer now publishes the small print the earlier review had to work out by hand. It states 162 fields compared across 27 activities, of which only 152 are genuine comparisons, the rest being actual dates carried through or blanks. It states the first blind run scored 6 of 13. Its own test suite runs green.

A separate overstated figure is gone. Internal agreement between the two copies of the engine used to be published as 925 out of 925. It now reads 925 of 989 with 64 comparisons skipped, on the live site, in the shared provenance code, and in the viewer.

1. The paid deliverable still overstates it on page one. The schedule health report says the engine agrees with the reference software on 13 of 13 "independently scheduled test projects". It does not say the engine was changed to match those same 13, does not say they total 27 activities, and does not say a real disagreement was removed from the count. Unchanged since the last review, and it also ships in the hosted bundle.
2. The exclusion is still described backwards on the live public page, in the generated comparison table, and in the operating procedure. All three say the two dropped cases are things the reference software "cannot represent" or "cannot construct by design". One of them is a lag of a few hours. The reference software handles that natively. It is the engine that cannot. The company's own limitations folder says so plainly, and the sentence is hardcoded in the script that writes the table, so it is not computed from the data.
3. The comparison table's headline count is mislabelled. It reads "Field-level checks | 27". Twenty-seven is the number of activities. The actual number of fields filled in is 160, out of 162 defined. This understates rather than inflates, but it is the wrong label on the published number.
4. Ten of the 162 fields are not comparisons. Eight are the schedule's own actual dates handed back and compared to themselves, on the two cases that matter most in delay work, work in progress and work done out of sequence. Two are blanks accepted as passes. The free viewer now discloses this. The comparison table and the paid report do not.
5. Critical path membership is still collected from the reference software and never scored. The one case where the two can be compared disagrees: the reference software marks one activity as driving, the engine calls both critical. A critical path count is something these products publish, and it sits outside the agreement claim.
6. The scoring script still accepts two different dates as a match on the same field, by falling back to the raw value if the adjusted one misses.
7. The provenance file attached to every health report stamps an engine version, an agreement figure, and a link to the engine's release evidence, on a report that never runs the engine. The one field designed to record how float was obtained is left empty.
8. The free viewer's own screening section still carries no note saying where its numbers come from and no link to the parity page that explains the limits.
9. The Python copy of the engine, which every scripted product actually uses, is still never compared to the reference software by any test. I ran it myself today and it matched on all 162 fields. Nothing in the product asserts that, so it could drift without anyone noticing.
10. There is still only one capture and no held-back case. The 13 test schedules total 27 activities and 13 links. No case anywhere has an activity with two predecessors or two successors, so nothing with merging or branching paths, and nothing with competing float, has ever been checked against the reference software.

This row is about how the checking is described, not about whether the engine's arithmetic is correct. I did not find a wrong number in the engine itself. I could not redo the reference-software capture. That side is pinned data from one session, run by the company's own principal, so "agrees with the reference software" rests on that record being honest. The word "independently" in the published wording means independent of the engine, not a third party. I checked the live public results page and the staged copy on the owner's machine, plus the site map, but not every page on the site. I did not render a finished health report, so the page-one wording is established from the template that produces it and from the copy in the hosted bundle, not from a rendered file. Whether the internal agreement figures, the release evidence, or the version records are accurate are separate questions graded elsewhere.

Two things are stated correctly and one has been fixed since the last grading.

The schedule health dashboard is the honest end of the range. On page one it tells the reader that float is "Taken from the file as submitted. No forward or backward pass is re-run, so a stale or overridden float value is reported as it stands rather than corrected." It also declines the formal DCMA critical path test by name and says its own version is a screening substitute, not something to cite in a claim.

The critical path validator declares its float basis accurately as "total float as computed by the source scheduler, with longest-path cross-check", and it does run a genuine independent longest-path calculation, so it can and does report activities the file calls critical that the arithmetic does not put on the longest path.

Now fixed: the last grading said the browser viewer published engine credentials against Primavera P6 with no limit naming the boundary. That is no longer true. The viewer's engine parity page was rewritten and now states, in its own words, that the 13 of 13 P6 result is fitted, that the first blind run scored 6 of 13 and the engine was then changed to match, that the port-agreement headline skips 64 comparisons rather than passing them, and that "The comparison covers the CPM engine. It says nothing about the browser-side sections of this viewer, which read your file and present it."

Everything else in the original finding reproduces today, unchanged.

1. The path explorer product does recompute the network from scratch. Its published basis of measurement says the opposite: "this trace reads the network as presented and does not recompute it". That statement is false about its own code, and the same false line is served by the live analysis server.
2. The forensic delay analysis product, the one used to build a delay claim, reads the stored float everywhere and declares no float basis at all. Its basis of measurement panel lists day unit, calendar and date fields, and has no row for float. A wrong or overridden float in the source file flows straight into which activities are called critical, into who gets blamed, and into the float consumption figures, with nothing flagged.
3. Every recompute in the suite ignores the imposed dates in the schedule. The engine supports the full Primavera constraint set, but no product feeds it. Reproduced today on the supplied constraint-heavy test file: with constraints ignored the project finishes 2026-10-15; with them honoured it finishes 2026-10-21. Float changes on 26 activities. The count of unfinished activities with no spare time goes from 11 to 25. Fourteen activities the constraint-blind pass shows with 7 to 8 days of spare time are actually at zero or minus 4. This matters most where it hurts: the time impact and but-for delay products exist to produce a delay figure from a recomputed finish date, and they produce it with the imposed dates switched off. The code even documents the gap and then names a constraint-aware caller that does not exist.
4. The browser viewer's DCMA metric 12, labelled "Critical Path Test (CP activities)", is still a green PASS whenever the file asserts that at least one activity has no spare time. No test is performed. The viewer contains no scheduling engine, and none of its reading screens says where the float came from.
5. The risk analysis product's declared basis says float comes "from the deterministic CPM pass". The column it drives comes from a helper whose own comment says it "Uses total_float_hr_cnt directly - does NOT rebuild a CPM pass". The declaration is wrong in the product's favour.
6. The critical path validator's own finding cannot reach its headline. On the test file, 9 of 10 activities the file calls critical are not on the longest path, and the report still reads GREEN, 87.0, High Confidence. The divergence caps one sub-check at 70 flat, and one diverging activity produces the same 70 as nine. Its narrative section runs a full recompute and then overwrites the recomputed float with the file's stored value before the prose is written.
7. The same tool reports a DCMA score out of 14 while awarding a free point in the slot where the Critical Path Test belongs. That slot holds a duplicate of the resources check and is scored as an automatic point. On the test file it reports 13 of 14 with the critical path test never run.
8. The schedule health dashboard tells readers to run the analysis server's critical path validator for the formal test. That tool has no such test either.
9. Reports that go out to clients read the stored float and declare no basis: the monthly progress report and its two project-specific siblings, the three-week field lookahead, and the claim workbench trust report.
10. The health dashboard still states "the CPP CPM engine agrees with Primavera P6 23.12 on 13 of 13 independently scheduled test projects" with no mention that the engine was corrected to match after a first blind run of 6 of 13. The browser viewer now carries that caveat. The dashboard does not.

This row is only about where the float number comes from and whether the product says so. It does not establish whether the recomputed float is right. Nothing here was compared against a live Primavera P6 session, so no figure above measures how close this suite gets to P6.

The scale of the constraint effect was measured on one small synthetic test file supplied with the product, and that file's stored float values were hand-typed by the file generator, not produced by Primavera. That does not weaken the constraint finding, because that test compares the product against itself with only the imposed dates switched on, but it does mean the six-day and 11-to-25 figures are illustrative of one file, not a measured error rate on real schedules. No real project schedule was tested.

The test file also contains one constraint code that is not a genuine Primavera token, so only 8 of its 15 imposed dates were recognised. The effect above is what those 8 alone produce.

This row says nothing about the other criteria: engine version consistency, release evidence, the P6 comparison itself, data privacy, or the test suites.

The core date-counting routine is real. It counts working days on the project's own P6 calendar, honours days forced off such as statutory holidays and days forced on such as a worked Saturday, and refuses to compute a nonsense span instead of guessing. Ran it: a Friday to Monday move returns 1 working day on a five-day calendar, 2 on a six-day, 3 on a seven-day.

The biggest failure in the 2026-08-12 grade is fixed, and the fix is real rather than cosmetic. The monthly progress report used to print a headline "Variance to Baseline" figure derived by multiplying calendar days by five sevenths, then labelled as working days. On the sample data it printed "0 Working Days" on a page whose own headline said the job was 11 working days late. Both the web dashboard and the Word report now read the single figure that was actually computed on the finish driver's calendar, and print a dash rather than an estimate when there is no figure. A test builds a case where the old shortcut and the correct method deliberately disagree, runs the real pipeline, and fails if the old behaviour returns. It passes today.

Two reports state their counting basis honestly at the top of the page. The concurrency report says in plain words when it fell back to a Monday to Friday week with no calendar evidence, and raises a warning. The contract-versus-baseline report states outright that its bucket figures use a fixed five-day Ontario calendar while its milestone figures use the project's own calendar. Naming that is to CPP's credit.

One report discloses its shortcut right beside the affected number. The counter-claim report prints "5/7 Mon-Fri approximation; supply a P6 calendar for exact count" in the same sentence as the day figure. That is the standard the published convention asks for, and it is met there.

The published promise is still not built. CPP's own written convention says that where no project calendar is available, the Monday to Friday fallback "is disclosed on the affected figure". No mechanism anywhere does this. The counting routine returns a plain number with no record of which calendar produced it, so nothing downstream can tell. The one skill that discloses beside the figure does so by hand-written sentence, not by any shared safeguard.

Two reports still print calendar-day figures on a page that promises none are shown. The convention text says "No calendar-day figure is displayed." Rendered the concurrency report from its own fixture: that exact sentence appears in the basis panel, while all four headline tiles carry a calendar-day sub-label and the headline percentage gauge is computed on calendar days. Rendered the counter-claim report end to end: the same promise appears, and so does "91 calendar days", twice.

A report can claim calendar awareness it never had. The shared basis panel prints, in bold, "The activity's own P6 calendar" whenever a report does not name one. The counter-claim report renders that panel with no calendar named, on a page where the day figure came from the five-sevenths shortcut. The bold claim and the figure disagree.

The five-sevenths shortcut is still live in two shipped skills, and one of them says nothing. The convention forbids it outright. Counter-claim discloses it. Constructive acceleration uses the same helper and prints the resulting day count with no note at all. A third skill still computes such a figure, but I could find no report that displays it.

One owner-facing figure is still calendar-blind, and the test suite pins it that way. In the claim package builder, the per-component slip is counted with no calendar passed, so every component silently uses Monday to Friday, while the comment above the line claims it follows the working-day rule. A test asserts the exact text of that calendar-blind call, so the green suite certifies the defect rather than catching it.

A calendar the parser cannot read still becomes Monday to Friday in silence. The parser sets an internal flag when a calendar decodes to no working days at all. Searched every skill: nothing in production reads that flag. Nothing warns and nothing stops.

Part-day precision is still dropped without a word. The routine cuts every timestamp back to the date. Ran it: a nine-hour slip inside one day reads as zero days, and a two-hour slip across midnight reads as a full working day. The separate calculation engine raises a loud alert about part-day loss, but that alert reaches no report a client receives, by design.

A warning message still describes a fallback the code does not perform. The engine warns that an invalid calendar will fall back to Monday to Friday. Ran it: an invalid but non-empty calendar does not fall back. It returns zero days across a span whose true answer is four, and a related helper crashes outright. Zero days reads as "no slip".

One report still counts on a hardcoded Ontario five-day week with a fixed holiday table that runs out after 2028, never consulting the project's calendar. It says so, but the numbers are wrong for any project not on that calendar.

Every remaining error runs in the same direction. Each one makes the delay look smaller than it was.

This row is only about how days are counted and how that basis is stated. It says nothing about whether the delay conclusions themselves are right, whether the method matches any published standard, or whether the numbers would survive cross-examination on any other ground.

I checked the shared counting routine, the shared basis panel, and the skills named in the earlier grade. I did not read all thirty-plus skills line by line, so the claim that no per-figure disclosure mechanism exists rests on the absence of any such mechanism in the shared code and on the plain-number return type, not on an exhaustive per-skill read. I did not check the schedule viewer product at all.

The undecodable-calendar path was proven with a synthetic file. I have not measured how often a genuine schedule export triggers it, only that the silent substitution happens once it does.

The invalid-calendar crash is not reachable from CPP's own file parser, which cleans up bad values first. It is reachable when calendar data is supplied by hand or by another tool. I report it as a warning message that contradicts the code, and a robustness gap, not an everyday failure.

All checks were read-only. No files were changed, committed or published.

The engine half of this is now genuinely fixed, and the finding graded on 2026-08-12 is out of date on that point. That grade flagged a published verification packet that named the wrong file fingerprints, so a reader following the instructions got a mismatch. That is corrected. Today I made a clean copy of the engine repository, checked out the released version, and computed the fingerprints myself. Both matched the published values to the character, and the file sizes matched too. I then ran the project's own verification command on that clean copy. It ran 1134 tests and printed "Verdict: PASS". A buyer, or an opposing expert, can do the same thing and get the same answer.

The supporting record around that release is also honest now. The change log has entries for the last two releases. The accuracy figure is published as "925 of 989 defined comparisons executed, 64 skipped" rather than the older "925 of 925", which had read as perfect coverage when it was not. A written procedure now exists for withdrawing and reissuing a report after the engine changes, and it names the specific behaviours that moved.

On the report side, some real things work. When a schedule file is handed in as a file, its fingerprint is recorded truthfully. I confirmed this on a live run. Output fingerprints are taken after the files are written, so they describe the real documents. The plain-text and spreadsheet-style outputs of the main delay method are stable: I ran it twice today and then simulated a run six weeks later, and those four files came out byte for byte identical every time. One product does the whole job properly. The three-schedule comparison prints a fingerprint table on the face of the report, records every input path and the exact command to run again, and refuses to finish if the provenance file cannot be written.

The reports still do not carry what a third party would need to reproduce them, and in places they say the opposite of the truth.

The worst case is the risk simulation product. I ran it twice today, same schedule file, same settings, minutes apart. All five outputs were different. The worst-case finish moved from 09-Mar to 08-Mar. The ranked list of the biggest risk drivers reordered, with two activities swapping places. No random seed appears anywhere in any output; I searched the summary file and there is none. The report page still carries a section headed "Reproducibility Manifest" and a stamp reading "Self-contained, Reproducible", and the provenance file still states that the seed is recorded for byte-stable reproduction and that default runs are deterministic. Both of those statements are false as of today.

The flagship delay report claims reproducibility on its face with nothing behind it. I searched the rendered file: zero fingerprints of any kind, and zero 64-character hash strings. It nonetheless carries a footer stamp reading "Reproducible" and a section subtitled "reproducibility manifest".

Ten products that generate client deliverables write no provenance record at all. Eighteen do. Several of the ten stamp the word "Reproducible" on the output anyway.

Reproduction detail is thin where it does exist. Twelve of the seventeen wired products record no command to run again; the live delay run I did today wrote "rerun_command: null" directly beside a sentence telling the reader to re-run the stated command. A unit test locks that null in place. The code the reports name lives in repositories titled "internal", and no code ships in the deliverable folder, so a recipient could not run the command even if it were named. Nothing that ships reads these provenance files back; the one checking tool in the suite needs a schedule fingerprint that comes out empty on every real run.

Other gaps I re-confirmed today. On a live run, every schedule-identifying field, including data date and activity count, came out empty. Inputs an analyst types in rather than uploads are recorded as "unavailable", which is the same marker used for a file that is missing or unreadable, so the reader cannot tell the two apart. The record is unsigned and does not fingerprint itself. Nothing ties the report to the version of the code that made it. If the provenance step fails, most products write an error string in its place and ship the report anyway. Only two stop. On a cross-day re-run the two documents a human actually reads, the web page and the Word file, both change, and the filenames change too, so nothing matches. One product declares the same record format while leaving out the engine block entirely, so its deliverables carry no engine version at all.

This row is about whether a report can be reproduced and checked. It says nothing about whether the underlying delay maths is correct, whether the methods are the right ones, or whether any conclusion in a report is sound. I ran two products end to end today, the main delay method and the risk simulation, plus the documented path of a third. For the remaining products I read the code rather than running them, so their behaviour is established by inspection, not by execution. The schedules I used are the small demo files bundled with the tool, not real project files; file size does not change the wiring gaps I found, but I did not test on a large real schedule. The engine verification I ran was a clone of the local copy of the repository on this machine, not a download from the public host, so it proves the tagged bytes and the published fingerprints agree, not that the public copy is identical to the local one. I did not attempt to verify the cryptographic signature record against the external transparency log. The engine version fingerprints are taken over the committed form of the files; a Windows copy made with automatic line-ending conversion turned on and the repository's own settings ignored would compute a different value, though a normal clean copy on this Windows machine reproduced the published values exactly. Nothing was edited, committed or published; all writes went to a temporary scratch folder.

Where the product leans on an outside standard, it says so correctly and it has a test that stops the wording being quietly dropped. The schedule health report is labelled a "schedule quality screen; not an AACE 29R-03 forensic MIP" in the machine record that travels with every report, and a test pins that exact sentence. Page one of the report tells the reader the check is narrower than it looks: it is a screening assessment, it has not been compared against the contract or the project records, and it is not a delay finding. The fourteen checks really are the fourteen checks, and the last two are the two named ratio measures rather than invented substitutes. Skills that are not one of the numbered methods in the standard say so in plain words.

Two claims have genuinely improved since 12 August, and both improvements are about honesty. First, the engine's agreement with the commercial scheduling package is now described everywhere in the engine repository as fitted, not independent. The single test capture first scored 6 of 13. The engine was then changed to match the seven cases it failed. No second, blind capture has ever been run. The documents now say that plainly, including a prepared concession for cross-examination. Second, the engine-versus-reference comparison is now published as 925 of 989 defined checks actually run, with the 64 skipped checks named field by field, instead of the earlier flattering "925 of 925".

Nothing on the 12 August failure list has been fixed. Every item below was re-checked today.

1. The guard meant to catch wrong citations is a list of 37 exact phrases, and it catches none of the errors actually present. I ran all 37 patterns against the six live offending lines by hand. All six were missed. The guard still reports a clean pass, and it still skips the copy that ships to the server.
2. One of the two registered copies of the forensic delay skill still carries the wrong method number. It calls windows analysis method 3.7, and describes it using the wording of a third method again. Windows analysis is method 3.3. The local copy is correct, so two versions with the same name disagree. The packaged copy on disk is unchanged since 26 April.
3. Two more wrong method numbers sit in current documents. Near-critical-path detection is labelled section 3.6, and the windows method is called section 3.6 four lines after being correctly called method 3.3. Section 3.6 is a different method entirely.
4. A made-up statistic still ships inside every generated health report file. The text says that, based on industry benchmarks, fixing each failed check takes eight working days, and that projects at a given compliance level have a 75, 45 or 25 percent chance of running more than 30 days late. There is no source. The numbers are typed into the file. The same block calls it a 14-point standard while dividing by 13. Stated fairly, this block is currently unreachable dead code, but it is inside every report file, visible in view-source, and one line of wiring away from printing.
5. The A to F grade, the compliance percentage and the red, amber or green band are the vendor's own inventions, printed under the outside standard's name with no disclosure anywhere. The cut-offs are typed into the file. The footer prints "THRESHOLDS PER DCMA 14-POINT ASSESSMENT" in the same bar as the grade, the percentage and the band, and the provenance block lists the standard and the grade together. I searched the report and the skill documentation for any sentence saying the grade is the vendor's own construct. There is none. That standard defines checks and thresholds. It defines no letter grade, no percentage and no band.
6. The report's own honesty paragraph now overstates one thing. It tells the reader the engine "agrees with Primavera P6 23.12 on 13 of 13 independently scheduled test projects". The word fitted does not appear anywhere in that file. The correction applied thoroughly across the engine documents did not reach the one document a client actually receives.
7. A risk function stamps an industry citation on a number that is not a schedule calculation, and its own description says the opposite of what the code does. The description says it runs a forward pass and records the completion date. The code adds up every activity duration. I ran it on two activities of ten days each that run side by side: it returned a P50 of 20 days where the correct answer is 10, tagged with the citation, with no warning field in the result. It also accepts a list of logic links and never uses them. Inline comments and the skill documentation are explicit about the shortcut, and the shipped report path uses a different, logic-aware routine, so the harm is bounded. The internal procedure document still calls this method an unimplemented gap, which no longer matches the code.
8. The server tells every connected client at start-up that these are "AACE-compliant forensic-scheduling tools", and the readme repeats it. The vendor's own written instruction says not to claim compliance with that standard without completing a methodology section. The blanket wording also covers the quality screen that the vendor's own record labels "not an AACE 29R-03 forensic MIP".
9. The readme's comparison table sells windows analysis as "MIP 3.4-3.7". Windows analysis is 3.3, which that range excludes. A code comment in the same skill still says windows were chosen for method 3.7, in a function used only for 3.3.

This row is about labelling, not about whether the underlying calculations are right. It does not establish that the schedule maths is wrong, and it does not establish that it is right. I read source files and ran the tests named above. I did not render a health report in a browser, so the three findings inside that report template are proven from the file and from tracing which code can call which, not from a printed report. I could not confirm from disk which packaged copy the hosted skill catalogue serves today. The wrong-method wording in this session's own skill listing matches the packaged copy on disk exactly, which is why I treat it as live, but the definitive check is to open that skill in the browser. The other packaged copies in that folder are equally old and I compared only two of them against the current sources, so there may be further drift I have not counted. My reading of which number belongs to which method comes from general knowledge cross-checked against the vendor's own statements of the same numbering, not from the standards documents themselves, so the adjudication rests on the vendor's own files agreeing with me, which they do. One line I could not test either way: an internal procedure document lists the author as an active practitioner of a method I found no implementation of anywhere in the suite. That is a statement about a person rather than a tool label, and only he can speak to it.

The tool-neutral test is simple. Feed a product more rows than any plausible cap, then count what it renders against the total it states, in every branch, and check whether each cap names its own denominator.

Producer one, the schedule health report, was run end to end today on a real 286-activity project pair. It produced five failed-activity registers. In all five, rendered rows equalled the rows in the embedded CSV and equalled the stated label: 13, 6, 10, 134 and 23. Each carried a label of the form "134 activities, all listed". The 134 matches the count the criteria grid states for that criterion. No cap language appears anywhere in the document. Run again on a 10,502-activity file, every criterion passed and the report says plainly that no registers were generated.

Producer two, the claim provability assessment, was driven through its real code with 30 long-runners. On its headline path, with no owner event list supplied, it rendered 30 of 30. The eight-row cap flagged at the last review is gone from the source, and the function now carries a written note explaining why long registers scroll instead of being cut.

The guard behind this also grew. It scans 98 files, up from 76. It runs 17 tests, up from 9, all passing. Caps written as a variable name rather than a number are now caught, which was the easiest way to hide one. A new discovery walk finds report producers by what they call, not by a hand-typed list, and the build fails if any producer lands in neither the scanned list nor the excused list. It found 53 producers and none escaped. Anything excused must carry a written reason, and the residual allowlist sits at 10 entries against a hard ceiling of 12.

Where caps exist by design, they generally state their own denominator: a chart says how many series it plotted out of how many exist, a workbook says "(+N)" when it clips, and the schedule viewer says "Showing first 200 of N activities".

Same file, other branch. The claim provability causation-tier table has two paths. The one fixed since the last review is the sparse one. The better-evidenced path was not fixed. When you supply a list of owner events, which is what a well-documented claim looks like, every auto-detected long-runner is dropped from that table. Driven today with 30 long-runners and one owner event: 30 computed, 0 rendered, and no marker of any kind telling the reader something is missing. The paragraph printed directly above the table says long-runners the file cannot explain stay weak. None of them appear. The machine-readable output still carries all 30, so the page and the data file disagree.

The written justification for the one remaining chart cap is factually wrong. It says the data is already limited upstream by a filter called top_n. That name does not exist anywhere in the file it points at. The chart itself is honest about what it plotted. The audit note that waves it through is not, and that note is exactly what a reviewer would rely on.

The guard states a safety promise that it does not keep: that an unfamiliar pattern must never pass by resembling something safe. Two shapes pass. A slice of exactly 4, 7 or 10 items on an unrecognised name is waved through as a date. A collection reached through a dictionary lookup is waved through as text, even when the collection's own name is on the guard's list. Neither hides a real cap today. I reran all 98 files with both holes closed and got zero new findings.

Coverage is uneven. The new discovery walk only recognises web-page and Word producers. Ten spreadsheet and CSV producers sit in neither ledger and are not discovered either, so a row cap added to a client workbook would not fail anything. Thirty-four JavaScript and HTML files in the same tree are scanned by nothing, and the schedule viewer's code is outside the guard entirely.

Three slice shapes remain invisible to the scanner. I swept for them by hand and found nine matches, all benign on reading.

The 30-row long-runner population is synthetic, because the sample files on this machine produce zero blow-outs and the table cannot be reached from shipped fixtures. The rows use the exact shape the product's own code emits. The dropped rows and the absent notice are properties of the code, not of my input.

I swept the unscanned spreadsheet and CSV producers with the product's own pattern and classifier and found one match, which discloses its own overflow. So the coverage gaps above are missing protection, not proof of a second live defect.

I did not test the deployment mirror, which the guard excludes by rule, and I did not run the schedule viewer in a browser.

One thing I was told was fixed today did not hold: the server test suite ended at 309 passed and 1 failed, on a client-name check unrelated to this criterion.

The error scrubber on the tool surface is genuinely fixed, not fixed on paper. I raised nine real exceptions today (missing file, permission, key lookup, bad JSON, archive open, file copy) using Windows and POSIX paths with spaces, quotes and a surname folder. None of the nine returned a username, a surname or a client folder name. A quoted spaced path now redacts whole, which was the shape a real Python error most often produces. Ordinary forensic prose survives untouched: a date written 2026/08/12, a 3/4 fraction, and/or, 24/7, and a web address all came back unchanged.

The design is honest about what it did not solve. The regex only finds candidates; a second pass decides how far each one really runs. The cases still not covered are written into a table in the test file with a note saying that the test passing does not mean the input is safe, and the pattern is pinned byte for byte across all twelve copies in the tree by a drift test.

The input side has real guards. Caller-supplied paths are checked for null bytes and traversal, must resolve under the server temp directory, and system locations are denied outright even if reached through a link.

The browser side does what it says for the ordinary case. Loading a P6 XER or XML into the viewer stays on the machine, and the browser-side anonymiser does tokenise activity, WBS, resource, calendar and code names before any upload, with the token-to-name map never leaving the browser.

The retention purge script for the free intake form is conservative and unusually candid. It refuses to delete anything outside its own folder, never follows links, ages folders by the timestamp in the name rather than by file date, logs every deletion, and states in its own header that the automatic trigger only fires when a new submission arrives, so a scheduled job is what actually keeps the promise.

The upload path does not use the scrubber. I ran it and read what came back: the browser receives the server's full absolute path verbatim, plus the raw Python error class name. Six sites in the dispatcher and one in the request handler build their error text by direct interpolation. The source-inspection test that polices exactly this habit covers only eight document-parser scripts and never looks at the upload path. That error string is then written into the job record and handed back on every status poll for the life of the record.

The remaining scrubber gap is not academic. A trailing folder whose name is all lower case is still emitted. I checked two shapes that a real matter produces: a lower-case personal name folder and a lower-case company folder. Both left the name on the wire.

Anonymised does not mean anonymous. The strip list covers names, descriptions and labels. It has no entry for the P6 user name recorded on every activity row, so the scheduler's login travels verbatim on every activity. Every activity ID, every internal identifier and every date and logic link also travel verbatim. The module's own header states that the output contains none of the original identity strings. That statement is not true.

Retention is a year by default, and the sweep runs only when the container starts. Nothing expires while the service is up. The rate-limit table is keyed on an unsalted digest of the caller's address and is never swept at all.

Disclosure is the decisive failure. The shipped viewer says "XER and XML files are never uploaded" and three near-identical variants, and the word privacy does not appear anywhere in the deployed bundle, so nothing links the policy that does describe the exception.

Finally, the suite does not exit at 310 passed. It is 309 passed and 1 failed, and the failure is the project's own client-name guard, tripped by an employer name left in a comment by today's uncommitted edit.

Five limits. I did not run a real upload end to end, because doing so would send a schedule to the server; the retention and stored-error findings come from reading the code path and the boot wiring, not from a running container's disk. Environment settings on the host could override the one-year default and the storage location, so 365 days is the code default rather than a confirmed live value. I could not confirm whether a scheduled purge job exists on the web host, so the intake retention promise rests on a cron I cannot see. My view of anonymiser coverage is based on the P6 exports available on this machine; other P6 versions emit further tables that the strip list does not name and that would travel verbatim. The scrubber verdict rests on nine exception shapes I chose, not on an exhaustive enumeration.