docs(sales-summaries): complete the book-neutrality check across all 18,900 days

The verification recompute finished. Comparing every summary in the 90-day
window against the run taken before the payout and cash-shift re-key:

  18,900 compared, 0 differing, largest difference 0.000000

Supersedes the partial 12,044 figure reported while the pass was still running.
Re-keying 213,943 entities moved no money anywhere, to the last decimal place.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-08-15 13:14:06 -07:00
parent 5997c42bf5
commit 07ef71ef7d

View File

@@ -472,15 +472,15 @@
<tr><td>Legacy-scheme keys remaining</td><td class="n good">0</td></tr>
<tr><td>Live re-import, 66 of 102 clients, 90-day window</td><td class="n good">0 entities created · 0 values rewritten</td></tr>
<tr><td><strong>Ownership changes since the re-key</strong></td><td class="n good">0 deposits · 0 shifts · 0 refunds</td></tr>
<tr><td><strong>Summaries recomputed and compared</strong></td><td class="n good">12,044 · 0 differences</td></tr>
<tr><td><strong>Summaries recomputed and compared</strong></td><td class="n good">18,900 · 0 differences</td></tr>
</tbody>
</table>
</div>
<div class="measure">
<p>The re-import is the important negative result. Every payout and shift the importer fetched
resolved to the client's own entity and wrote nothing — the re-key is transparent to the
importer, which is exactly what the legacy-key fallback is for. And recomputing 12,044
client-days afterwards reproduced the previous figures to the cent, so re-keying 213,943
importer, which is exactly what the legacy-key fallback is for. And recomputing all 18,900
client-days afterwards reproduced the previous figures exactly — largest difference 0.000000, so re-keying 213,943
entities moved no money at all.</p>
<p>One caveat worth stating plainly: re-keying stops future contention, but it does not
retrospectively re-attribute records that were claimed by the wrong client while the