Marty spotted rows where "left" exceeded "bought" — 3,521 remaining on a
2,500-impression purchase, with "served" reading 0 across those rows.
Reproduced against the network: on 11 of 26 campaigns the ad app's own
assigned/remaining counters have grown past what we inserted. We write
assigned = remaining = the purchased amount; later both sit higher. Actively
serving campaigns still reconcile exactly (served + remaining = bought), so
our arithmetic is right and the inputs are drifting. The cause is inside the
ionCube-encoded ad application, so there is nothing to fix at source.
Direction matters: this is OVER-delivery. Members receive more impressions
than their allowance and the ledger still only charges what they asked for,
so nobody loses anything.
The table now clamps both columns to what was actually bought, so a row
always reconciles: served + left = bought. Showing a member more impressions
remaining than they purchased reads as broken software, which costs more
trust than the bonus impressions are worth.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
martbost
e6b1151ace
