diff --git a/docs/2026-08-15-thirty-day-reconciliation.html b/docs/2026-08-15-thirty-day-reconciliation.html
index 29821e9a..4a023cda 100644
--- a/docs/2026-08-15-thirty-day-reconciliation.html
+++ b/docs/2026-08-15-thirty-day-reconciliation.html
@@ -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