What a 263-session reconciliation can prove
By Tom Howcroft, live cash player and Overshove builder
On 12 June 2026, Overshove reconciled one real beta account containing 263 session records. This note explains the narrow result, the method and what the sample cannot establish.
What was the sample?
The sample was one active Overshove beta account with 263 session rows and one current bankroll row at the time of the check. The reconciliation was performed on 12 June 2026 after a sync defect had created duplicate bankroll scope across devices. The underlying player identity and session-level records are not published. No claim is made that this account represents other players, stakes, countries or playing patterns.
This is first-party product evidence, not a poker performance study. The sample size is 263 stored sessions because the question was whether the application could preserve and recompute one account's ledger, not whether 263 sessions establish a true win rate. The relevant dates are the audit date and the product state checked on that date. The private session date range was deliberately excluded from publication.
How was the reconciliation run?
The method used the account's stored session rows as the primary ledger. Each session's application net was recomputed under the same session formula used by the product, then summed independently. The result was compared with the account summary and the single surviving bankroll record. Duplicate bankroll rows and duplicate demo sessions associated with the extra bankroll had been identified and removed during the repair, leaving one bankroll and 263 sessions for the final check.
The independent recomputation matched the displayed app total. The exact financial amount and starting bankroll are withheld from this public note. There were no separate adjustment rows in the final state, which made the session sum directly comparable with the displayed app net.
What did the check establish?
It established that, for this account and this product state, 263 stored sessions could be counted once and their net could be recomputed to the displayed total after duplicate bankroll scope was removed. It also exposed the boundary a tracker must protect: a locally newer starting-bankroll value must not overwrite the cloud value merely because one device has stale data.
That is an integrity finding, not an outcome finding. The check did not review individual strategic decisions, verify cash against bank statements, calculate a statistically reliable win rate or compare Overshove with another tracker. It cannot show that the player is representative, that every import will reconcile or that the sync path will never fail again. It shows one real sample, one dated method and one final equality that can be independently repeated from the stored rows.
Why publish such a narrow result?
Poker software often presents aggregate numbers without showing where they came from. A reconciliation methods note demonstrates a more useful standard: state the unit counted, the date, the formula boundary, the final check and the limits. The same standard should be applied whenever a player migrates from a spreadsheet or another tracker.
For a personal migration, preserve the original export, count the rows, recompute net independently, compare checkpoints through the history and keep deposits or withdrawals separate from poker results. If any total differs, stop before treating charts or rates as evidence. A tracker does not become trustworthy because a graph looks smooth. It becomes trustworthy when the ledger can be inspected, exported and reconciled.