1 pointby joshyi_ba3 hours ago1 comment
  • patty_pie2 hours ago
    The per-service calibration factor is the right call — blended totals are useless for attribution. Curious how stable your factors are over time though. In our experience, volume discounts and reserved capacity shift the multiplier enough month-to-month that historical restating becomes a moving target. Are you versioning the calibration factors, or just applying the latest one when you restate?
    • joshyi_ba2 hours ago
      Well, we compute per-service factors per reconciliation run, and each run's factors are saved with their date window (start_date, end_date, generated_at) in a report artifact. But restatement currently applies whatever factor you pass at execution time. There's no calibration_adjustments table tracking what corrections have already been applied to which date ranges. So double-application is a real risk if you're not disciplined about reusing the saved report. That's a gap we didn't notice, a correction history table is the right fix, thanks for that catch.
      • patty_pie2 hours ago
        Yeah, the double-application risk is subtle and very easy to miss until someone reruns a restatement and wonders why the numbers shifted. A correction history table with an applied_to_range column would cover it. Good tool, looking forward to seeing it develop further.