Why audited spend uses Math.max, not a sum
inventory_agg and domain_agg are two views over the same auctions. The first production run reported $630.49 against $309.82 of real snapshot spend.
Published 2026-09-10 · Search job: inventory_agg domain_agg double count spend
Supply Audit spend is a lower bound. It is the larger of two report views over the same auctions, not the sum of those views.
The first production run, on 2026-09-02, reported observed_spend_cents of $630.49. The run's own inventory-source snapshot totalled $309.82. The aggregator had incremented one running total once per matched row across every probe. inventory_agg and domain_agg are two views of the same auctions. Every dollar was counted once per view. No unit test caught it, because every fixture used a single probe.
What we do now
Accumulate spend per probe. Reconcile with Math.max, not a sum. Max rather than "always trust inventory_agg" because each probe truncates independently at the row cap, sorted by spend. This seat ignores report offset. Either view can be the more complete one on a given night.
The honest claim is "at least this much of your delivery was examined." partial_coverage is what says the ceiling was hit. The per-probe breakdown is stored on the run as observed_spend_cents_by_probe so the headline stays checkable. The fixed run recorded domain $320.67 and inventory $309.82, and used $320.67 as the headline.
Three regression tests cover the overlap case, the unequal-truncation case, and the Math.max() -Infinity trap when no probe matched.
Same class of mistake
Two spend sources, one auction is the ledger version of this error: beeswax hourly rows and beeswax_snapshot lifetime rows cover the same auctions and must never be summed. A plain sum roughly doubles spend. The product read uses greatest().
Do not treat $320.67 as the exact exchange total for that window. It is the larger examined slice. The first-run finding mix on top of that headline is in Read Supply Audit findings.