diff --git a/docs/2026-08-15-thirty-day-reconciliation.html b/docs/2026-08-15-thirty-day-reconciliation.html index 03fd3cbb..952efcd7 100644 --- a/docs/2026-08-15-thirty-day-reconciliation.html +++ b/docs/2026-08-15-thirty-day-reconciliation.html @@ -120,7 +120,7 @@
The importer deliberately understands both the old and new record names, so the change can + be deployed before the renaming finishes. That tolerance is a bridge, not a destination — + while any record still carries an unscoped name, two clients can still land on it, and the + guarantee rests on a convention rather than on the data.
+Measuring the whole database rather than the part that was migrated gives an honest + picture, and it is not a flattering one.
+| Record type | Client-scoped | Still unscoped | No owner to scope by |
|---|---|---|---|
| Refunds | 51,986 | 0 | 0 |
| Payouts | 144,652 | 0 | 36 |
| Cash-drawer shifts | 69,291 | 0 | 0 |
| Card payments | 259,763 (1.6%) | 14,241,890 | 2,122,161 |
Refunds, payouts and shifts are done. Card payments are not — the migration + described above covered the ten clients sharing a location today, within the reporting window, + which is 1.6% of them. And sampling 2% of the orders belonging to every client that has + ever contended found 12,954 payments still owned by two orders, which + extrapolates to roughly 650,000 across that population.
+So the correct reading of the balance figures earlier in this report is: they are what the + calculation fixes are worth, measured on data where the sharing had been resolved for the + clients and period in question. They are not a claim that the whole database is clean.
+Renaming has to be driven from orders, because a payment's rightful owner is whichever order + refers to it — so completing it means walking all 19,040,296 orders, not just the clients that + look shared today. Nine client pairs contended in the past without sharing a location now, and + a migration scoped to the current configuration misses every one of them.
+On the test machine this ran at roughly 15,000 orders an hour once the database no longer + fitted in memory, which puts a full pass in days rather than hours. That is a hardware + characteristic of a swapping 29 GB restore, not a property of the work: the same code + completed 267,012 orders in 100 seconds when the cache was warm. It belongs in a maintenance + window on properly sized hardware, and it is resumable and safe to re-run — a second pass over + already-renamed records does nothing at all.
+The finish line is measurable, not a judgement call.
+ unscoped-report counts, for every record type, how many names are client-scoped,
+ how many are still unscoped, and how many have no owner. Two things follow from it: