Bryce
89baac19f3
The previous report derived its baseline arithmetically. This one runs the job three times over the same 90 days against identical data, writing real summaries each pass: production's calculation, then R1, then R2. 18,900 summaries per run, 56,700 in total. Window 2026-05-10 to 2026-08-07, deliberately stopping a week short of the backup so the partial days around the cut cannot distort it. Reportable population, 8,350 client-days across 96 clients: baseline 1,024 days off, 87.74% clean, $58,531.75 + R1 752 days off, 90.99% clean, $55,528.17 + R1 + R2 105 days off, 98.74% clean, $852.38 R1 8,054 unchanged, 272 to balance, 0 to unbalance, 0 balanced-day edits R2 7,701 unchanged, 647 to balance, 0 to unbalance, 0 balanced-day edits Across 90 days of trading neither fix altered a single day that already balanced, replicating the 30-day finding on three times the sample. The longer window surfaced two residual clusters the short one could not see: NGMV across five days in late May and NGEB across four spanning May to July. NGEB is the known ezCater fee question; NGMV and N-30012 are undiagnosed and worth a look before this ships. Also records a deployment finding: the transactor was sized for a toy database (2 GB object cache against 27 GB of data) and the final 7,958 client-days of a pass were crawling at ~35/min. Resized to 8 GB cache and 16 GB heap, they finished in 90 seconds. Worth checking production's sizing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>