Canonical Money Architecture

StackScan reports show the savings number in many places — the paid hero ("You just unlocked ~$X/year"), the plan table's "Total impact (modeled)" line, the stack transformation card, the Start Here highest-impact actions, the execution timeline, and the unlock CTA. Without a canonical source, each surface drifts. The canonical money architecture (lib/stackscan-canonical-money.ts) exports computeCanonicalMoney(finalPlanRows) — a pure function that sums impactMonthly across REMOVE and REPLACE rows after the LLM pass has run. Every savings surface on the paid page reads from this helper, not from the pre-LLM scan engine total.

Before canonical money, the hero read money.monthlyRecoverable (pre-LLM engine estimate) while the plan table summed post-LLM row impacts. When the LLM flipped REMOVE/REPLACE rows to KEEP, the two diverged — gaps of 2× to 19× observed across QA runs at different team sizes. Threading canonicalMoney through the results page reconciles hero, boardroom card, transformation delta, CTA copy, and share block to one number. The scan engine still publishes its pre-LLM diagnosis (the three waste buckets), but the canonical actionable savings comes from the plan the user is about to execute.

A CFO reading a StackScan report expects the $X/mo at the top to equal the $X/mo in the plan below. The average mid-market team overpays $2,000-$6,000/year on CRM overlap alone — and when that number appears on a report, any drift between surfaces reads as sloppy modeling and kills trust. Canonical money makes that equality a property of the code, not a review-time catch. Combined with the fuzz harness's canonical-equality invariant, regressions are caught at commit time rather than on a customer's screen.