What the deduplication work and the two calculation fixes actually did to the books, measured day by day against production's own summaries.
+ +Both arms are computed on the same deduplicated data, so this isolates what the calculation fixes are worth. Figures exclude the ten deactivated duplicate clients, which the plan says to exclude from reporting; including them the shape is identical (432 → 70 days, $25,622.98 → $1,548.64).
+This is the question that matters most for the books, and it has two halves. No day that balanced under production went out of balance — that count is zero. But 237 client-days that were balanced had their line amounts change anyway, and a balance-only view would hide every one of them.
+None of those 237 came from the calculation fixes. Both fixes are provably inert on balanced days — see the decomposition below. They came from the data being corrected underneath.
+| Outcome, production → final | Client-days | Reading |
|---|---|---|
| Out of balance → balanced | 309 | the intended repair |
| Balanced → out of balance | 0 | nothing was broken |
| Balanced → balanced, numbers changed | 237 | amounts moved, balance held |
| Balanced → balanced, identical | 1,652 | untouched |
| Still out of balance | 44 | residual, see below |
| Production summaries in window | 2,242 | of 6,300 client-day slots |
| Pattern | Days | Cause |
|---|---|---|
| Every category 0.00 → real values | ~100 | production held an all-zero summary for a day that had orders |
| Card Payments ↔ Fees reallocation | ~135 | the payout arrived, so the processing fee is now known and booked separately |
| Service Charges line appears | 13 | R2, on days that were already out of balance |
The second pattern is worth reading carefully: Card Payments falls by exactly what Fees gains, so the day stays balanced while the split between the two lines changes. That is a data-freshness effect from re-importing, not a change in how anything is calculated.
Applied in sequence, each measured against the state before it. Percentages of a 3,040 client-day population.
+| Outcome | Client-days |
|---|---|
| Unchanged | 1,581 |
| Numbers changed | 547 |
| Out of balance → balanced | 56 |
| Balanced → out of balance | 19 |
| Balanced → balanced, numbers changed | 237 |
The data work is the only step that unbalances anything: 19 days go out of balance purely from correcting the data, mostly where a refund that had been sitting under the twin client now lands on the right one. The two calculation fixes then absorb all 19, which is why the end-to-end figure is zero.
+| Outcome | Client-days | Share |
|---|---|---|
| Unchanged | 2,941 | 96.7% |
| Out of balance → balanced | 86 | 2.8% |
| Balanced → out of balance | 0 | — |
| Balanced → balanced, numbers changed | 0 | — |
| Still out of balance, but closer | 13 | 0.4% |
| Days touched · dollars moved | 99 | $973.79 |
| Outcome | Client-days | Share |
|---|---|---|
| Unchanged | 2,760 | 90.8% |
| Out of balance → balanced | 276 | 9.1% |
| Balanced → out of balance | 0 | — |
| Balanced → balanced, numbers changed | 0 | — |
| Still out of balance, but closer | 4 | 0.1% |
| Days touched · dollars moved | 280 | $23,729.45 |
Across 3,040 client-days, neither R1 nor R2 changed a single number on a day that was already balanced. Every day they touched was already out of balance. That is the strongest available evidence that they cannot quietly restate correct books — and it is why R2 carries the larger dollar figure without carrying larger risk.
+Of 6,300 client-day slots in the window, production held a summary for only 2,242. The remaining 4,058 had none at all — nothing to compare against, and nothing an accountant could have looked at.
+They are not evenly spread. Eight consecutive days show 210 missing summaries each, which is every client in the database:
+| Dates | Missing per day | Reading |
|---|---|---|
| Jul 15 – Jul 29 | 117 | clients with no summary that day |
| Jul 30 – Aug 6 | 210 | every client — a total coverage hole |
| Aug 7 – Aug 13 | 89 | clients with no summary that day |
The plan predicted a global gap at 2026-07-30 → 08-06 from reading the scheduler, which only looks back seven days and so can never backfill a hole older than that. This measurement found the same eight days independently, from the data. Every one of those 1,680 client-days now has a summary.
+Five client-days above the ten-cent materiality threshold, totalling $404.04. Everything else — 62 days — comes to $1.62, with the largest single day at nine cents.
+| Client | Date | Variance | Explanation |
|---|---|---|---|
| NGBK | 2026-08-06 | +$299.42 | refunds now held by both twins — a re-key consequence |
| NGDA | 2026-08-01 | −$50.00 | auto-gratuity booked as a service charge |
| NGEB | 2026-08-10 | −$25.00 | ezCater fee semantics predicted |
| NGEB | 2026-07-29 | −$20.00 | ezCater fee semantics predicted |
| NGPS | 2026-08-12 | +$9.62 | unexplained predicted |
The ten-cent threshold separates register rounding from real variance with nothing sitting near the boundary — the largest sub-threshold day is 9.00¢ and the smallest material one is $9.62, two orders of magnitude apart.
+as-of — not a re-simulation of them. Datomic keeps every past value, so the comparison is against exactly what was there.fixed + untendered tip + service charges. That identity was checked against a from-scratch baseline recomputation on 20 random client-days and agreed on every one.Re-keying a charge that has two parent orders duplicates the tender, because the other client's import then matches neither key and creates a second charge which cardinality-many appends. The migration must split shared charges first. Separately, remove-voided-orders retracts orders, and 63% of the contended clients' charges have two parents, so a retraction there deletes the other client's payment.